Маршрут VPN, привязанный к индексу интерфейса, ломается при переподключении

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

Проверьте, на что маршрут указывает на самом деле

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

Get-NetRoute -DestinationPrefix '10.77.0.0/16' | Select-Object DestinationPrefix, NextHop, InterfaceIndex, Store
Get-NetAdapter | Where-Object InterfaceDescription -like '*VPN*' | Select-Object Name, InterfaceIndex, InterfaceDescription
Get-VpnConnection -Name 'Lab VPN' | Select-Object Name, ServerAddress, SplitTunneling

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

Привяжите префикс к профилю, а не к адаптеру

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

Add-VpnConnectionRoute -ConnectionName 'Lab VPN' -DestinationPrefix '10.77.0.0/16' -PassThru

Справка Add-VpnConnectionRoute описывает связь с подключением, и область телефонной книги важна: профиль отдельного пользователя и профиль всех пользователей — разные объекты. Этот механизм принадлежит собственному VPN-клиенту Windows, поэтому адаптер поставщика, управляемый собственной службой, может брать свои маршруты из совершенно другого источника политики.

Очистите старые маршруты, прежде чем добавлять новый

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

Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like '10.77.*'
Remove-NetRoute -DestinationPrefix '10.77.0.0/16' -NextHop '0.0.0.0' -Confirm:$false

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

Переподключитесь в другом порядке

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

rasdial 'Lab VPN' /disconnect
rasdial 'Lab VPN'
Find-NetRoute -RemoteIPAddress 10.77.5.20 | Select-Object -First 1

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

Знайте, чего маршрут не может

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

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