Re: [squid-users] transparent proxy in squid3

2012-03-06 Thread pplive
Dear Amos,

Finally I have solved the problem!

The thing is, when I redirect the http.alt packet from the switch, I
need to modify the dst mac address as the mac address of the squid3
machine.

After doing this, a simple command works as follows:

yeung@nodec1:/var/log/squid3$ sudo iptables -t nat -A PREROUTING -p
tcp --dport 8080 -j REDIRECT --to-port 3128

THanks a lot for your strong help!

Best,
Alex


On Mon, Mar 5, 2012 at 10:30 PM, pplive p2pne...@googlemail.com wrote:
 Dear Amos,

 Thanks for your great hint of tcpdump gets packets before any of the
 iptables etc handling gets done to them and  We have to rely on
 ebtables/iptables LOG functionality for those bits

 Now I start debugging iptables, using
 sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
 --log-prefix TEST: 

 from node-s (sender), we run [node-s (sender), 10.0.1.1, node-r,
 10.0.2.1 (receiver), the squid3 machine is 10.0.3.1]

 wget 10.0.2.1:8080

 while we still see
 19:20:09.439059 IP nodes-links.40520  noder-linkr.http-alt: Flags
 [S], seq 4014254024, win 5840, options [mss 1460,sackOK,TS val
 68449700 ecr 0,nop,wscale 6],
 in tcpdump, we see nothing in the iptables log

 in contrast, if we run 'wget 10.0.3.1:8080' (directly connect to 8080
 port of squid3 machine, although there is no service)
 we see information in both tcpdump
 19:26:51.347175 IP nodes-links.41022  nodec1-tblink-l9.http-alt:
 Flags [S], seq 1779139991, win 5840, options [mss 1460,sackOK,TS val
 68550176 ecr 0,nop,wscale 6], length 0
 19:26:51.347287 IP nodec1-tblink-l9.http-alt  nodes-links.41022:
 Flags [R.], seq 0, ack 1779139992, win 0, length 0
 
 and iptables log
 
 Mar  5 19:24:09 nodec1 kernel: [28094.303462] TEST: IN=eth0 OUT=
 MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
 DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
 SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
 Mar  5 19:24:09 nodec1 kernel: [28094.303495] TEST: IN=eth0 OUT=
 MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
 DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
 SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
 

 Can we conclude the error was happened due to
 sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
 --log-prefix TEST: 
 cannot pick up the 8080 packet forwarded by the switch? Can some
 packet loss happen before this step?

 I am sorry I am not very familiar with the linux kernel/system...and
 bother you so much trouble...

 Thanks a lo!

 On Mon, Mar 5, 2012 at 5:57 PM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 06.03.2012 11:09, pplive wrote:

 Dear Amos,

 To see whether there were some internal firewall in my system , I
 tried a simpler topology, i.e.,

 Client (10.0.0.1) (eth0) - (eth0) Squid3 (eth1) - (eth0) Server
 (10.0.0.2)

 I just follow the setting in


 http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables

 brctl addbr br0
 brctl addif br0 eth0
 brctl addif br0 eth1

 ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6
 --ip-destination-port 8080 -j redirect --redirect-target ACCEPT


 ACCEPT on the layer-2 bridging is to handle the packet entirely at that
 low layer.

 It needs to be DROPed out of the bridging layer into to iptables layer
 handling before NAT can change the IP/port and routing can shift it to INPUT
 path where Squid gets it.




 iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j REDIRECT
 --to-port 3128

 According to tcpdump, we can see the packets are forwarded to port 3128
 (I use wget 10.0.0.2:8080 at the client)

 14:04:50.282381 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
 388132433, win 5840, options [mss 1460,sackOK,TS val 1028407 ecr
 0,nop,wscale 6], length 0
 14:04:53.212426 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
 388132433, win 5840, options [mss 1460,sackOK,TS val 1029157 ecr
 0,nop,wscale 6], length 0

 Still, I am confusing of using one NIC, how can I redirect the packets
 to port 3128.


 NAT is a special system which can change packets on both bridging and
 routing layers but does not itself make them change layer.

  So what the above trace shows is that packets arriving are NAT/NAPT changed
 as they flow through the bridge. But not anything else.


 tcpdump gets packets before any of the iptables etc handling gets done to
 them. So its useful to verify that the packets are arriving and/or leaving
 the NIC as expected. but not much help deciphering what is happening to them
 in the middle around where Squid sits.
  We have to rely on ebtables/iptables LOG functionality for those bits.


 I'm sorry I can't be of much more help. Beyond suggesting to try later
 versions of the software including kernel I've run out of ideas.

 Amos


