Home
Wednesday, April 26, 2017
5:59:09 PM
Users online: 0   You are here >> Home > Open Source OS

Forums | Open Source OS Forums search
Forum FAQ
   
  1  
iptables and squid transparant proxy
robzy 
7/8/08 11:47:55 PM
Hero
Immortal


I'm trying to figure out how squid transparent proxy is operating, the iptables line I'm using is:
iptables -t nat -A PREROUTING -s 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-port 3128

Using wireshark on a client I can see that incoming HTTP packet's TCP field give the IP of the web server being access (which is expected, since its a transperant proxy).

I use this command to log the squid packets as (i think) they leave my system:
iptables -A OUTPUT -d 192.168.1.3 -j LOG -p tcp --sport ! 22 --log-prefix "probsquid: "

And that shows up a lot of packets along the lines of:
Aug  7 23:46:34 cookiemonster probsquid: IN= OUT=eth0 SRC=192.168.1.6 DST=192.168.1.3 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=63133 DF PROTO=TCP SPT=3128 DPT=223 
7 WINDOW=14600 RES=0x00 ACK URGP=0

(3128 being the port that squid is running on)

I am curious though, if in the output chain the packet still has SRC of 192.168.1.6, at what point does it get changed to the URL of the server before being sent to 192.168.1.3?

Rob.


Edited by robzy: 8/8/2008 2:00:00 AM

-----
עם ישראל חי

GlennsPref 
8/8/08 10:30:51 AM
Champion

I have no idea, but as far as config for iptables and squid, I've been doing a little of that.

Some excelent docs...

iptables
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_ipta


squid
http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch32_:_Controlling_Web_Access_wit


I have ppp0 as the external connection and is dhcp
eth0 192.168.0.2 is the internal connection to 192.168.0.3

I have the browser settings(on my machine) adjusted to point to the (on board) proxy, so my machine is both proxy, gateway and my computer.
Don't do that for the client(s) though.

<edit> In effect to access the web from my machine, the pathway would be...
browser to eth0 (192.168.0.2) and the proxy, then the proxy updates any changes from ppp0 which is the external connection.

The other machine (192.168.0.3) is connected to eth0 (192.168.0.2) and hits the proxy the same way.</edit>gw


Edited by GlennsPref: 8/8/2008 10:55:16 AM

I found this, using tshark... http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch04_:_Simple_Network_Troubleshoo

Viewing Packet Flows with tshark

The tshark program is of the Fedora Linux wireshark RPM. It used to be called tethereal and came as part of the tethereal package, and many texts refer to it by its old name.

The tshark command-line options and screen output mimic that of tcpdump in many ways but tshark has a number of advantages.

The tshark command has the ability of dumping data to a file like tcpdump and creating new files with new filename extensions when a size limit has been reached. It can additionally limit the total number of files created before overwriting the first one in the queue, which is also known as a ring buffer.

The tshark screen output is also more intuitive to read, though the dump file format is identical to tcpdump.

Table 4-4 and Table 4-5 show some popular command switches and expressions that can be used with tshark.


Table 4-4 : Possible tshark Switches



there's more on the page...

;)


Edited by GlennsPref: 8/8/2008 10:59:37 AM

-----
Regards, Glenn

Linux user #406321 (Mandriva)
register @ http://counter.li.org/
GlennsPref@gmail.com

sponger 
8/8/08 10:50:42 AM
Immortal

POSTROUTING?

-----

wilsontc 
8/8/08 10:55:15 AM
Guru

I think the whole idea is that it doesn't.

I was under the impression that transparent implies no configuration necessary on the client (you still need the firewall rules).

So what you should see is this: Client browses to www.google.com. This packet has dst of www.google.com. Then it gets redirected to 192.168.1.3:3128. The proxy server examines it's cache. It can't find anything.

Now at this point I think you're expecting the proxy to say "Sorry, I don't have it! You'll get it yourself". But the proxy fetches it instead, and then passes it to the client.

