Re: [squid-users] transparent proxy in squid3

Dear Amos,

On Sun, Mar 4, 2012 at 9:44 PM, Amos Jeffries <squid3_at_treenet.co.nz> 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):

19:20:32.892968 LLDP, name HP10e1, length 175
        [|LLDP]
19:21:02.893220 LLDP, name HP10e1, length 175
        [|LLDP]
19:21:32.926454 LLDP, name HP10e1, length 175
        [|LLDP]
19:22:02.926704 LLDP, name HP10e1, length 175
        [|LLDP]
19:22:32.926953 LLDP, name HP10e1, length 175
        [|LLDP]
19:23:02.926954 LLDP, name HP10e1, length 175
        [|LLDP]

>
> Does Squid already have a cached copy of the URL object being used as a
> test?

There is nothing in access.log

In store.log, there were something like:
1330884676.947 RELEASE -1 FFFFFFFF EF04955C9C3C77E5D1B6FF62A7A3FCD3
200 1330881076 1330881076 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330888276.971 RELEASE -1 FFFFFFFF 68D3201BA065E81CE2C8EBCAFA5A09B7
200 1330884676 1330884676 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330891876.995 RELEASE -1 FFFFFFFF CD3C59C716DCC1044CB8CA3FDAA5FA87
200 1330888276 1330888276 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330901292.051 RELEASE -1 FFFFFFFF 4C1B76CACC62E006B31038BD1ECA0E6C
200 1330897692 1330897692 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330904892.075 RELEASE -1 FFFFFFFF 7C594B62FAFC7F6E089C2AB00A12F3DD
200 1330901292 1330901292 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330908492.099 RELEASE -1 FFFFFFFF 7A850805E7A84AE3F1E4F6F459C808E4
200 1330904892 1330904892 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330912092.123 RELEASE -1 FFFFFFFF AB296C5B26704A2C167005139C0A42C1
200 1330908492 1330908492 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330915692.147 RELEASE -1 FFFFFFFF 20640CFA0B07E42FC24ADB3D87C57338
200 1330912092 1330912092 -1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest

Thanks a lot!

>
> Amos
Received on Mon Mar 05 2012 - 03:29:54 MST