Почему широкий маршрут VPN ломает несколько публичных сайтов

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

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

Разрешите имя, которое не открывается, затем смотрите в таблицу маршрутизации, а не в браузер.

Сравнивайте адрес, а не имя сайта

Найдите адрес, который клиент действительно пробовал, затем проверьте, какой маршрут ему соответствует. Назначение внутри 45.61.20.10 попадает под 45.0.0.0/8, если этот префикс присутствует, даже если сам сайт никак не связан с туннелем. Сравнение проблемного адреса с установленными префиксами — это задача на вычитание, а не догадка.

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

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

Читайте самый конкретный совпадающий префикс, а не первую знакомую строку. Маршрут в таблице не доказывает, что он выиграл поиск; это делает самое длинное совпадение. Два префикса могут совпасть с одним адресом, и только один из них получает пакет. Проигравший остаётся в таблице и в списке выглядит так же реально.

Запишите префикс, его интерфейс и разрешённый адрес. Эти три значения и есть весь диагноз.

Выясните, кто установил маршрут

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

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

Внимательно прочитайте собственное поведение на основе классов

Собственные профили Windows имеют документированный параметр NativeProfile/DisableClassBasedDefaultRoute, который управляет автоматическим маршрутом, выводимым из адреса интерфейса. Адрес профиля, начинающийся с 45, при таком поведении может создать запись 45.0.0.0/8, и так один публичный адрес захватывает целый диапазон класса A.

Имя свойства подталкивает к неверному чтению: значение true отключает вывод, а false включает его. Это также не тот же объект, что маршрут по умолчанию, и оно не управляет сторонними клиентами, которые устанавливают свои префиксы.

Если вывод — доказанная причина, исправьте профиль через его владельца управления и явно укажите предназначенные частные префиксы. Если запись добавил скрипт, исправьте скрипт. Замена одного необъяснённого широкого маршрута другим меняет симптом, не отвечая на вопрос.

Исправьте источник, затем снова проверьте оба пути

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

Одновременно просмотрите план адресов сервера. Пул, пересекающийся с публичным пространством, снова и снова вызывает эту проблему. Диапазон, выбранный оператором намеренно, заслуживает другого разговора, а не автоматической перенумерации.

Повышение MTU или очистка DNS не исправит префикс, который по-прежнему направляет этот адрес в туннель. Сначала проверьте выбор, затем путь.

Похожие статьи