Как да премахнете остарял маршрут, оставен от VPN под Windows
Намерете записа, който наистина е остарял, прегледайте премахването му спрямо правилното хранилище на правила и потвърдете, че търсенето избира интерфейса, който очаквате.
Сесията ви приключи преди часове, адаптерът го няма, а маршрутът все още е в таблицата и сочи към интерфейс 42. Изтриването на този ред отнема една команда; решението, че е правилният ред, отнема четири проверки. Таблицата с маршрути се споделя, така че широкото премахване изважда пътища, които други връзки още използват, включително този, който носи тунела. Всяка стъпка по-долу стеснява целта, докато остане само един запис, който може да съвпадне.
1. Решете дали записът е остарял, или умишлен
Запис, който е преживял рестартиране, е бил записан някъде, а това някъде обикновено е решение, а не случайност. Разделното тунелиране зависи от маршрути, които изглеждат точно като остатъци, а правило, което прокарва един префикс през тунела, е неразличимо от остарял запис в един списък. Попитайте кога се е появил маршрутът: такъв, който съществува само докато тунелът е вдигнат, принадлежи на конфигурацията на клиента, така че команда за почистване е грешният инструмент. Премахнете умишлен маршрут и следващата връзка се проваля на стъпката, която никой не наблюдава.
Маршрутът до крайната точка заслужава собствено предупреждение. Когато клиентът добави маршрут до хоста на VPN сървъра, за да могат шифрованите пакети да го достигнат през локалната връзка, изтриването на този маршрут срутва тунела при следващото повторно свързване, а симптомът се чете като повреда на сървъра. Сравнете дестинацията с адреса, към който се свързва клиентът, преди да пипате каквото и да е: един публичен адрес, който съвпада с VPN сървъра, е външният път, а не боклук.
2. Запишете четирите полета, които именуват записа
Само префикс не е идентичност, защото два интерфейса могат да държат маршрути към една и съща дестинация. Отбележете префикса на дестинацията, индекса на интерфейса, следващия хоп и хранилището на правила, защото тези четири стойности описват точно един запис. Едно изброяване ви дава всички тях:
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric
Сортирането по метрика изважда нагоре маршрутите, които машината наистина предпочита, а именно там обикновено стои остатъкът. Сравнете записа, докато тунелът е вдигнат, и отново след като падне: маршрут, който си тръгва с адаптера, е бил на клиента, а този, който остава, е записан от нещо друго. Хранилището на правила е полето, което хората пропускат, и то обяснява повторната поява, защото запис, премахнат от активното хранилище, се връща след следващото обновяване на правилата. Запишете четирите стойности, преди да пуснете каквото и да е, което променя състоянието.
3. Прегледайте премахването, после премахнете един запис
Remove-NetRoute приема същия префикс и индекс на интерфейса, които Get-NetRoute отпечата, и има превключвател за преглед, така че нищо не трябва да се гадае. Пуснете двойката в този ред:
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42
Прегледът отпечатва обекта, който би изтрил, затова сравнете префикс, интерфейс и следващ хоп с бележките си, преди да отпуснете превключвателя. Нито един от редовете не достига постоянен запис, защото активното хранилище е по подразбиране; добавете -PolicyStore PersistentStore, когато идентифицираният маршрут живее там, иначе премахването изглежда успешно и записът се връща при следващото обновяване на правилата. Дръжте извънлентов път за възстановяване, когато сесията е отдалечена, защото изтриването на маршрута, който носи собствената ви връзка, я прекратява. Никога не посягайте към команда, която изчиства таблицата.
4. Открийте кой компонент го връща
Изтриването не е поправка, докато собственикът все още е настроен да инсталира маршрута. Собственикът обикновено е един от три: профилът на VPN клиента със списъка за разделно тунелиране, скрипт или планирана задача, която добавя маршрути при влизане, или домейн правило, приложено към машината. Проверете първо профила, защото той се изпълнява при всяко свързване:
Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore
Постоянните записи се виждат без свързване на каквото и да е, така че маршрут, който се връща след рестартиране без VPN сесия, почти винаги живее в това хранилище или в скрипт за стартиране. Поправете собственика там и ръчното премахване става проверка, а не лечение.
5. Проверете търсенето, съседите и бележката
Чистият резултат не е „маршрутът го няма“; той е търсене, което сега избира интерфейса, който очаквахте. Попитайте машината накъде ще тръгне пакет към засегнатия префикс, защото остатъкът все още сочи мъртвия индекс, а чистият отговор сочи интерфейса на връзката или правилния шлюз. Find-NetRoute отговаря на това за един адрес наведнъж:
Find-NetRoute -RemoteIPAddress 10.20.4.7
След това тествайте съсед: изберете втори префикс, който разделното тунелиране още изисква, и потвърдете, че търсенето му е непроменено, защото премахването на един маршрут в повече е грешката, която това почистване кани. Опитайте отново приложението, което първоначално се провали, и запишете кой компонент притежава префикса сега. Документацията на Microsoft за Get-NetRoute изброява полетата, които записахте във втората стъпка. След шест месеца точно тази бележка ще попречи същият запис да бъде диагностициран два пъти.