Re: [squid-users] transparent proxy in squid3

On 5/03/2012 4:29 p.m., pplive wrote:
> Dear Amos,
>
> On Sun, Mar 4, 2012 at 9:44 PM, Amos Jeffries wrote:
>> On 05.03.2012 06:40, pplive wrote:
>>> Dear Amos,
>>>
>>> Thanks a lot! By looking at your URL, I have enter the following
>>> commands in my squid3 machine (my HTTP service is at PORT 8080), the
>>> squid3 proxy machine is at 10.0.3.1, HTTP server (noder) is at
>>> 10.0.2.1, HTTP client (nodes) is at 10.0.1.1:
>>>
>>> yeung_at_nodec1:~$ sudo iptables -t nat -A PREROUTING -s 10.0.3.1 -p tcp
>>> --dport 8080 -j ACCEPT
>>> yeung_at_nodec1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080
>>> -j DNAT --to-destination 10.0.3.1:3128
>>> yeung_at_nodec1:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
>>> yeung_at_nodec1:~$ sudo iptables -t mangle -A PREROUTING -p tcp --dport
>>> 3128 -j DROP
>>>
>> <snip>
>>
>>
>>> However, the proxy still has some problem, when we start wget from the
>>> HTTP client
>>> yeung_at_nodes:~$ wget 10.0.2.1:8080
>>> --2012-03-04 09:31:39-- http://10.0.2.1:8080/
>>> Connecting to 10.0.2.1:8080... ^C
>>
>> So far good (modulo the testing with port-8080 factor).
>>
>>
>>> yeung_at_nodes:~$
>>>
>>> We look at the TCPDUMP result at squid3 machine (10.0.3.1), we see the
>>> following message:
>>> 09:31:39.384558 IP nodes-links.51902> noder-linkr.http-alt: Flags
>>> [S], seq 2501418596, win 5840, options [mss 1460,sackOK,TS val
>>> 38022185 ecr 0,nop,wscale 6], length 0
>>> 09:31:42.379034 IP nodes-links.51902> noder-linkr.http-alt: Flags
>>> [S], seq 2501418596, win 5840, options [mss 1460,sackOK,TS val
>>> 38022935 ecr 0,nop,wscale 6], length 0
>>>
>>> It seems that there were some HTTP-alt traffic coming in from the
>>> switch, but no HTTP traffic going out of the squid3 machine.
>>>
>> Is this a dump of all packets involving port 8080? or did you add an IP
>> address or interface direction to hide some packets?
> Yes, I use 'sudo tcpdump -i eth0', and I have skip some LLDP messages
> as follows (as the squid3 machine is connected to a programmable
> switch):

>> Does Squid already have a cached copy of the URL object being used as a
>> test?
> There is nothing in access.log

I'm thinking it is probably something in the kernel security controls
then. SELinux can block interception because it is an MITM attack on the
clients. Also rp_filter can block the TCP connections in strange places
and show up like this. Did you restart the networking on the squid box
after changing sysctl.conf (/etc/init.d/networking restart)

Amos
Received on Mon Mar 05 2012 - 09:56:06 MST