Re: [squid-users] transparent proxy in squid3

2012-03-05 Thread pplive
Dear Amos,

I did restart the networking.

When I just to review all iptables settings, from tcpdump we can see

09:35:23.830038 IP nodes-links.37711  noder-linkr.http-alt: Flags
[S], seq 3652549612, win 5840, options [mss 1460,sackOK,TS val
59678297 ecr 0,nop,wscale 6], length 0
09:35:26.827763 IP nodes-links.37711  noder-linkr.http-alt: Flags
[S], seq 3652549612, win 5840, options [mss 1460,sackOK,TS val
59679047 ecr 0,nop,wscale 6], length 0
09:35:28.828079 ARP, Request who-has noder-linkr tell nodes-links, length 46

I think the nodec1 (my squid3 machine) is even able to start an ARP query.

My OS is Ubuntu, kernel version
yeung@nodec1:/etc/squid3$ uname -r
2.6.32-34-generic-pae

I have checked the rp_filter setting, it has been disabled.

Sorry for causing you trouble.

Best,
Alex


On Mon, Mar 5, 2012 at 4:56 AM, Amos Jeffries squ...@treenet.co.nz wrote:
 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@nodec1:~$ sudo iptables -t nat -A PREROUTING -s 10.0.3.1 -p tcp
 --dport 8080 -j ACCEPT
 yeung@nodec1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080
 -j DNAT --to-destination 10.0.3.1:3128
 yeung@nodec1:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
 yeung@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@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@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


Re: [squid-users] transparent proxy in squid3

2012-03-05 Thread pplive
Dear Amos,

To see whether there were some internal firewall in my system , I
tried a simpler topology, i.e.,

Client (10.0.0.1) (eth0) - (eth0) Squid3 (eth1) - (eth0) Server (10.0.0.2)

I just follow the setting in
http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables

brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1

ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6
--ip-destination-port 8080 -j redirect --redirect-target ACCEPT

iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j REDIRECT
--to-port 3128

According to tcpdump, we can see the packets are forwarded to port 3128
(I use wget 10.0.0.2:8080 at the client)

14:04:50.282381 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
388132433, win 5840, options [mss 1460,sackOK,TS val 1028407 ecr
0,nop,wscale 6], length 0
14:04:53.212426 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
388132433, win 5840, options [mss 1460,sackOK,TS val 1029157 ecr
0,nop,wscale 6], length 0

Still, I am confusing of using one NIC, how can I redirect the packets
to port 3128.

Thanks a lot!

Best regards,
Alex

On Mon, Mar 5, 2012 at 4:19 PM, pplive p2pne...@googlemail.com wrote:
 Dear Amos,

 I did restart the networking.

 When I just to review all iptables settings, from tcpdump we can see

 09:35:23.830038 IP nodes-links.37711  noder-linkr.http-alt: Flags
 [S], seq 3652549612, win 5840, options [mss 1460,sackOK,TS val
 59678297 ecr 0,nop,wscale 6], length 0
 09:35:26.827763 IP nodes-links.37711  noder-linkr.http-alt: Flags
 [S], seq 3652549612, win 5840, options [mss 1460,sackOK,TS val
 59679047 ecr 0,nop,wscale 6], length 0
 09:35:28.828079 ARP, Request who-has noder-linkr tell nodes-links, length 46

 I think the nodec1 (my squid3 machine) is even able to start an ARP query.

 My OS is Ubuntu, kernel version
 yeung@nodec1:/etc/squid3$ uname -r
 2.6.32-34-generic-pae

 I have checked the rp_filter setting, it has been disabled.

 Sorry for causing you trouble.

 Best,
 Alex


 On Mon, Mar 5, 2012 at 4:56 AM, Amos Jeffries squ...@treenet.co.nz wrote:
 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@nodec1:~$ sudo iptables -t nat -A PREROUTING -s 10.0.3.1 -p tcp
 --dport 8080 -j ACCEPT
 yeung@nodec1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080
 -j DNAT --to-destination 10.0.3.1:3128
 yeung@nodec1:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
 yeung@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@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@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


Re: [squid-users] transparent proxy in squid3

2012-03-05 Thread pplive
Dear Amos,

Thanks for your great hint of tcpdump gets packets before any of the
iptables etc handling gets done to them and  We have to rely on
ebtables/iptables LOG functionality for those bits

