I'm setting up some traffic routing to use Squid's TPROXY with a
separate router. So the network design looks like:
Clients ----- Squid
|
|
Router
|
|
Internet
There will be a GRE tunnel between Squid and the router. So the idea is:
- The router intercepts web requests from the clients, uses iptables to
mark them and routes them over the GRE tunnel to Squid.
- The Squid proxy machine intercepts the traffic coming from the GRE
interface and redirects it to TPROXY.
- Squid does its thing, probably making a request to a web server.
- The traffic to the web server is routed over the GRE tunnel back to
the router.
- The router CONNMARKs the traffic from the GRE tunnel and directs it
out to the internet.
- Reply traffic from the webserver has its connmark restored by the
router and is sent back over the GRE tunnel to Squid.
- Squid's response to the client is sent over the GRE tunnel to the router.
- The router sends the response on to the client.
I can do everything except identify Squid's requests to the web server
and therefore route them back over GRE. I could use tcp_outgoing_tos
and then route based on ToS, but I'd prefer to avoid abusing the ToS
flags - is there a similar way of setting the fwmark? qos_flows only
seems to control the replies to the client rather than requests to the
web server...
I've read through the documentation for setting up wccp, but as far as I
can see the example configurations only route client->squid traffic via
GRE and the squid->client and squid<->webserver traffic all follows the
usual routing instead (which would require Squid to have its own
dedicated connection to the router).
-- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve_at_opendium.com Email: steve_at_opendium.com Phone: sip:steve_at_opendium.com Sales / enquiries contacts: Email: sales_at_opendium.com Phone: +44-844-9791439 / sip:sales_at_opendium.com Support contacts: Email: support_at_opendium.com Phone: +44-844-4844916 / sip:support_at_opendium.comReceived on Mon Jan 14 2013 - 12:30:53 MST
This archive was generated by hypermail 2.2.0 : Tue Jan 15 2013 - 12:00:04 MST