There was a long time ago a small "bug" report in the list about tproxy
intercepted connections which was intended (from squid logic) to
127.0.0.0/8.
The solution was to define no-tproxy on the localhosts cache_peer in
order to avoid the problem.
I wanted to describe the *bug* from the kernel point of view:
tproxy means interception of a connection on the very socket level Which
is not related in any form to netfilter connection tracking!!
Also it is recommended to disable if possible netfilter connection
tracking on all sockets that are destined to be intercepted.
The other side of this interception is the binding of an IP+PORT which
are not in any form related to the proxy machine IP identification as a
socket of it(proxy machine).
The above means that it is expected from all the IP packets that do
match the IP+PORT socket to be returned into the proxy machine.
All the above is some internal logic inside the kernel and relies on
very heavy routing policies which are defined by either the network
Admin or any automation tools.
The above description explains why a binding of an IP for example
1.1.1.1:9000 towards 127.0.0.1:9090 might not be possible.
Since the basic logic is that the only IP's that can contact the
127.0.0.0/8 addresses are OS local IP addresses.
We can run a simple test that can confirm that the kernel do or do not
allow such sockets to exists but since squid do use a VIA and
forward_for headers it is expected if possible to not force the kernel
into a complex of binding non-local IP from within the kernel towards a
local_ip inside the kernel.
The only case that it might be "worth" to do use this non_local_IP
binding is if the load and capacity of the server from CPU RAM and
overall I\O throughput can exhaust the about 32k src ports that can be
dedicated for squid for in-kernel network traffic usage between processes.
When the above is true the first solution that comes in my mind is to
use more IP addresses from the 127.0.0.0/8 subnet for binding both in
server side and client side(of squid by the auto socket binding of the
kernel).
I am not sure if this is implemented yet in the kernel or if it is
needed but since now we have IPV6 it is clear that there are some limits
that can be exceeded above imagination.
Has anyone tested the mentioned pair non_local_IP:port =>
127.0.0.0/8:port in the socket level?
Thanks,
Eliezer
