If you get stuck with things contact me and I will see if I can sort things out so you would be able to grasp couple basics. Eliezer ---- Eliezer Croitoru Linux System Administrator Mobile: +972-5-28704261 Email: eliezer@xxxxxxxxxxxx -----Original Message----- From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Hoggins! Sent: Tuesday, January 3, 2017 3:13 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Intercept mode failing Hello Amos, I believe my main problem is that I'm trying to apply recipes without understanding some of the internals, so it seems difficult to adapt. I'll keep searching. Thanks anyway ! Hoggins! Le 03/01/2017 à 12:39, Amos Jeffries a écrit : > On 2017-01-03 23:53, Hoggins! wrote: >> Hello, >> >> (answering to both Amos and Antony here, you got the same questioning >> ;) ) >> >> Le 03/01/2017 à 11:45, Amos Jeffries a écrit : >>> On 2017-01-03 23:13, Hoggins! wrote: >>>> Okay, I get that. >>>> >>>> Le 03/01/2017 à 10:33, Antony Stone a écrit : >>>>> No - you must do the NAT (or REDIRECT) rule *on the Squid server*. >>>> >>>> Well, my Squid server is not on the same network as my clients, so >>>> I need something else than just a REDIRECT on the Squid itself. >>> >>> That does not matter when the DNAT or REDIRECT is done on the Squid >>> machine. >> >> OK, I'll have a deeper look into that, indeed I'm not familiar with >> what REDIRECT *exactly* does. >> > > It does the same as DNAT, but using the machines "primary" IP address > instead of one you configure. Usually that means the first IP assigned > to eth0 or equivalent first interface. > > DNAT is best if you want a specific fixed IP:port for Squid to receive > on. > > REDIRECT is best if you want the proxy to be plug-n-play on any > network. squid.conf and iptables not needing IP address, just a port > number. > > >>> >>>> >>>>> >>>>> If you need to use policy routing to get the packets to the Squid >>>>> machine in the first place, that's okay, but this *must* be packet >>>>> routing, not address translation >>>> >>>> Policy routing was my first choice, but there is one important >>>> detail in my setup : between my gateway (192.168.22.10) and my >>>> Squid (192.168.55.3), there's an IPSec tunnel. My gateway does not >>>> have a link-local route to 192.168.55.3 so I can't add the default >>>> route to it inside a routing table (I get "Network is unreachable", >>>> which is expected). >>>> >>>> So I guess I'm stuck. >>> >>> >>> So how did the packets get to the Squid machine after your DNAT ? >>> >>> The route does not have to be link-local. Any type of route will do >>> so long as all the routers handling the packets know which way to >>> pass them, and the dst-IP address is not changed. >> >> Well, xfrm routing is a lot different than "classic" routing, I >> learnt it the hard way. DNAT *will* work whereas policy routing won't >> if I don't explicitly declare all my subnets in my IPSec tunnel >> configuration. Got a big discussion about that on StrongSwan's >> mailing-list, and I believe this sums it up pretty nicely : >> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9 >> .png >> > > Looks like a simplified version of the netfilter devs official diagram > to me. So all the required decision points are present and should be > configurable. > >> >> Anyway, yes, if I try to add a route by : >> ip route add default via <IP ADDRESS> table 123 >> >> <IP ADDRESS> *has* to be directly reachable. Or it has to be in the >> routing table somehow. But the routing table handling the tunnelled >> packets is not managed by iproute2. > > It should "simply" be one of the tables with a value other than "123". > But that should not be a consideration as editing it is not necessary. > This "123" routing is only relevant *before* packets enter the tunnel, > since it is what tells the OS to send packets to the tunnel. > > IIRC the routing table for HTTP traffic (your '123' table) should > indicate the tunnel as the gateway <IP ADDRESS>. I don't recall > whether that gw was needing to be the local or the remote tunnel > endpoint though sorry, been too long since I set one of these up. > >> >> So as I can't do otherwise, I'm going to experiment a bit more with >> the REDIRECT + DNAT between the gateway and the Squid server. >> > > I think you are misinterpreting that diagram in regards to the policy > routing setup. > > What we have on the squid wiki on "Policy Routing" makes packets > follow this path; > > * the PREROUTING "mangle" table sets marks on packets to be delivered > to Squid. > > * those packets go through the "FORWARD" to that gateway in > '123'/'proxy' table. > (in our wiki that is the "ip rule add fwmark 2 table ..." part). > > * after POSTROUTING the packets destined to a tunnel gateway are > diverted at that last-minute decision point after "QoS egress" so they > go back to "OUTPUT" which is where the tunnel related things are done > to it. > > Note that for the machine where the tunnel leads *from*, all that > matters is routing the packets into the tunnel. Once packets are > encapsulated by the tunnel they simply go through it to the other end. > The receiving machine does whatever it needs to after the packets > leave the tunnel. > > HTH > Amos > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
