iptables 端口转发_ISP对pptpd及1723端口的动态管控初探

摘要：考虑到网课做远程登录linux的实验，特意在某某云租用了日本服务器，在安装pptpd及对应的客户端连接服务器的过程中，无意中发现了ISP对1723端口的动态管控，进行了一些原理猜测，提供给大家探讨。

一、某某云日本服务器搭建

最低配置的ECS云服务器，普通的E2CPU，0.5G内存，不到10美元一个月的价格，提供了一个公网ip地址，课程需要安装了ubuntu版本的18.04，ping、telnet及在云控制台或者本机远程ssh登录都轻易成功了。感觉还不错。唯一值得注意的地方时，visa信用卡有个绑卡及扣款动作，还有就是1美元预授权，这都无法绕开。基本上参考互联网资料，照方抓药，具体步骤：

1、某某云的服务器的安全组，默认大部分端口都是关闭的，需要客户手动打开1723端口及gre协议。我理解的是：对于个人做实验，多打开几个端口没关系。

2、安装pptpd. 自带软件仓库安装，查看了一下，软件源都是默认来自某某云，强大. sudo apt-get install pptpd 以及sudo vi /etc/pptpd.conf里面指定服务器提供给未来客户端的ip地址范围，假设采用推荐的http://192.168.0.XXX这个网段。

3、设定dns. sudo vi /etc/ppp/pptpd-options.

4、设定客户端远程登录的用户名和密码：sudo vi /etc/ppp/chap-secrets.

5、开启ip转发功能sudo vi /etc/sysctl.conf 增加了一句net.ipv4.ip_forward=1然后立刻执行更新sudo sysctl -p

6、安装nat的转发。首先需要安装iptables，可以自带软件仓库安装apt-get install iptables，然后再sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE，之后，各种操作策略有争议的地方，问：是否要单独在iptables里面打开1723级gre协议，我理解的是：如果机器上没有用防火墙做其它保护，默认端口都是打开的，所以，不需要单独打开；但是，机器本来有防火墙使用的话，说明防火墙已经在起作用，那需要单独打开它们sudo iptables -A INPUT -p tcp --dport 1723 -j ACCEPT #开放1723端口；以及　sudo iptables -A INPUT -p gre -j ACCEPT　　#开启gre协议

7、重启pptpd 使其生效，用命令：service pptpd restart 或者/etc/init.d/pptpd restart，至于是否需要保存iptables，则看自己的需求了。不要求开机自动加载的话，可以每次手动启动pptpd。

至此，服务器端的安装设置均已完成。

二、客服端测试情况

1、windows电脑，win7测试，手动添加某某某网络适配器，然后属性、安全、类型里面选择PPTP，然后wifi上网，输入服务器设置的用户名和密码，直接连接成功，几秒钟可以打开某搜索网站；

2、安卓手机，同样设置，无线与网络，连接里面，找到某某某，添加，类型PPTP，然后，类似电脑上的操作，一次成功，成功以后在屏幕顶部状态栏会出现一把小小的钥匙logo；huawei小米都测试可用；手机测试的时候，不论是使用ISP接入，还是使用4G流量的接入，都可以连接，速度与平时使用区别不大，看视频不卡。

3、苹果平板，居然添加不了PPTP协议，原因未知，猜测是ios更新升级以后，认为PPTP协议不够安全，所以故意放弃对该协议的支持。

正在窃喜，怎么这么容易就成功了，可惜，好景不长，第二天过去，还不到48小时，以上三种方式就都无法再连成功，显示错误如下图。

三、测试与诊断

1、排除服务器其它软件。服务器这边一直在尝试安装Nginx对建站的支持软件，以及开展SSH登录Linux的基础教学。那么，操作起来很简单，先把Nginx的服务关闭，然后，重启机器，无效果，错误仍然存在。服务器再无其它软件了。

2、iptables的问题。参考网络资料，打开各种端口：包括filter表格里面的INPUT/OUTPUT/FORWARD里面打开各种端口及协议，还有nat表格里面进行检查，看看有无异常，甚至iptables打开所有端口（打开所有端口等于iptables没安装？NO，因为nat转发的部分必须靠这个，还不完全一致），以上均无法解决。

3、某某云的安全组，某某云的安全组可以理解成iptables的硬件版本，那么，参考iptables的设置，打开某某云安全组里面各种出入端口和协议，仍无法解决问题。

4、重启机器，卸载pptpd再重装，重新加载ppp文件夹等，都试过了，仍然无效。

5、更换wifi以及三家手机信号提供商的上网服务，仍然无效。

