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_at_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 <p2pnet10_at_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 <squid3_at_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 "DROP"ed 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
Received on Tue Mar 06 2012 - 22:00:50 MST
This archive was generated by hypermail 2.2.0 : Wed Mar 07 2012 - 12:00:02 MST