The idea is that the client never makes web requests directly (other than for SSL).

Does this answer your question? I'm sure www.squid-cache.org has some documentation about 'how squid works' that would give you a more exact answer than that I can provide.

-----
Quote by Kothos
More importantly, do any of you girls like arse hair??



wilsontc 
8/8/08 10:56:48 AM
Guru

whoops


Edited by wilsontc: 8/8/2008 10:57:59 AM

-----
Quote by Kothos
More importantly, do any of you girls like arse hair??



wilsontc 
8/8/08 10:57:38 AM
Guru

whoops

-----
Quote by Kothos
More importantly, do any of you girls like arse hair??



robzy 
8/8/08 11:57:57 AM
Hero
Immortal


Quote by sponger
POSTROUTING?


There is no POSTROUTING chain in the filter table, and there is nothing coming through the nat tables POSTROUTING (well, not from squid anyways).

Quote by wilsontc
Does this answer your question?


Not at all actually :P But I think that's my fault as it's worded very badly.

Bottom line: I want to catch squid's packets just before they leave the server and go to my client machine.

Using wireshark on my client machine I know that these packets have a SRC of 209.85.171.99 (for instance).

In order to capture these packets, I tried looking in the filter table's OUTPUT chain - but at this point all of the packets had a SRC of 192.168.1.6 (the servers IP address).

I want to know when (most likely in between the OUTPUT chain and the client PC) the packets are changed to the SRC that the client thinks it's talking to. And furthermore - how to construct a rule to catch them with iptables.

Rob.

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

wilsontc 
8/8/08 12:17:20 PM
Guru

Quote by robzy
Quote by sponger
POSTROUTING?


There is no POSTROUTING chain in the filter table, and there is nothing coming through the nat tables POSTROUTING (well, not from squid anyways).

Quote by wilsontc
Does this answer your question?


Not at all actually :P But I think that's my fault as it's worded very badly.

Bottom line: I want to catch squid's packets just before they leave the server and go to my client machine.

Using wireshark on my client machine I know that these packets have a SRC of 209.85.171.99 (for instance).

In order to capture these packets, I tried looking in the filter table's OUTPUT chain - but at this point all of the packets had a SRC of 192.168.1.6 (the servers IP address).

I want to know when (most likely in between the OUTPUT chain and the client PC) the packets are changed to the SRC that the client thinks it's talking to. And furthermore - how to construct a rule to catch them with iptables.

Rob.



Well, that's actually my point. The client should never have a packet with SRC 209.85.171.99; as soon as an http request is made, the client stops talking directly (well, semi directly thanks to NAT) to the website and all communication is passed through to the proxy.

So you should really only be seeing packets from the proxy to the client. It's all local traffic. That's how I thought it worked, so correct me if necessary.

-----
Quote by Kothos
More importantly, do any of you girls like arse hair??



robzy 
8/8/08 12:34:51 PM
Hero
Immortal


Quote by wilsontc
Well, that's actually my point. The client should never have a packet with SRC 209.85.171.99; as soon as an http request is made, the client stops talking directly (well, semi directly thanks to NAT) to the website and all communication is passed through to the proxy.


By "client" I mean squid's client, the desktop computer. And since it's a transparent proxy, it means that to the client all the packets will appear to be coming from the webserver, when in actual fact its squid handling them.

[edit]: And a small thing to note, Wireshark in the server reports the packets leaving the machine (from squid) to the client come from SRC 209.85.171.99.

So, somewhere between the output chain - and where ever Wireshark listens to them (the interface level, right?) the SRC is changed from 192.168.1.6 to 209.85.171.99 (or the webservers IP)

Rob.


Edited by robzy: 8/8/2008 12:47:22 PM

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

robzy 
8/8/08 12:47:03 PM
Hero
Immortal


[edit]: Gah, silly me.


Edited by robzy: 8/8/2008 12:47:16 PM

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

luser 
8/8/08 12:49:47 PM
Overlord

