tcpdump调试pptp

2019-11-26 16:38:17 浏览数 (1)

本文由腾讯云 社区自动同步,原文地址 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

代码语言:javascript复制
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**会好很多。

0 人点赞