本文由腾讯云 社区自动同步,原文地址 https://stackoverflow.club/article/tcpdump_debug_pptp/
tcpdump调试pptp
在内网中有一个pptp client,奈何怎么也连接不上pptp server,可以用tcpdump调试下。
现象:
在客户端使用pptp命令行建立V**,出现timeout错误
代码语言:javascript复制wenfeng@wenfeng-woniu:~/workspace$ sudo pptpsetup --create piV** --server 10.134.118.131 --username wenfeng --password ty7938TYI --encrypt --start
Using interface ppp0
Connect: ppp0 <--> /dev/pts/2
LCP: timeout sending Config-Requests
Connection terminated.
Modem hangup
初步调试
在客户端所在机器使用tcpdump 监听,发现gre包没有回复。
在软路由端使用tcpdump监听,发现gre包应该回复给192.168.19.152
, 但是回复给了10.135.80.126
. pptp server地址在10.134.118.131
wenfeng@wenfeng-nec:~$ sudo tcpdump -v 'proto gre' -i wlp4s0b1
tcpdump: listening on wlp4s0b1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:34:33.418488 IP (tos 0x0, ttl 63, id 37553, offset 0, flags [DF], proto GRE (47), length 56)
192.168.19.152 > 10.134.118.131: GREv1, Flags [key present, sequence# present], call 4480, seq 1, length 36
LCP, Conf-Request (0x01), id 1, length 22
encoded length 20 (=Option(s) length 16)
ACCM Option (0x02), length 6: 0x00000000
Magic-Num Option (0x05), length 6: 0x0c5f864f
PFC Option (0x07), length 2
ACFC Option (0x08), length 2
16:34:33.444041 IP (tos 0x0, ttl 61, id 16265, offset 0, flags [DF], proto GRE (47), length 61)
10.134.118.131 > 10.135.80.126: GREv1, Flags [key present, sequence# present], call 21013, seq 0, length 41
LCP, Conf-Request (0x01), id 1, length 27
encoded length 25 (=Option(s) length 21)
ACCM Option (0x02), length 6: 0x00000000
Auth-Prot Option (0x03), length 5: CHAP, MS-CHAPv2
Magic-Num Option (0x05), length 6: 0x83c9a897
PFC Option (0x07), length 2
ACFC Option (0x08), length 2
16:34:36.358545 IP (tos 0x0, ttl 63, id 38010, offset 0, flags [DF], proto GRE (47), length 56)
192.168.19.152 > 10.134.118.131: GREv1, Flags [key present, sequence# present], call 4480, seq 2, length 36
LCP, Conf-Request (0x01), id 1, length 22
encoded length 20 (=Option(s) length 16)
ACCM Option (0x02), length 6: 0x00000000
Magic-Num Option (0x05), length 6: 0x0c5f864f
PFC Option (0x07), length 2
ACFC Option (0x08), length 2
16:34:36.457045 IP (tos 0x0, ttl 61, id 16288, offset 0, flags [DF], proto GRE (47), length 61)
10.134.118.131 > 10.135.80.126: GREv1, Flags [key present, sequence# present], call 21013, seq 1, length 41
LCP, Conf-Request (0x01), id 1, length 27
encoded length 25 (=Option(s) length 21)
ACCM Option (0x02), length 6: 0x00000000
Auth-Prot Option (0x03), length 5: CHAP, MS-CHAPv2
Magic-Num Option (0x05), length 6: 0x83c9a897
PFC Option (0x07), length 2
ACFC Option (0x08), length 2
16:34:39.364961 IP (tos 0x0, ttl 63, id 38203, offset 0, flags [DF], proto GRE (47), length 56)
192.168.19.152 > 10.134.118.131: GREv1, Flags [key present, sequence# present], call 4480, seq 3, length 36
LCP, Conf-Request (0x01), id 1, length 22
encoded length 20 (=Option(s) length 16)
ACCM Option (0x02), length 6: 0x00000000
Magic-Num Option (0x05), length 6: 0x0c5f864f
PFC Option (0x07), length 2
ACFC Option (0x08), length 2
可能的原因
GRE协议是于TCP,UDP协议平级的三层协议,它有一个最大的特点是没有端口这一概念。与OpenV**不同,OpenV**使用的是广泛的TCP和UDP协议,所有路由都能够支持,可以自由的NAT和端口映射。而GRE协议就不行了,因为没有端口的概念,导致路由器在进行NAT的时候无从下手,对于路由器来说,当它接收到一个GRE数据包,只能观察到它的源IP和目标IP,但是源IP由于NAT的原因可能这一个IP后面是好多台主机,同时目标IP也是这样,所以路由器无法判断这个数据包应该送到哪个主机上。
命令行配置pptp https://blog.csdn.net/hanyun9988/article/details/78568428
tcpdump指定抓取gre包 https://blog.csdn.net/Mr0Yang/article/details/52247885
tcpdump通用命令 https://www.cnblogs.com/ggjucheng/archive/2012/01/14/2322659.html
tcpdump指定使用的网卡 https://blog.csdn.net/norsd/article/details/65724919
GRE协议难以穿透路由器的解释https://blog.csdn.net/lvshaorong/article/details/71216227
应对方案
很不幸,我要绕开问题了。pptp由于其协议的原因很难穿透路由器nat,所以换为openV**会好很多。