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