6、telnet 服务器公网ip 1723端口号，成功！ssh服务器也成功，这说明服务器的ip并没有被封杀，1723协议在整个连接过程中可用，但就是无法建立pptpd连接。

四、终极排障

1、打开log功能排错。pptpd有对应配制文件，例如“pptpd.log”，操作在配制文件里面打开log功能再重启pptpd服务。

Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Using interface ppp0

Connect: ppp0 <--> /dev/pts/1

appear to have received our own echo-reply!

No CHAP secret found for authenticating admin

Peer admin failed CHAP authentication

Modem hangup

Connection terminated.

这是一种错误的log，简单分析就是，服务器pptpd在建立和客户端连接的过程中，听不到客户端的回应。以下还有另一种：这一种是配制信息得不到回应，如下图：

Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

Using interface ppp0

Connect: ppp0 <--> /dev/pts/1

LCP: timeout sending Config-Requests

Connection terminated.

Modem hangup

看完以上两种错误，交替出现，不知所云，因此还想要更多细节。

2、在交互认证的ppp密码过程中打开log功能。为什么服务器和客户端双方握手不成功？原因猜测是握手交互的细节出问题了。那么，ppp在pptpd连接的过程中，扮演了加密认证的功能，下面也打开它的log，这样，分析更加深入：

Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

pptpd-logwtmp: $Version$

using channel 1

Using interface ppp0

Connect: ppp0 <--> /dev/pts/1

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x3985????> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <magic 0xccd0????> <pcomp> <accomp>]

sent [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <magic 0xccd0????> <pcomp> <accomp>]

……这里省略，一共尝试了十次“收发收”,故意问号隐去可能的设备id……

LCP: timeout sending Config-Requests

Connection terminated.

Modem hangup

LCP是什么？网上查到的是链路控制协议，应该是TCP/IP七个传输层次里面，紧贴第1层物理层上面的第2或者第3层链路。LCP控制协议出问题。服务器首先发出要求认证，采用chap Ms-v2，客户端有回应，然后服务器再一次发LCP ConfAck，期待客户端做LCP Conf…可是一直等不到回应，就只好继续询问。

3、偶然的机会让我想到更换ISP.通过安卓手机使用电信4G网络，偶尔出现了配制等待特别久，果断打开log，发现了惊喜：

Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

pptpd-logwtmp: $Version$

using channel 39

Using interface ppp0

Connect: ppp0 <--> /dev/pts/2

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa023????> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <magic 0x7294????> <pcomp> <accomp>]

sent [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <magic 0x7294????> <pcomp> <accomp>]

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa023????> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <magic 0x7294????> <pcomp> <accomp>]

sent [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <magic 0x7294????> <pcomp> <accomp>]

rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0xa023????> <pcomp> <accomp>]

sent [LCP EchoReq id=0x0 magic=0xa023????]

sent [CHAP Challenge id=0xd6 <9321b67cc33fa02bdf9319811647????>, name = "pptpd"]

rcvd [LCP EchoRep id=0x0 magic=0x7294????]

rcvd [CHAP Response id=0xd6 <8082d4a546ed3b527fa0038c58f7174f00000000000????0e69b69d25a38175de0221????3e9288b6eed835ffbff40????>, name = "yixun"]

sent [CHAP Success id=0xd6 "S=E22E09FA15????BB4203B4C7F3477B8DCA15???? M=Access granted"]

peer from calling number 106.19.??.??? authorized

sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]

rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

MPPE required but peer negotiation failed

sent [LCP TermReq id=0x2 "MPPE required but peer negotiation failed"]

sent [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]

rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]

Discarded non-LCP packet when LCP not open

rcvd [CCP ConfRej id=0x1 <mppe +H -M +S -L -D -C>]

Discarded non-LCP packet when LCP not open

rcvd [LCP TermAck id=0x2]

Connection terminated.

Connect time 0.1 minutes.

Sent 10 bytes, received 43 bytes.

这里说明：服务器和客户端的交互过程又继续前进了几步，最终问题出在这里：“MPPE required but peer negotiation failed”上网检查，发现是客户端配制pptd进行连接，选择MPPE协议这一步，客户端的回复让服务器不满意，所以，服务器记录了MPPE不满足条件，这一步，如果是手机安卓扮演的客户端，明明选了PPP加密(MPPE)，无果；如果是win7客户端，不知道哪里选MPPE，查找资料说是windows自带，也无果。

