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
>
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