Now I start debugging iptables, using
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
--log-prefix TEST: 

from node-s (sender), we run [node-s (sender), 10.0.1.1, node-r,
10.0.2.1 (receiver), the squid3 machine is 10.0.3.1]

wget 10.0.2.1:8080

while we still see
19:20:09.439059 IP nodes-links.40520  noder-linkr.http-alt: Flags
[S], seq 4014254024, win 5840, options [mss 1460,sackOK,TS val
68449700 ecr 0,nop,wscale 6],
in tcpdump, we see nothing in the iptables log

in contrast, if we run 'wget 10.0.3.1:8080' (directly connect to 8080
port of squid3 machine, although there is no service)
we see information in both tcpdump
19:26:51.347175 IP nodes-links.41022  nodec1-tblink-l9.http-alt:
Flags [S], seq 1779139991, win 5840, options [mss 1460,sackOK,TS val
68550176 ecr 0,nop,wscale 6], length 0
19:26:51.347287 IP nodec1-tblink-l9.http-alt  nodes-links.41022:
Flags [R.], seq 0, ack 1779139992, win 0, length 0

and iptables log

Mar  5 19:24:09 nodec1 kernel: [28094.303462] TEST: IN=eth0 OUT=
MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0
Mar  5 19:24:09 nodec1 kernel: [28094.303495] TEST: IN=eth0 OUT=
MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1
DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP
SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0


Can we conclude the error was happened due to
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG
--log-prefix TEST: 
cannot pick up the 8080 packet forwarded by the switch? Can some
packet loss happen before this step?

I am sorry I am not very familiar with the linux kernel/system...and
bother you so much trouble...

Thanks a lo!

On Mon, Mar 5, 2012 at 5:57 PM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 06.03.2012 11:09, pplive wrote:

 Dear Amos,

 To see whether there were some internal firewall in my system , I
 tried a simpler topology, i.e.,

 Client (10.0.0.1) (eth0) - (eth0) Squid3 (eth1) - (eth0) Server
 (10.0.0.2)

 I just follow the setting in


 http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables

 brctl addbr br0
 brctl addif br0 eth0
 brctl addif br0 eth1

 ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6
 --ip-destination-port 8080 -j redirect --redirect-target ACCEPT


 ACCEPT on the layer-2 bridging is to handle the packet entirely at that
 low layer.

 It needs to be DROPed out of the bridging layer into to iptables layer
 handling before NAT can change the IP/port and routing can shift it to INPUT
 path where Squid gets it.




 iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j REDIRECT
 --to-port 3128

 According to tcpdump, we can see the packets are forwarded to port 3128
 (I use wget 10.0.0.2:8080 at the client)

 14:04:50.282381 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
 388132433, win 5840, options [mss 1460,sackOK,TS val 1028407 ecr
 0,nop,wscale 6], length 0
 14:04:53.212426 IP 10.0.0.1.33088  10.0.0.10.3128: Flags [S], seq
 388132433, win 5840, options [mss 1460,sackOK,TS val 1029157 ecr
 0,nop,wscale 6], length 0

 Still, I am confusing of using one NIC, how can I redirect the packets
 to port 3128.


 NAT is a special system which can change packets on both bridging and
 routing layers but does not itself make them change layer.

  So what the above trace shows is that packets arriving are NAT/NAPT changed
 as they flow through the bridge. But not anything else.


 tcpdump gets packets before any of the iptables etc handling gets done to
 them. So its useful to verify that the packets are arriving and/or leaving
 the NIC as expected. but not much help deciphering what is happening to them
 in the middle around where Squid sits.
  We have to rely on ebtables/iptables LOG functionality for those bits.


 I'm sorry I can't be of much more help. Beyond suggesting to try later
 versions of the software including kernel I've run out of ideas.

 Amos


Re: [squid-users] transparent proxy in squid3

2012-03-04 Thread pplive
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@nodec1:~$ sudo iptables -t nat -A PREROUTING -s 10.0.3.1 -p tcp
--dport 8080 -j ACCEPT
yeung@nodec1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080
-j DNAT --to-destination 10.0.3.1:3128
yeung@nodec1:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
yeung@nodec1:~$ sudo iptables -t mangle -A PREROUTING -p tcp --dport
3128 -j DROP

yeung@nodec1:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
ACCEPT tcp  --  nodec1-tblink-l9 anywheretcp dpt:http-alt
DNAT   tcp  --  anywhere anywheretcp
dpt:http-alt to:10.0.3.1:3128

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
MASQUERADE  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

