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

Резултатът, който искате, не е адаптерът да запази номера си веднъж. А е маршрутът да се появява с какъвто номер получи връзката, всеки път, и да изчезва, когато връзката се затвори. Двойното повторно свързване е най-евтиният начин да различите тези изходи.

Знайте какво не може маршрутът

Маршрутът от профил дава път и нищо друго. Той не отваря отдалечена защитна стена, не създава обратен маршрут в далечния край и не решава два обекта с еднакъв диапазон от адреси; всяко от тези е отделна конфигурация с отделен собственик. Затова потвърждаването на пътя е началото на приемателния тест, а не целият той.

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