Маршрут 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

Потрібний результат — не те, що адаптер один раз збереже свій номер. А те, що маршрут з'явиться з будь-яким номером, який отримає з'єднання, кожного разу, і зникне, коли з'єднання закриється. Подвійне повторне підключення — найдешевший спосіб розрізнити ці результати.

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

Маршрут із профілю дає шлях і більше нічого. Він не відкриває віддалений міжмережевий екран, не створює зворотний маршрут на далекому краї і не вирішує два сайти з однаковим діапазоном адрес; кожне з цього — окрема конфігурація з окремим власником. Тому підтвердження шляху — початок приймального тесту, а не весь тест.

Тримайте список префіксів при профілі та зазначайте, у якій області його додано, щоб наступна людина могла прочитати задуманий проєкт, а не виводити його з таблиці маршрутів. Маршрути, що існують лише в чиїйсь пам'яті, — це ті, що після чергового повторного підключення перебудовуються неправильно. Коментар в один рядок у нотатках про розгортання коштує менше, ніж цілий день повторного пошуку.