我遇到了一个奇怪的网络问题。我在办公室的 udp:1195 上设置了 VPN（将端口从 1194 改为了 1194）。
VPN服务器是10.9.0.1，我的客户端连接时接收10.9.0.2。
当 VPN 连接时，我可以从家里 ping 通 LAN 服务器 (10.217.50.0/24)。
我可以从局域网服务器（10.9.0.2）ping 我的VPN 客户端。
我总是可以从 LAN 服务器 ssh 到 VPN 客户端。（在 10.217.50.169 >> ssh 10.9.0.2）
我始终可以从 vpn 客户端通过 ssh 连接到 VPN 服务器的 LAN 或 VPN 地址。（在 10.9.0.2 >> ssh 10.9.0.1 或 ssh 10.217.50.9）
我总是可以从 vpn 客户端通过 ssh 连接到网关地址的 fios 路由器。（在 10.9.0.2 >> ssh 10.217.50.1）
如果目标服务器刚刚重启，我只能从 vpn 客户端 ssh 到 lan 服务器。（在 10.9.0.2 >> ssh 10.217.50.169）
如果我在机器重新启动后等待几秒钟，就会出现以下错误：
ssh [email protected]
kex_exchange_identification: read: Connection reset by peer
Connection reset by 10.217.50.169 port 22
工作路由器是 Verizon Fios G1100。我在其上设置了一条路由，允许 10.217.50.0/24 访问 10.9.0.0/24。
有任何想法吗？
我猜想机器上线几秒钟后我被路由器中的某些防火墙规则阻止了。
看来此路由器在防火墙 Web 配置上没有数据包过滤选项。我确实可以通过 ssh 访问防火墙，并且我已经从我的 VPN 确认，我可以从我的 VPN 客户端连接 ssh 到 VPN 网关 10.9.0.1 和路由器 10.217.50.1。
答案1
这听起来像是一个非常经典的路由/反向路由/安全问题。
ICMP（ping）消息用于诊断或控制目的。其错误被导向来源原始数据包的 IP 地址，因此 ICMP 数据包在两个方向上流动。
SSH 和其他 TCP 应用程序使用 TCP（三向）握手。问题就在这里：您的 VPN 客户端将数据发送到“服务器”（直接通过 VPN 服务器的 NIC）。服务器获取数据并根据其路由表向网络网关发送技术上正确的答案。但（安全）网关从未看到连接被启动，因此“未知”答案被阻止为“未启动”或“非法尝试”。这是完全正常的，防火墙应该阻止半答案的连接。
如何解决这个问题？
你可以为所有服务器添加本地路由，在尝试访问 VPN LAN 时指向 VPN 网关。从技术上讲（作为网络管理员），这是“正确”的解决方案（因为不涉及其他组件），但管理起来却很麻烦。
您还可以检查您的 VPN 服务器和安全设备是否支持 ICMP 重定向（基本上是动态路由公告）。这或多或少无法完美运行。
您可以（也许应该）停止通过这个“自己的”vpn 绕过您的安全应用程序，而使用它提供的 VPN 解决方案。