Search squid archive

Re: Re: transparent proxy on remote box issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/11/2013 9:46 p.m., WorkingMan wrote:
I have confidence that we can get to the bottom of this with this level
of
details.
I am currently stuck at this step:

VPN Server - > Web Site (SQUID's mac)

This was also where I was stuck before. At this point I am simply
issuing a
curl
www.cnn.com from VPN server (VPN client/SQUID not involved)

If I follow: http://www.tldp.org/HOWTO/TransparentProxy-6.html
What happens is that it says use DNAT/SNAT + policy routing and that in
the end
didn't do any policy routing since MAC address to the web site didn't
point to
SQUID's mac address.
Okay please drop that how-to. It is for a completely different network
topology than your diagram showed.

If I follow http://wiki.squid-
cache.org/ConfigExamples/Intercept/IptablesPolicyRoute.
Mac address of web site is SQUID's mac address but somewhere I get
packet loss
because it just keeps retransmitting the same http request. I had to add
one
extra
rule to arrive to this behavior (see below).
There are several use-case configurations in that page.
You need the one under "When Squid is in a DMZ between the router and
Internet".

There is no traffic going to SQUID other than ARP (for getting mac
address).
One hint I had was that the traffic are not marked correctly.

This line if added (I got it from somewhere online) will change the mac
address
of
the web site to be the one of SQUID:

iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-
mark 2
OUTPUT ???   none of the routing tutorials you have been looking at
mention doing anything in OUTPUT.

*PREROUTING* table  (as in the "before routing" table of rules) is the
one you should be altering on the VPN server.

- Reset the VPN server config from these changes,
- go back to
http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute.
- follow the section "When Squid is in a DMZ between the router and
Internet"
- follow the section "Routing Setup"
- then re-run the 4 tests I outlined for this stage of configuration.

With that rule:
06:13:38.327212 0a:a5:82:f8:2e:93 (VPN's mac)> 0a:3c:e1:08:45:b7
(SQUID's mac),
IPv4, length 74: 10.0.0.170.57525 > 157.166.248.10.80 (web site): tcp 0

Without that rule:
06:01:59.823267 0a:a5:82:f8:2e:93 (VPN's mac) > 0a:ee:81:f6:13:ef
(SQUID's
mac),
IPv4, length 66: 10.0.0.170.43154 > 157.166.249.11.80 (web site): tcp 0
Easily explained. MARK are not set on the packet, they are flags in the
kernel metadata about a connection.
I'm doubt if they show up in a tcpdump, but they definitely will not
leave the machine they are used on.

On SQUID I followed this: http://wiki.squid-
cache.org/ConfigExamples/Intercept/LinuxRedirect
There is no traffic going to SQUID according to tshark (unless there is
just
not
showing up) so we can ignore this for now.
Rewind. That is steaming on way ahead of where things are broken.

Amos



I followed DMZ + policy routing and it still same result (tested with VPN
client).

*mangle
:PREROUTING ACCEPT [383:47877]
:INPUT ACCEPT [311:32547]
:FORWARD ACCEPT [149:20258]
:OUTPUT ACCEPT [302:67329]
:POSTROUTING ACCEPT [451:87587]
[77:4928] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j MARK --set-xmark
0x2/0xffffffff
[77:4928] -A PREROUTING -m mark --mark 0x2 -j ACCEPT
COMMIT
# Completed on Sat Nov  2 08:30:56 2013
# Generated by iptables-save v1.4.18 on Sat Nov  2 08:30:56 2013
*nat
:PREROUTING ACCEPT [13:864]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [5:354]
:POSTROUTING ACCEPT [0:0]
[18:1218] -A POSTROUTING -o eth0 -j MASQUERADE

Source-NATing the outbound traffic.

I take it this is intended to happen on the traffic back to the client network? If so, try adding the parameter: -d 10.100.0.0/16 so only that client reply traffic is NAT'ed.

COMMIT
# Completed on Sat Nov  2 08:30:56 2013
# Generated by iptables-save v1.4.18 on Sat Nov  2 08:30:56 2013
*filter
:INPUT ACCEPT [311:32547]
:FORWARD ACCEPT [149:20258]
:OUTPUT ACCEPT [313:68601]
COMMIT

ip route list table http
default via 10.0.0.117 dev eth0

ip rule show
0:      from all lookup local
219:    from all fwmark 0x2 lookup http
220:    from all lookup 220
32766:  from all lookup main
32767:  from all lookup default

ip route
default via 10.0.0.1 dev eth0
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.170

Can you make this work on your end?

My wireless POP have a wifi link where yours has a VPN link. But otherwise the same as what you seem to be trying to setup. There is a subtle difference in your 10.0.0.0/24 being in a cloud though. Mine are physical Ethernet between CPE.

Amos




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux