江苏
SSL VPN 能拨上，内网却死活不通
一次把人绕晕的远程接入排障记录
下午三点多，某客户群里弹出一条消息：“VPN 能连上，地址也拿到了，可ERP服务器就是连接不上。”
这种描述听着耳熟。远程接入类的问题，最难搞的往往不是“连不上”，而是连上了、地址也有了、但就是不通。前者好歹有报错，后者连个像样的 deny 日志都看不到。
这台防火墙上上跑着到分支机构的 IPsec 隧道，好几年了，一直很稳，笔记本电脑也用univpn连接，便于访问内网资源，最近应客户要求，又增加了一种方式，就是SSLVPN。
一、现象：拨号一切正常，ping 一个包都不回
客户端的表现挑不出毛病——拨号成功，认证通过，虚拟网卡拿到了 172.16.2.x 的地址，路由也下了。
但访问内网就完全不是那么回事：ping 内网的 erp服务器192.168.100.253，全部超时；业务系统的端口连不上；换几台机器、换网络，都一样。
偏偏同一台设备上， IPsec 业务一切正常，隧道 SA 稳稳当当。这一对比，很容易把人往“SSL VPN 配置有问题”上带。
二、策略确实没问题，会话表却是空的
第一步照例是查安全策略。
安全策略显然是放行了SSLVPN网段到内网的访问，和L2TP over IPSec的网段写在同一条策略里面，没道理L2TP over IPSec能访问内网，SSLVPN却不行啊，这不合逻辑，秒过。
同理，nonat策略也不用看了，因为同样引用了两个地址池。
三、抓包：ping包有来无回
开个五元组抓包吧， 源地址是VPN客户端的IP，目的地址是内网的ERP服务器192.168.100.253，结果显示，只有请求，没有回应。
五元组丢包统计信息显示：丢包率100%，好家伙，把客户端的请求全给丢掉了，服务器压根就没收到请求，怎么可能有回包。
四、加密流里，藏着 SSL VPN 的网段
事出反常必有妖啊，好端端的，怎么就把正常的数据包全部给丢弃了呢？
用diag命令，进入诊断模式看一下吧。
然后dis firewall statistics acl
结果显示：IPSec precheck failed packets discarded: 58
咦，好像发现问题所在了，SSLVPN客户端进来的数据包，应该是被IPSec反查丢弃了。
速度切到ipsec配置页面查询，果不其然，当初为了图省事，直接在“对象”中把原来的VPN地址增加了一个172.16.2.0/24网段（原来L2TP over IPSec只有172.16.1.0/24一个网段）。
这样一来，安全策略和NAT策略是省事了，但是忘记在加密流（感兴趣流）里面减少一个网段了。
后果是：SSL VPN 用户的访问流量（以及内网回给地址池的流量）被加密流 ACL 匹配上了。设备一看，这段流量按定义该进隧道、该被加密，可实际上它根本不走 IPsec，也没有对应的 SA——前反查不讲情面，一票否决，包就这么给丢弃了。
这也解释了为什么日志里干干净净：没有 deny，没有拒绝，包就是不见了。
五、解决问题
找到原因了，改起来就很快，无非是把 SSL VPN 地址池从加密流里摘出去。
对象里面的地址池，就不去改动了，否则还要调整安全策略和NAT策略。
还是简单点吧，直接收紧加密流，把引用的对象删除，手写172.16.1.0/24，保存就好。
通知客户测试，回复没问题了，可以正常访问ERP服务器。
这活儿最折腾人的地方，就是所有配置看上去都没问题，包却不见了。安全策略没拦，日志没记，连接也没断——丢包发生在一个平时根本不会去翻的检查项上。
总结：排查还是得细心，不轻易放弃任何蛛丝马迹，可能问题就在一个不起眼的地方等着你发现。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