yeung@nodec1:~$ sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
DROP   tcp  --  anywhere anywheretcp dpt:3128

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination

However, the proxy still has some problem, when we start wget from the
HTTP client
yeung@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
yeung@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.

I am really sorry for continuing this problem.

Best regards!

On Fri, Mar 2, 2012 at 7:39 PM, Amos Jeffries squ...@treenet.co.nz wrote:
 On 3/03/2012 12:51 p.m., pplive wrote:

 Dear all,

 I try to configure a transparent web proxy through squid 3, here is
 the network topology

 Users -  Switch -  Internet

 Users means a couple of PCs, all of them have public IP, all of them
 are connected to a switch. One PC among them is designed to be a proxy
 machine. The switch is programmable, thus for the TCP packets with
 destination address 80, it can be re-directed to the proxy machine.
 For other packets, it will be forwarded further to the Internet. The
 programmable switch has been tested and works well.

 The proxy machine has installed squid3, the listening port is 3128,
 and we have configure 'http_port 3128 transparent' in squid.conf . One
 problem is this machine has only one NIC (eth0), thus we can not use
 the method proposed in

 http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables
 (using a bridge)

 I have tried several iptable settings, such as

 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
 --to-port 3128
 iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to
 xx.yy.zz.ii:3128

 Neither of them works.


 There are several other iptables rules involved, along with sysctl
 requirements. See
 http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat

 the Squid 3.1 ptions is intercept for NAT interception proxy. Transparent
 proxy is something else.

 If you have any other problems after fixing all that check the switch is
 bypassing the redirect when the packets for port 80 come *out* of the squid
 box.

 Amos


Re: [squid-users] transparent proxy in squid3

2012-03-04 Thread pplive
Dear Amos,

On Sun, Mar 4, 2012 at 9:44 PM, Amos Jeffries squ...@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@nodec1:~$ sudo iptables -t nat -A PREROUTING -s 10.0.3.1 -p tcp
 --dport 8080 -j ACCEPT
 yeung@nodec1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 8080
 -j DNAT --to-destination 10.0.3.1:3128
 yeung@nodec1:~$ sudo iptables -t nat -A POSTROUTING -j MASQUERADE
 yeung@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@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@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  EF04955C9C3C77E5D1B6FF62A7A3FCD3
200 1330881076 1330881076-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330888276.971 RELEASE -1  68D3201BA065E81CE2C8EBCAFA5A09B7
200 1330884676 1330884676-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330891876.995 RELEASE -1  CD3C59C716DCC1044CB8CA3FDAA5FA87
200 1330888276 1330888276-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330901292.051 RELEASE -1  4C1B76CACC62E006B31038BD1ECA0E6C
200 1330897692 1330897692-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330904892.075 RELEASE -1  7C594B62FAFC7F6E089C2AB00A12F3DD
200 1330901292 1330901292-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330908492.099 RELEASE -1  7A850805E7A84AE3F1E4F6F459C808E4
200 1330904892 1330904892-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330912092.123 RELEASE -1  AB296C5B26704A2C167005139C0A42C1
200 1330908492 1330908492-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest
1330915692.147 RELEASE -1  20640CFA0B07E42FC24ADB3D87C57338
200 1330912092 1330912092-1 application/cache-digest 185/185
GET http://localhost:3128/squid-internal-periodic/store_digest

Thanks a lot!


 Amos


[squid-users] transparent proxy in squid3

2012-03-02 Thread pplive
Dear all,

I try to configure a transparent web proxy through squid 3, here is
the network topology

Users - Switch - Internet

Users means a couple of PCs, all of them have public IP, all of them
are connected to a switch. One PC among them is designed to be a proxy
machine. The switch is programmable, thus for the TCP packets with
destination address 80, it can be re-directed to the proxy machine.
For other packets, it will be forwarded further to the Internet. The
programmable switch has been tested and works well.

The proxy machine has installed squid3, the listening port is 3128,
and we have configure 'http_port 3128 transparent' in squid.conf . One
problem is this machine has only one NIC (eth0), thus we can not use
the method proposed in
http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables
(using a bridge)

I have tried several iptable settings, such as

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT
--to-port 3128
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to
xx.yy.zz.ii:3128

Neither of them works.

Use 'tcpdump -i eth0' on the proxy machine, we can see the first
packet of every HTTP request, forwarded by the switch, but nothing
else.

Could somebody provide me some hints on this? Thanks a lot!

Best regards,
Alex Chan