Aleksey Tsalolikhin a écrit :
[my server] ---pptp--> [VPN server] --> website
Where is the squid proxy ?
There is none. Instead of going through squid, the packets must go
through the VPN.
IIUC, the PPTP server acts as a router and forwards the packets to their
destination.
There is some kind of transparent proxy in the VPN,
because when I route packets destined to a particular website (by
static route using the website's IP address) via the VPN server, the
webserver records HTTP access from the VPN server.
Maybe it's not transparent proxy but plain source NAT/masquerading.
If I traceroute to the IP address that I believe is the PPTP server, I
can see the last two hops with that same address :
17 69.15.192.18 176.584 ms 175.154 ms 176.838 ms
18 69.15.192.18 [open] 176.160 ms 2855.959 ms *
This could mean that the address belongs to a NAT device which forwards
the PPTP session to the actual PPTP server behind it. So when the PPTP
server forwards the packets to the HTTP server through the NAT device,
they are masqueraded with the NAT device address.
Ok. Here is my trouble: Connection times out.
# telnet www.google.com 80
Trying 74.125.93.99...
telnet: connect to address 74.125.93.99: Connection timed out
Can you capture the network traffic on the PPTP interface of your server
(ppp0) e.g. using tcpdump or wireshark/tshark ? Then can you check
whether outgoing HTTP connection requests and replies go through this
interface ? Can you check what is the source address of the requests ?
If you didn't SNAT or MASQUERADE packets going out through the PPTP
tunnel, here is a possible scenario :
- telnet asks for a HTTP connection to 74.125.93.99.
- initial routing selects the output interface and default source
address according to the default route in the main routing table : eth0
and its address.
- rerouting due to the mark changes the output interface to ppp0 but
does not alter the source address.
- the packet travels through the PPTP tunnel to the PPTP server.
Depending on the PPTP server's behaviour, a lot of different scenarios
may then happen. Here are some.
1a) the PPTP server sees a source address different from the remote
endpoint address and drops the packet because of rp_filter=1 or iptables
filtering. So the connection times out.
1b) or the server does not care about the source address and forwards
the packet to the HTTP server. So far so good.
2a) The PPTP server is not behind a NAT device and does not do SNAT or
masquerading itself, so the packet reaches the HTTP server with its
original source address.
3a) The HTTP server sends a reply to this address, so the packet arrives
to your box on eth0. You may want to check this with a packet sniffer.
If you don't drop the packet because of rp_filter or iptables, the
connection should work.
This is not what seems to happen however, as you wrote that the server
sees the PPTP server's address and the connection times out.
2b) Or the PPTP server is behind a NAT device or does SNAT or
masquerading itself, so the packet reaches the HTTP server with the
source address of the PPTP server or its NAT device.
3b) The HTTP server sends a reply to this address, so the packet arrives
to the PPTP server (or its NAT device). It is un-masqueraded so its
destination is now your eth0's address. The PPTP server then forwards
the packet back to its destination, i.e. your box.
4a) If the PPTP server is not behind a NAT device and does not do "dumb"
SNAT/masquerading itself, the source address of the reply packet is not
altered. The packet reaches eth0 on your box and the connection should
work unless you filter too hard. Check with a packet sniffer on eth0.
4b) If the PPTP server is behind a NAT device, note that the device did
not see the request packet which was encapsuled in the PPTP tunnel, so
it considers the reply packet as a "new" connection and masquerades it.
The reply arrives at your box with the wrong source address and is
discarded.
4c) Alternatively, the NAT device seeing the reply packet without seeing
the request packets may consider it invalid and drop it. End of the journey.
The problem in this scenario is that the reply packet does not travel
trough the PPTP tunnel because you didn't use ppp0's address as source
address.
As a test, you can try to force the source address in the telnet command
line :
$ telnet -b 192.168.2.131 www.google.com 80
If it works, you know what to do : SNAT or MASQUERADE on ppp0.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
