Diagnosing Forwarding on pptpd

李某人

Diagnosing Forwarding on pptpd
by James Cameron
2007-10-18
Summarising the situation; clients can ping the IP address assigned to
their tunnel, but cannot ping anything beyond the server (the target).
Presumably also the server can ping the IP address assigned to the
client.
If that is the situation, then this is just a Linux routing and packet
forwarding problem.  It would happen with any network connection, not
only a tunnel.  Read on.
(note to self,  this is the situation)
Here's a simplified diagram, the blue line shows what we are aiming
to achieve - bidirectional packet flow between the client and the
target:

Assume that eth0 is the network interface that the server uses
to get to the target, and ppp0 is the tunnel network device
created by the client connection.  These are conventions we use to
explain, but adjust the instructions if the interface
names are different.
Here's a diagram showing the network interfaces as well:

Rewrite This HOWTO
This is a very detailed procedure.  It can help if our
instructions are tailored to the environment.  We give that
opportunity here, although only for the text, not the diagrams.
Be cautious.  Do not give information that may threaten security.  Use
an alias.
Client Name :
Client Tunnel Network Interface :
Client Tunnel Network Interface Address :
Server Name :
Server Tunnel Network Interface :
Server Tunnel Network Interface Address :
Server External Network Interface :
Server External Network Interface Address :
Target External Network Interface Address :
We'll list a series of tests that must be completed.  These follow the
path of the packets.  In each test, the diagram will be highlighted:

• [color="blue"]blue for the scope of the test,
  
• [color="green"]green for the packet flow and
  
• [color="red"]red for the test probe points.
  

Here is the legend or key for the symbols used in the diagrams below:

Test 0
Can the client ping the server inside the tunnel?

on client, type the command:
ping 10.1.1.1

make note of the result, the test passes if replies are seen,

stop the ping if desired,
You've already agreed above that this worked.  If the
answer is no, then fix the problem before proceeding.

(note to self,  test 0 passed, ping showed return packets)
Test 1
Can the server see the packets from the client for the target?

on server type the command:
tcpdump -n -i ppp0 icmp and src host 10.1.1.2 and dst host 72.14.207.99
and leave it to run,

on client, type the command:
ping 72.14.207.99
but expect no response there,

make note of the result, the test passes if on server the tcpdump has shown packets,

stop the ping and tcpdump if desired,
If there are no packets, the fault is at the client.  Stop and address
that issue at the client before proceeding.
The most common cause of failure for this test is a lack of route to
the target on the client.  Other causes are iptables rules on
the client or the server.
(There's nothing the server can do to prevent the client from using the
tunnel once it is established; routing at the client end is the
responsibility of the client.)

(note to self,  test 1 passed, tcpdump shows echo requests)
Test 2
Is the server configured to forward packets?

on server, type the command:
cat /proc/sys/net/ipv4/ip_forward

make note of the result, the test passes if 1 is shown.
If this is "0", it should be changed to "1", using
echo or sysctl.

(note to self,  test 2 passed, ip_forward is 1)
Test 3
Can the server reach the target?

on server type the command:
ping 72.14.207.99

make note of the result, the test passes if replies are seen,

stop the ping if desired,
Output from ping must show that packets are returning.  If it
does do not, then stop and address that issue at the server or the
target before proceeding.
Routing table entries on the server are a common cause.  Also check
iptables OUTPUT rules.  If there are no iptables rules
then this is not the cause.

(note to self,  test 3 passed, ping showed return packets)
Test 4
Can the server forward the requests to the target?

on server type the command:
tcpdump -n -i eth0 icmp and dst host 72.14.207.99
and leave it to run,

on client, type the command:
ping 72.14.207.99
but expect no response there,

make note of the result, the test passes if on server the tcpdump has shown packets,

leave the ping running, but stop tcpdump if desired,
If this test fails, then stop and address that issue at the server.
The most common cause of failure for this test is iptables
FORWARD rules.
Do not proceed until the answer is yes to this test.

(note to self,  test 4 passed, tcpdump showed echo requests)
Test 5
Can the target forward the replies back to the server?

on server type the command:
tcpdump -n -i eth0 icmp and src host 72.14.207.99
and leave it to run,

if not already running, on client, type the command:
ping 72.14.207.99
but expect no response there,

make note of the result, the test passes if on server the tcpdump has shown packets,

leave the ping running, but stop tcpdump if desired,
There must be ICMP echo replies with a source address of the target.
If the answer is no, then stop and address that issue.
The most common cause of failure for this test is that the target has
no route to the tunnel IP address of the client.  Look at the source
address on the ICMP echo requests as they leave the server's external
network interface.  If an unroutable address range is assigned
(e.g. 10.x.x.x, or 192.168.x.x) to the client, then ensure the server
is configured to do network address translation (NAT) or
masquerade.
The most common way to do NAT is to add an iptables rule that affects
packets leaving the server:
# iptables --table nat --append POSTROUTING \
  --out-interface [color="#003000"]eth0 --jump MASQUERADE

(note to self,  test 5 passed, tcpdump showed echo replies)
Test 6
Can the server forward the target reply packets back to the client?

on server type the command:
tcpdump -n -i ppp0 icmp and src host 72.14.207.99 and dst host 10.1.1.2
and leave it to run,

if not already running, on client, type the command:
ping 72.14.207.99
but expect no response there,

make note of the result, the test passes if on server the tcpdump has shown packets,

stop the ping and tcpdump if desired,
If the test fails, then the server is not forwarding the returned
packets that were seen in test 5; either they are misaddressed, or
iptables rules are configured to prevent it.  As usual, fix
this.

(note to self,  test 6 passed, tcpdump showed echo replies)
Once test 6 passes, the fault must be with the client.  For the
packets to leave the server and not arrive on the client would
normally be a client problem.
(note to self,  bugger! [or other expression of dismay])
Passed all tests, but something still doesn't work?  If it's Windows
share browsing, consider either adding the proxyarp or
ms-wins option in /etc/ppp/options.pptpd, or running
the bcrelay program.
Comments
If you have comments on this document, please send them to the
author at james.cameron at hp.com.  But if you need help, use
the mailing list
(
subscribe
,
archives
)
so that we can share the load.
ChangeLog
DateChange
2007-10-18
Added most common way to enable NAT from the server to the target.
Rework instructions using variables that may be set by the reader.
Made tcpdump expressions more exact, in order to reduce the
size of the explanations.
2007-01-25
Reworded each test narrative to isolate goal, test, expected result,
and possible causes.  Made it more clear in the text where each test
command was being done.
2006-03-09
Page is reasonably often needed during IRC and e-mail discussions, so
the diagrams have been made clearer.
2005-02-09
Second draft, following IRC discussion.
2005-01-25
First draft, used in private mail.
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/11995/showart_1008992.html