Azure P2S: у одного клиента Windows пропали маршруты после изменения VNet

Два ноутбука проходят проверку подлинности на одном и том же шлюзе Azure point-to-site, и только один достигает только что подключённой VNet. Оба показывают Connected, значит, аутентификация — не различие; различие — маршруты к назначению, которые они держат. Начните с отказавшего клиента, сравните одно назначение и только потом решите, кому принадлежит пробел — пакету шлюза или локальной таблице маршрутов.

Начните с отказавшего клиента, а не со шлюза

Подтвердите топологию, прежде чем винить ноутбук. Проверьте, какие VNet подключены к VNet шлюза и доступна ли новая сеть напрямую через пиринг или через отдельный туннель site-to-site. Если новая VNet вообще не подключена к VNet шлюза, ни один клиентский пакет не сможет туда маршрутизировать, и работающий ноутбук — это аномалия, которую нужно объяснить. Запишите ответ: он определяет, отлаживаете вы клиента или шлюз.

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

Сравните одно назначение с помощью route print

Выберите разрешённый IP ресурса и сравните оба ноутбука дважды: в отключённом состоянии, затем в подключённом. В Windows route print -4 выводит маршруты IPv4 с префиксом назначения, интерфейсом, следующим узлом и метрикой. Запишите строку, которая действительно победила бы для этого назначения, вместо того чтобы считать записи со словом VPN.

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

Конфликтующий локальный префикс может дать тот же симптом. Прежде чем что-то добавлять, определите, какой из двух случаев у вас: туннельного маршрута нет вовсе или он проигрывает более конкретному.

TTL expired — не ошибка распространения маршрутов

Ping, возвращающий TTL expired in transit, говорит, что пакет исчерпал лимит переходов, а это обычно означает петлю пересылки, а не сломанный драйвер VPN. Ping в Windows принимает TTL до 255, и увеличение значения не исправляет петлю; оно лишь откладывает ту же ошибку. Относитесь к сообщению как к симптому пути, а не как к доказательству о распространении маршрутов.

Используйте tracert -4 10.24.1.10, чтобы увидеть, где путь повторяется. Если одни и те же два перехода появляются снова и снова, ищите маршрут, который отправляет трафик, идущий в туннель, обратно в туннель или в локальный маршрутизатор, возвращающий его назад.

Пересоздайте пакет на том шлюзе, которому он принадлежит

Microsoft документирует, что клиентские пакеты Windows нужно повторно скачать и установить после значимых изменений топологии. Возьмите текущий пакет со шлюза Azure, обслуживающего этот профиль, и примените его поддерживаемой процедурой для этого клиента. Замена исполняемого файла постороннего VPN-приложения — не та же операция, что пересоздание настроек, специфичных для шлюза. Скачать пакет заново дёшево; угадывать локальные маршруты — нет.

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

Сценарии маршрутизации Azure P2S отделяют напрямую пирингованные VNet от сетей, доступных через другие туннели, и новый пакет не может сделать пиринг транзитивным. Некоторым сценариям Windows site-to-site или BGP также нужны вручную настроенные удалённые маршруты, поэтому обновление пакета не является универсальным механизмом распространения маршрутов.

Оставляйте временный маршрут временным

Ручной маршрут может изолировать отсутствующий клиентский маршрут, но стройте его из реального проекта: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, без флага постоянства, чтобы он исчез при перезагрузке. Индекс интерфейса и следующий узел выбирайте по подключённому адаптеру VPN, а не наугад.

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

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