tcpdump调试pptp

羽翰尘

修改于 2019-11-26 16:38:17

2K0

修改于 2019-11-26 16:38:17

文章被收录于专栏：技术向

本文由腾讯云+社区自动同步，原文地址 https://stackoverflow.club/article/tcpdump_debug_pptp/

tcpdump调试pptp

在内网中有一个pptp client，奈何怎么也连接不上pptp server，可以用tcpdump调试下。

现象：

在客户端使用pptp命令行建立V**，出现timeout错误

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