站点间 VPN 只有一个方向通：两类不同的故障

永不返回的应答和被拒绝的连接是两类不同的故障。请比较策略、路由以及服务器实际看到的源地址。

站点 A 能到达 B，B 却到不了 A，而隧道在两个方向上看起来都正常。在动隧道之前，先判断你遇到的到底是哪一类故障。在 B 侧新建连接被拒绝，与 A 侧发起的连接收不到应答，会产生相似的抱怨和完全不同的诊断。前者是路径上的策略或路由问题；后者是已被放行流量的回程或状态问题。

这个区别决定了哪些命令值得执行。

两类看起来相同的故障

第一种情况下，B 的主机向 A 发送 SYN，却什么也没有回来。第二种情况下，A 的主机成功建立会话，应答却在回程中消失。两位用户都说链路是单向的，也都描述了一个消失的包，所以仅凭描述无法区分两者。

问清是哪一侧发起了失败的那次尝试。仅这一条事实就能排除一半的可能原因。

然后确认测试始终使用相同的主机和服务。一侧的 ping 和另一侧的文件共享连接测的是两件不同的事，而由网关发出的诊断可能选中一个任何用户流量都不会使用的隧道地址。

情况一：缺少回程路径

远端服务器若经由另一条默认网关应答，就可能收到请求却把应答路由到别处。有状态防火墙随后会丢弃这条非对称应答，因为它不匹配已建立的流，看起来就像那个方向从未通过。地址转换又带来一个变体：目的端看到的是转换后的源地址并向其回包，因此为原始地址编写的规则永远匹配不上。

请检查目的端在转换后实际观察到的地址，并为该地址而原始子网检查回程路由。

情况二：策略从未放行

相反的情况比看起来更简单也更常见：某个办公室只应使用中心服务，永远不应向中心发起连接。这种不对称是有意的访问决策，隧道正是按设计工作。改任何隧道设置之前，请先读访问策略。是文档而不是抓包说明原本打算放行哪个方向。抓包只能显示发生了什么，不能显示什么被授权过。

如果确实需要双向发起，请通过平台支持的规则集添加针对该服务的精确许可。为了修好一个应用而把所有子网设为互信，会把一个狭窄的需求变成一条宽泛的许可，而这种交换事后很少被复核。

在同一批主机上比较改动前后

观察同一次尝试的两端，而不是两次独立的尝试。在发起主机的网关和目的端同时抓包，然后比较进入了什么、发出了什么，以及远端看到的地址。

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

如果目的端的抓包显示请求的源地址与预期不符，答案在地址转换或路由上，而不在隧道的安全策略里。如果目的端完全没有看到请求，那么这个包从未经过受保护路径。

修正之后，从同一台主机重复完全相同的测试，并确认无关访问依然被拒绝。隧道状态为“established”本身并不能支持上述任何一个结论。

相关文章