On 26/07/2012 4:50 p.m., Abhishek Chanda wrote:
Hi Amos,
Thanks for the reply.
My Squid is 3.1.19. I am trying to use OpenFlow to automate the
deployment of Squid in my organization. When the OpenFlow controller
sees a new HTTP packet, it modifies it's destination IP and port to
that of Squid and sends it back. Thus, I expected I will not need
iptable rules here.
I am a bit confused about how Squid does DNAT. Can you point me to
some document?
There is no document but the code.
Squid accept()'s a TCP connection. If the http_port is marked with
"intercept" it then performs a call to getsockopt(SO_ORIGINAL_DST)
asking the kernel for the NAT table record of that connections original
destination. That is all Squid-3.1 does, later series 3.2 has extra
security that validates that the HTTP details match the TCP ones and
ensures destination it is actually delivered to was the clients intended
destination.
Does OpenFlow controller update the Squid box kernel NAT tables so the
above can work? if not, how can Squid receive that original destination
info?
The behaviour you described in your first email hints that Squid is
receiving a connection which is addressed to itself on port 3128. Which
could very easily be relayed on to .. itself on port 3128... etc
I'm not clear what you meant by "register a MISS or HIT". I assume you
meant "log a MISS or HIT"? logging is not done on a transaction until it
has been completed and all timing details are known. In the case where
Squid forwards to itself, the request might never finish looping...
Amos