The log rule is wrong. When the client (squid) connects to the web server you're accessing, the destination won't be 192.168.1.3 anymore. It will be the address of the web server. Try:

iptables -A OUTPUT -p tcp --dport 80 -j LOG --log-prefix "probsquid: "

instead.

-----
It's gonna be a glorious day!
I feel my luck could change.

robzy 
8/8/08 12:51:33 PM
Hero
Immortal


Quote by luser
The log rule is wrong. When the client (squid) connects to the web server you're accessing, the destination won't be 192.168.1.3 anymore. It will be the address of the web server. Try:

iptables -A OUTPUT -p tcp --dport 80 -j LOG --log-prefix "probsquid: "

instead.


Nono, I'm wanting to capture the packets that squid sends to the clients (not to the webserver). I want to catch them with SRC=209.85.171.99 though.

Rob.

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

wilsontc 
8/8/08 12:51:57 PM
Guru

Quote by robzy
Quote by wilsontc
Well, that's actually my point. The client should never have a packet with SRC 209.85.171.99; as soon as an http request is made, the client stops talking directly (well, semi directly thanks to NAT) to the website and all communication is passed through to the proxy.


By "client" I mean squid's client, the desktop computer. And since it's a transparent proxy, it means that to the client all the packets will appear to be coming from the webserver, when in actual fact its squid handling them.

[edit]: And a small thing to note, Wireshark in the server reports the packets leaving the machine (from squid) to the client come from SRC 209.85.171.99.

So, somewhere between the output chain - and where ever Wireshark listens to them (the interface level, right?) the SRC is changed from 192.168.1.6 to 209.85.171.99 (or the webservers IP)

Rob.


Edited by robzy: 8/8/2008 12:47:22 PM




Ah cheers, thanks.

-----
Quote by Kothos
More importantly, do any of you girls like arse hair??



eckythump 
8/8/08 7:40:39 PM
Overlord

heh, yikes.

Just to clarify here... is the actual transparent proxying working, and it's just the logging side of thing that's giving you grief?

Are squid's own logs insufficient?

-----
"Grandfather had an accident, he got burnt." "Oh no, how bad?" "Well, they don't fuck around at the crematorium."

robzy 
8/8/08 7:53:02 PM
Hero
Immortal


Quote by eckythump
Are squid's own logs insufficient?


In actual fact, squids own logs are better as they will actually tell me whether the data fetched was from the server or from cache.

However, this is more succinct, as it can log all traffic in one handy-to-see place.

And now that it's become a challenge, I cant just let it go :P

Rob.

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

TheSecret 
8/8/08 9:10:07 PM
Master
Robzy,

What you are asking is impossible with iptables. The source IP is modified by the linux kernel just before it leaves the machine, it is the very last step before transmitting, after iptables has already finished it's bit.

If you want to verify it is leaving the machine with a modified source ip, you can download and run ebtables to check.

-----
Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest.

robzy 
9/8/08 2:10:27 AM
Hero
Immortal


Quote by TheSecret
What you are asking is impossible with iptables. The source IP is modified by the linux kernel just before it leaves the machine, it is the very last step before transmitting, after iptables has already finished it's bit.


Seriously? Correct me if I'm wrong but that's a pretty stupid design :P

After all, it is iptables redirects the packets in the first place.

Rob.

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

TheSecret 
9/8/08 11:54:48 AM
Primarch
Maybe you should better understand the design, before criticizing.

http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png

Why not just verify this for yourself by using ebtables?

-----
Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest.

robzy 
9/8/08 12:13:59 PM
Hero
Immortal


Quote by TheSecret
Maybe you should better understand the design, before criticizing.

http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png


Sorry, to be perfectly honest it wasn't so much a criticism than hoping someone would explain why it is - as yes, I'm sure there's a reason.

Granted, I really could have phrased it better.

Thanks for the linkage.

Rob.

-----
&#1506;&#1501; &#1497;&#1513;&#1512;&#1488;&#1500; &#1495;&#1497;

  1  
Forums | Open Source OS