進行 NAT 時 TCP 握手時間過長
我在位置“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 毫秒內盡快回复。但是，只有 TCP ACK 數據包回复 SYN，伺服器的 ACK 會持續重傳大約 10 秒，然後繼續握手過程。在建立 HTTPS 連接時也會發現此行為，並在 hEX 下的所有設備上觀察到。
如果我刪除地址 X 的路由策略，則使用路由
終端設備 -> hEX -(NAT)-> 遠端伺服器 ‘X’，立即建立 TCP 握手。
如果我通過使用路由連接到 hAP 下設備上的地址 X
終端設備 -> hAP -(NAT)-> 遠端伺服器 ‘X’，TCP 握手立即建立。
有什麼問題，我應該如何解決？
在閱讀您的文章並查看您提供的網路跟踪螢幕截圖後，我將重點關注該細節，特別是 ICMP 重定向。
在對此進行了一些研究之後，“ICMP | Redirect | (redirect for host) 是什麼意思？” 文章似乎有一些潛在的解決方案來幫助解決這個問題。
建議在路由器之間使用靜態路由和/或不通過子網遮罩使用重疊子網將有助於路由器不會自動選擇更好的路由，從而導致您擷取的重定向。
綜上所述，在我看來，也許路由在兩個方向上的
hEX -> nAP和hEX <- nAP跳躍之間變得混亂，並且在之間使用靜態路由可能會有所幫助。最終工作解決方案
OP 刪除了整個路由策略，在問題中表示為“X”，然後將策略添加為 DHCP 選項 121。該策略基本上路由到hAP上****hAP的 IP （通過 VPN 介面）作為網關。
以前到“X”的流量由hEX然後是hAP路由，但現在hEX作為交換機工作，hAP只負責路由和偽裝到/來自“X”的流量。
ICMP 重定向是一個很好的線索，而製作直接/靜態路由正是解決此問題所需要的。