Слишком долгое рукопожатие TCP при выполнении NAT
Я установил Mikrotik hEX в местоположении «A», Mikrotik hAP AC ^ 2 в местоположении «B» и подключил каждый к OVPN L2. На обоих маршрутизаторах включены функции NAT и имеется собственная сеть. hEX имеет сеть 192.168.0.0/23, а hAP имеет сеть 192.168.3.0/24. Эти две локальные сети связаны как одна локальная сеть 192.168.0.0/22. Я подтвердил, что все мосты, маршрутизация и политика DHCP настроены и работают, как я ожидал.
После настройки вышеуказанного параметра я пытаюсь подключиться к общедоступному IP-адресу ('X') с устройства, подключенного под hEX, чтобы использовать этот маршрут.
Конечное устройство -> hEX -> hAP - (NAT) -> Удаленный сервер 'X'
Для этого я добавил политику маршрутизации к «X», чтобы использовать IP-адрес интерфейса привязки сервера VPN на hEX в качестве шлюза, и подтвержденный эхо-ответ ICMP хорошо принимается, стабилен и требует около 9-12 мс для ответа.
Однако, когда я использую любое программное обеспечение, которое использует TCP для установления соединения (я не подтверждал, затрагивается ли UDP тоже, но я думаю, что это отрицательно), происходит что-то странное, например: 
Даже другие пакеты TCP отвечают как можно скорее, менее чем за 50 мс, если TCP-соединение установлено. Однако только пакет TCP ACK, отвечающий на SYN, ACK сервера продолжает повторно передаваться в течение примерно 10 секунд, а затем процесс подтверждения продолжается. Такое поведение также наблюдается при установке HTTPS-соединения и наблюдается на всех устройствах под hEX.
Если я удалю политику маршрутизации для адреса X, тогда используйте route
Конечное устройство -> hEX - (NAT) -> Удаленный сервер 'X', подтверждение TCP устанавливается немедленно.
Если я подключаюсь к адресу X на устройстве под hAP, используя маршрут
Конечное устройство -> hAP - (NAT) -> Удаленный сервер 'X', подтверждение TCP устанавливается немедленно.
В чем проблема и как ее исправить?
Прочитав ваше сообщение и просмотрев предоставленный вами снимок экрана трассировки сети, я сосредоточусь на этих деталях и, в частности, на перенаправлениях ICMP.
Проведя некоторые исследования по этому поводу, "Что означает ICMP | Redirect | (перенаправление для хоста)?" сообщение, похоже, имеет несколько потенциальных решений, которые помогут решить эту проблему.
Предполагается, что использование статических маршрутов между маршрутизаторами и / или неиспользование перекрывающихся подсетей через маски подсети поможет маршрутизаторам автоматически не выбирать лучший маршрут, вызывающий переадресацию, которую вы перехватили.
При всем сказанном, мне кажется, что, возможно, путаются маршруты между hEX -> nAP и hEX <- nAP могут помочь переходы в обоих направлениях и использование статических маршрутов между ними.
Окончательное рабочее решение
OP удалил всю политику маршрутизации, которая в вопросе обозначена как «X», а затем добавил политики как параметр 121 DHCP. Эта политика в основном направляет на ГАПIP на hEX (через интерфейс VPN) для шлюза.
Ранее трафик на "X" направлялся hEX затем ГАП, но сейчас hEX работает как переключатель и ГАП отвечает только за маршрутизацию и маскировку трафика к / от «X».
Перенаправление ICMP было хорошей подсказкой, и создание прямого / статического маршрута - именно то, что потребовалось для решения этой проблемы.