On 09/03/2013 02:37 PM, Amos Jeffries wrote:
>
>> Moreover, the following section really confused me:
>>
>> Use DIVERT to prevent existing connections going through TPROXY twice:
>> iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
>>
>> Based on my understanding of this iptables rule, I think it is
>> intended for reply packets coming from web servers to squid (with the
>> spoofed IP address), right?! Saying that its purpose is to "prevent
>> existing connections going through TPROXY twice" really confused me
>> and I still can't understand what this means!
>
> I'm not sure myself. It is part of the magics which the iptables people
> passed to me.
>
> As far as I understand "-m socket" matches any packet which has a local
> process with sockets sending/recieving. So it _probably_ causes the
> TPROXY rule to operate only on SYN,SYN-ACK packets from the client and
> ignore the packet on the squid->server connection *and* packets on
> ESTABLISHED state for already caught connections. Although I am not sure
> of that ESTABLISHED ivolvement. "DIVERT" is just the name of a local
> custom chain with the operations to perform on the "-m socket" matched
> packets.
>
> As far as Squid goes this is system level voodoo to be added to your
> iptables rules. The netfilter help mailing lists is the place to go for
> explanations if you want to know the deeper meanings. I can help you wit
> hthe Squid side, such as it is, and history behind the wiki page since I
> am the developer for TPROXYv4 in Squid - but it has a long history
> before I gt anywhere near it.
Not getting to the code level but the idea and logic seems like what you
have mentioned..
"-m socket" from a logic point of view is more like "match that this
connection is a socket connection and not just a routed one".
a socket means that the connection *end* is the socket from the OS point
of view.
In a regular router the connection is just forwarded ie "routed" through
the hardware and a very low level\inspection of the OS.
when moving to the upper levels of the software a SYN and SYN-ACK are
part of *a* connection with a ip:port to ip:port pair.
once there is a double ip:port + ip:port from the connection tracking
which is the layer 3 of the 7 then this connection can be invalid..
From a network point of view + OS point of view there is not a chance of
this kind of thing happening..
these iptables rules:
iptables -t mangle -A PREROUTING -p tcp -m socket -j CONNECTION
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
--tproxy-mark 0x1/0x1 --on-port 3129
#
iptables -t mangle -N CONNECTION
iptables -t mangle -A CONNECTION -j MARK --set-mark 1
iptables -t mangle -A CONNECTION -j ACCEPT
#
describe that a packet comes from the interface into the OS and the OS
while enabling basic connection tracking still in the layer2\3 and not
the more upper levels.. checks for the state of the connections first.
pesudo:
1 - if it's an established connection and ends or starts on this OS aka
machine dont mangle with it and let the connection keep going.
2- if it's do not match the last rule which means that this connection
is destined to another machine and in the SYN or SYN-ACK level which is
not yet a socket in any form of it like to this machine\OS or another in
the world and that the traffic is through this machine..
then send the connection to this TPROXY port and register it as
intercepted and let the process handle the traffic that comes from this
connection.
hope it helps to understand the subject in more depth.
by the way if we have a loaded server\traffic that we can test a 65k++*2
or 3 it will help SMP development.
I would not suggest this yet to any sane admin that want to sleep at night.
the NANOG had a nice guy that suggested the next phrase:
"get into a cisco BGP device from a linux using screen and print the
whole BGP sessions and many other info that on the main ram of the
device and let the screen run and run and run in the background while
you are not seeing it but dont let anyone know that you did that and see
what happens.."
I assume he tried it..
Eliezer
Received on Tue Sep 03 2013 - 20:36:27 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 04 2013 - 12:00:05 MDT