4、进一步更换ISP. 经过上述的分析，我们在客户端–网路–服务器三者之间，我已经可以选择相信服务器是正确的了，而客户端也一直没变，那么中间的网络嫌疑最大。如果是手机4G信号的话，中间的网络包括：手机–基站–路由器阵列–出境路由器—境外路由器—某某云–服务器。那么采取反证法，我需要找到一个境外ISP，然后再测试以上pptpd. 突发奇想，我找到HK某手机卡，背着设备跑到深圳河边的某地，安卓手机建立PPTP，直接一把就成功，后来又多试几次包括热点分享给电脑试PPTP，也是ok的，这其中的交互报文log如下：

Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.

pptpd-logwtmp: $Version$

using channel 61

Using interface ppp0

Connect: ppp0 <--> /dev/pts/1

sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cc9????> <pcomp> <accomp>]

rcvd [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <magic 0xcc09????> <pcomp> <accomp>]

sent [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <magic 0xcc09????> <pcomp> <accomp>]

rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x6cc9????> <pcomp> <accomp>]

sent [LCP EchoReq id=0x0 magic=0x6cc9????]

sent [CHAP Challenge id=0xe2 <c169c44a965????0daa3a980182f????>, name = "pptpd"]

rcvd [LCP EchoRep id=0x0 magic=0xcc09????]

rcvd [CHAP Response id=0xe2 <92b87d52244ce210eb7????f4eeab592000????0000000006b????92939b1dcfe58fdd4e7db562407c82363331e1f1????>, name = "yixun"]

sent [CHAP Success id=0xe2 "S=0C4D3E1B5902A????2A43B324879C4E77924???? M=Access granted"]

peer from calling number 203.145.??.?? authorized

sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]

rcvd [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]

sent [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]

rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]

rcvd [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]

sent [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]

MPPE 128-bit stateless compression enabled

sent [IPCP ConfReq id=0x1 <addr 192.168.0.1>]

rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]

sent [IPCP ConfRej id=0x1 <compress VJ 0f 01>]

rcvd [IPCP ConfAck id=0x1 <addr 192.168.0.1>]

rcvd [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]

sent [IPCP ConfNak id=0x2 <addr 192.168.0.234> <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]

rcvd [IPCP ConfReq id=0x3 <addr 192.168.0.234> <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]

sent [IPCP ConfAck id=0x3 <addr 192.168.0.234> <ms-dns1 8.8.8.8> <ms-dns2 8.8.4.4>]

Cannot determine ethernet address for proxy ARP

local IP address 192.168.0.1

remote IP address 192.168.0.234

pptpd-logwtmp.so ip-up ppp0 yixun 203.145.??.??

Script /etc/ppp/ip-up started (pid 10729)

Script /etc/ppp/ip-up finished (pid 10729), status = 0x0

Modem hangup

pptpd-logwtmp.so ip-down ppp0

Connect time 4.1 minutes.

Sent 1366917 bytes, received 438902 bytes.

Script /etc/ppp/ip-down started (pid 10792)

MPPE disabled

sent [LCP TermReq id=0x2 "MPPE disabled"]

Connection terminated.

Waiting for 1 child processes...

script /etc/ppp/ip-down, pid 10792

Script /etc/ppp/ip-down finished (pid 10792), status = 0x0

感谢临时客串的境外ISP。至此，初探结论达成。

您查询的iP:203.145.??.??

ASN归属地：香港特别行政区

参考数据1：香港 HGC | Fully-Fledged Fixed-Line Telecom Operator

参考数据2：香港 和记电讯移动网

兼容IPv6地址：::CB??:5F??

映射IPv6地址：::FF??:CB??:5F??

五、结论

ISP在提供服务的时候，对通往境外的报文是有过滤功能的，这一过滤滤网采取了动态配制，至少在本案例中，动态配制的建立时间大约为48小时。由此，可以初探其机制：当检测到通往固定境外IP的1723端口并且总是做PPP加密的链路创建，则考虑在滤网添加新的规则，专门封闭这一链路创建动作。注意，只是封锁链路创建，不是粗暴地封锁1723端口（telnet 1723还能用），也更不是封锁IP地址（SSH也能用），毕竟信息还有可能误判，滤网要给自己留有余地。这一滤网规则在某台出境路由器上建立以后，会广播给所有的“出境路由器”做规则修改，所以我们更换三家ISP都收到同样的限制。更进一步，如果通往境外服务器公网IP的“动作”更大，则滤网限制将更严格，直至最后的封IP。至此，我更加敬仰“停泊在某某大学城计算机实验楼下悬挂黑A车牌的凯迪拉克”车主。

以上是这次测试的内容，来自一名想当科学家的程序员大叔，原文CSDN有同步发布，欢迎专家批评指正。