長すぎるTCPハンドシェイク中NAT
Mikrotik hEXを場所「A」にインストールし、Mikrotik hAP AC ^ 2を場所「B」にインストールしてそれぞれをOVPNL2に接続しました。 2つのルーターは両方ともNAT機能がオンになっていて、プライベートネットワークがあります。hEXにはネットワーク192.168.0.0/23があり、hAPにはネットワーク192.168.3.0/24があります。これら2つのローカルネットワークは1つのローカルネットワーク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へのルーティングポリシーを削除した場合は、routeを使用します
エンドデバイス-> hEX-（NAT）->リモートサーバー 'X'、TCPハンドシェイクがすぐに確立されます。
ルートを使用して、hAPの下のデバイスのアドレスXに接続する場合
エンドデバイス-> hAP-（NAT）->リモートサーバー 'X'、TCPハンドシェイクがすぐに確立されます。
問題は何ですか？どのように修正すればよいですか？
あなたの投稿を読み、あなたが提供したネットワークトレースのスクリーンショットを見た後、私はその詳細と特にICMPリダイレクトに焦点を当てます。
このいくつかについて調査した後、 "ICMP |リダイレクト|（ホストへのリダイレクト）はどういう意味ですか？" 投稿には、この問題の解決に役立ついくつかの潜在的な解決策があるようです。
ルーター間で静的ルートを使用するか、サブネットマスクを介して重複するサブネットを使用しないと、ルーターがより適切なルートを自動的に選択して、キャプチャしたリダイレクトが発生しないようにすることをお勧めします。
とはいえ、ルートがhEX -> nAPとhEX <- nAPの間で混乱しているように思われます。両方向のホップで、静的ルートを使用すると役立つ場合があります。
最終的な作業ソリューション
OPは、質問で「X」として表されているルーティングポリシー全体を削除し、DHCPオプション121としてポリシーを追加しました。このポリシーは基本的にhAPにルーティングします。ゲートウェイのhEX（VPNインターフェイス経由）のIP。
以前は、「X」へのトラフィックはhEX、次にhAPによってルーティングされていましたが、現在、hEXはスイッチとして機能しており、hAPはルーティングのみを担当します'X'との間のトラフィックをマスカレードします。
ICMPリダイレクトは良い手がかりであり、直接/静的ルートを作成することは、まさにこの問題を解決するために必要なことです。