Обратный трафик Azure P2S VPN работает только в одну сторону

Значок туннеля зелёный, NSG выглядит разрешающим, действующие маршруты выглядят правильными, но виртуальная машина по-прежнему не может открыть соединение обратно к подключённому клиенту. Обычное допущение состоит в том, что работающий туннель point-to-site симметричен: если клиент достигает виртуальной машины, то и она достигает клиента. Это допущение — ошибка в рассуждении, а не в конфигурации. Туннель может пропускать одно направление незапрошенного потока и отбрасывать другое, и исправление зависит от того, какой уровень его отбрасывает.

Миф: подключённый туннель — это двусторонний туннель

Туннель VPN — это путь политики, а не провод. Каждое направление сопоставляется с селекторами, маршрутами и фильтрами, и любой из них может разрешить одно направление, блокируя другое.

На практике асимметрия настолько распространена, что направление стоит проверять первым, а не последним. Клиент инициирует, шлюз отслеживает поток, а ответ следует за созданным состоянием. Виртуальная машина, которая начинает новый поток, такого состояния не имеет, поэтому зависит от того, будет ли обратный путь явно маршрутизируемым и разрешённым. Когда этого пути нет, попытка соединения умирает раньше, чем её увидит любое приложение.

Проверяйте направление до проверки доступности

Выберите один адрес клиента, один адрес виртуальной машины и один протокол. Подключитесь с клиента и запишите результат; затем начните тот же тест с виртуальной машины и запишите его тоже. Если первый успешен, а второй нет, пул клиентов, связь со шлюзом и путь от клиента к VNet работают.

Следующий шаг — доказательства, а не новые правила. Проверьте NSG в подсети виртуальной машины в обоих направлениях, прочитайте действующие маршруты на сетевом интерфейсе виртуальной машины и захватите пакеты на ней, пока клиент отправляет трафик. Запрос, который приходит без ответа, — это проблема фильтра или обратного маршрута; запрос, который не приходит вовсе, — проблема пути. Не считайте неудачный ping доказательством недоступности виртуальной машины: политика ICMP может отбрасывать ответ, пока TCP работает.

Обратный путь IKEv2 point-to-site — обычный подозреваемый

В отчёте Azure, на котором основана эта статья, клиент достигал виртуальных машин по IKEv2, но входящий ICMP от виртуальной машины к клиенту не работал, пока тип туннеля шлюза не был переключён на OpenVPN. Автор отчёта утверждает, что Microsoft подтвердила ограничение в пути IKEv2 point-to-site: обратный трафик от виртуальной машины к клиенту не маршрутизируется симметрично, если сеанс не начал клиент. IKEv2 полагается на селекторы трафика, и шлюз в том случае не учёл обратное направление.

Это не делает OpenVPN лучшим типом туннеля вообще. Это делает тип туннеля переменной в матрице тестов для этой рабочей нагрузки.

Смена типа туннеля — это изменение службы, а не переключатель. Каждому клиенту нужен совместимый профиль, а шлюзу может понадобиться другой сертификат или настройка аутентификации. Воспроизведите одностороннее поведение с одним тестовым клиентом и одной тестовой виртуальной машиной, смените тип по утверждённому графику и затем повторите те же тесты направления. Если поведение сохраняется после переключения, тип туннеля не был причиной, и вы сузили проблему, не затрагивая продакшен.

Миф: обнаружение через broadcast пересекает границу VNet

Второе допущение не выполняется по несвязанной причине. Виртуальная сеть Azure не передаёт широковещательный трафик, поэтому виртуальная машина не может получать широковещательные кадры из локальной сети через подключение site-to-site или point-to-site. Приложения, которые находят партнёров через broadcast, например старый просмотр файлов или некоторые протоколы обнаружения устройств, никогда не увидят удалённую сторону, как бы ни были написаны маршруты.

Замените обнаружение через broadcast именами DNS, службой каталогов или явным списком партнёров. Если у приложения нет альтернативы unicast, проекту нужен другой механизм обнаружения, а не более широкий туннель.

Что изменить и как это доказать

Если тест направления не проходит только на IKEv2, запишите тип туннеля шлюза, пул адресов клиентов и точный тест ICMP или TCP, затем оцените утверждённый профиль OpenVPN для затронутых клиентов. Если он не проходит на любом типе туннеля, работайте с обратным путём: адрес клиента должен быть маршрутизируемым из подсети виртуальной машины, любой пользовательский маршрут должен указывать на допустимый следующий переход, а межсетевой экран клиента должен принимать входящий поток. Приложите доказательства по NSG и маршрутам к заявке.

Проверяйте приложением, а не ping. Успешный обмен ICMP после изменения ничего не говорит о порте службы, её аутентификации или разрешении имён. Повторите тест после переподключения, потому что клиент, получивший другой адрес из пула, может изменить результат. Затем повторите ещё раз после того, как клиент заснёт и проснётся: именно в возобновлённом сеансе одностороннее поведение часто появляется снова.