我在位置“A”安装了 Mikrotik hEX，在位置“B”安装了 Mikrotik hAP AC^2，并使用 OVPN L2 连接了它们。两个路由器都启用了 NAT 功能，并拥有自己的专用网络。hEX 的网络为 192.168.0.0/23，hAP 的网络为 192.168.3.0/24。这两个本地网络绑定为一个本地网络 192.168.0.0/22。我已确认所有桥接、路由和 DHCP 策略均已配置并按预期运行。
配置上述设置后，我尝试从 hEX 下连接的设备连接到公共 IP（'X'），以使用此路由。
终端设备 -> hEX -> hAP -(NAT) -> 远程服务器‘X’
为了实现这一点，我已将路由策略添加到“X”，以使用 hEX 上的 VPN 服务器绑定接口的 IP 作为网关，并确认 ICMP 回显答复已得到良好接收、稳定，并且需要大约 9-12 毫秒才能答复。
但是，当我使用任何使用 TCP 建立连接的软件时（我尚未确认 UDP 是否也受到影响，但我认为是负面的），会发生一些奇怪的事情，如下所示：
如果建立了 TCP 连接，其他 TCP 数据包也会在 50 毫秒内尽快回复。但是，只有回复 SYN 的 TCP ACK 数据包，服务器的 ACK 会持续重新传输约 10 秒，然后继续握手过程。建立 HTTPS 连接时也会发现此行为，并且在 hEX 下的所有设备上都可以观察到。
如果我删除针对地址 X 的路由策略，则使用路由
终端设备 -> hEX -(NAT) -> 远程服务器‘X’，TCP 握手立即建立。
如果我通过使用路由连接到 hAP 下的设备上的地址 X，
终端设备 -> hAP -(NAT) -> 远程服务器‘X’，TCP 握手立即建立。
这是什么问题？我该如何解决？
答案1
阅读完您的帖子并查看您提供的网络跟踪屏幕截图后，我将重点关注该细节，尤其是 ICMP 重定向。
在对其中一些内容进行了一些研究之后，“ICMP | 重定向 | (主机重定向) 是什么意思？”该帖子似乎有一些潜在的解决方案可以帮助解决这个问题。
建议在路由器之间使用静态路由和/或不通过子网掩码使用重叠子网，这将有助于路由器不会自动选择更好的路由，从而导致您捕获的重定向。
总而言之，在我看来，也许路由在两个方向的跳数之间变得混乱hEX -> nAP，hEX <- nAP而使用之间的静态路由可能会有所帮助。
最终工作解决方案
OP 删除了整个路由策略，在问题中表示为“X”，然后将策略添加为 DHCP 选项 121。此策略基本上路由到人胰腺癌的 IP 在己烯（通过 VPN 接口）用于网关。
之前到“X”的流量由己烯然后人胰腺癌， 但现在己烯充当开关，人胰腺癌仅负责路由和伪装往返于“X”的流量。
ICMP 重定向是一个很好的线索，而建立直接/静态路由正是解决此问题所需要的。