正文共：1234 字 3 图，预估阅读时间：1 分钟
我们前面介绍过了如何在公有云部署VSR设备（以腾讯云为例，在公有云部署一台VSR），也介绍了如何配置L2TP VPN实现访问云内业务（巧用VSR的L2TP VPN功能实现访问云上业务）；同时，我之前也使用这种方案将我的服务器放到了云上（成本增加了100块，内网服务器上公网解决方案2.0重磅来袭！），可以实现随时从公网访问。
但是，前段时间我的光猫出问题了，怎么都不能联网，后来换了光猫，谁知这一换竟然还出现了问题。
现象是我用来拨号的360路由器死活无法连接VPN，怎么调整都不行，我还以为是路由器故障了，重置了路由器，于事无补。
我不是还有一台MSR810-W嘛（淘了一台二手的H3C企业路由器，就用它来打开网络世界的大门），也用这台路由器进行了测试，还是怎么都连不上，此时我都怀疑是我的公网服务器故障了。后来用两台云主机进行测试，发现业务还能通，于是我就开始怀疑是联通把UDP给封了。
最后我才检查到光猫上，就是在高级NAT设置里面，有个ALG开关配置，勾选上L2TP，再测试业务就正常了。
我记得之前应该是介绍过ALG相关的知识，但是一时间想不起来了，那就再复习一下吧。
ALG，全称为Application Layer Gateway，即应用层网关，它是一种特殊的网关，工作在OSI网络模型的第七层-应用层（Application Layer），能够对特定的应用程序协议进行识别和处理。
ALG能够实现对特殊协议的识别、解析与转换，诸如SIP、H323、RTSP、PPTP、L2TP、IPsec、FTP等多种应用层协议的数据包，当这些协议的数据流需要穿越NAT设备时，ALG能够动态修改数据包中的端口号或相关信息，确保原本设计为在私有网络内部直接通信的应用能够在经过NAT转换后仍然能正常工作，这对于网络地址转换而言至关重要。
为此，我又特地去翻了一下L2TP相关的RFC协议规范（RFC2341、RFC2661），里面提到以下内容：
1、L2TP和L2F（Layer Two Forwarding，思科的二层隧道协议）都是自我描述的，在其承载的介质之上的级别上运行。
2、对于基于UDP/IP网络的L2TP和L2F，两者使用的都是众所周知的UDP注册端口1701。每个数据包报文头中的Version字段可以用于区分两种分组类型，一般L2F使用值1，L2TP版本使用值2。
3、按照RFC2341，L2F的源端口和目的端口均使用相同的UDP端口1701，其中使用CLID（Client ID）值来实现多路分解。而按照RFC2661，L2TP隧道的启动器选择可用的源UDP端口（可能是1701，也可能不是1701），并发送到端口为1701的目的地址；接收方在其自己的系统上选择一个可用端口（可能是1701，也可能不是1701），并将其回复发送到启动器的UDP端口和地址，将其自己的源端口设置为找到的可用端口。但是按照可见的实现方式，大部分参考的应该都是RFC2341。
查看抓包也很方便，只需要筛选L2TP服务器的IP地址，或者筛选L2TP协议即可。可以看到，数据的封装使用的UDP协议，源目端口都是1701。
4、UDP协议本身是不可靠的，所以基于UDP/IP协议的L2TP传输也是不可靠的传输，都存在丢包的风险。对于某些协议来说，允许静默地丢弃数据包可能更成问题。如果启用了PPP可靠传递[RFC1663]，则上层PPP协议都不会遇到丢失的数据包；如果启用了L2TP序列号，L2TP可以检测到数据包丢失。
回到与本次相关的技术点，那就是L2TP在传输时，源端口和目的端口均使用相同的UDP端口1701。对于常规的NAT设备而言，一般使用的是PAT（Port Address Translation，端口地址转换）模式，该模式下，NAT设备需要对报文的源IP地址和传输层源端口同时进行转换。放到该问题中，就是源端口1701被转换了，导致接收方无法将报文识别为L2TP业务报文。
而解决方案也很简单，只要在NAT设备上开启ALG就可以了，启用之后，NAT设备就可以对报文应用层数据载荷中的字段进行分析和处理，不再对源端口做转换。
除了本次发现的L2TP，常见的还有FTP（File Transfer Protocol，文件传输协议）协议（FTP：文件传输协议），FTP应用由FTP客户端与FTP服务器之间建立的数据连接和控制连接共同实现，而数据连接使用的地址和端口由控制连接协商报文中的载荷信息决定，这就需要ALG利用NAT的相关转换配置完成载荷信息的转换，以保证后续数据连接的正确建立。
长按二维码
关注我们吧
将Juniper虚拟防火墙vSRX部署在ESXi进行简单测试
409
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
