Метриката на VPN маршрут се промени след свързване: какво означава това
По-ниската метрика само решава равенство между еднакво конкретни маршрути. Прочетете правилото на политиката, префикса и хост маршрута на крайната точка, преди да редактирате какъвто и да е номер на VPN маршрут.
Свързвате VPN, изпълнявате route print и маршрутът по подразбиране вече носи много по-ниска метрика отпреди. Естественият извод е, че VPN е поел маршрута по подразбиране, защото номерът му е по-малък. Понякога точно това се е случило. Често метриката изобщо не е решаващият фактор и редактирането ѝ не променя нищо, защото изборът е направен по-рано — чрез дължина на префикса или чрез правило на политиката.
Симптомът е реален: трафикът, който преди излизаше през Wi-Fi адаптера, сега излиза през тунела, или обратното. Метриката е един вход за търсене, което се изпълнява във фиксиран ред, и точно този ред трябва да прочетете, преди да пипате число.
С какво числото всъщност се състезава
Първото сравнение е конкретност, не предпочитание. Маршрут за 10.20.0.0/16 побеждава 10.0.0.0/8 и двата побеждават 0.0.0.0/0, каквото и да казват метриките им. VPN, който инсталира маршрут по подразбиране с най-ниската метрика на машината, пак губи от всеки по-конкретен маршрут, който съвпада с дестинацията, включително хост маршрута, който клиентът инсталира за собствения си сървър.
Затова понижаването на метриката на маршрут по подразбиране не може да принуди директно свързана подмрежа да влезе в тунела. Ако искате тази подмрежа вътре във VPN, добавете маршрут за префикса или изберете таблицата на тунела с правило на политиката. Метриката е грешният лост за тази работа.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linux решава таблицата преди метриката
В Linux ядрото първо се обръща към базата с политики. ip rule изброява правилата и таблиците, които те избират, а ip route get 203.0.113.10 показва таблицата, маршрута и адреса на източника, които ядрото действително би използвало за тази дестинация. Метрика в таблица 100 никога не се състезава с маршрут в главната таблица, защото правилото е избрало таблицата, преди да се сравнява каквато и да е метрика.
Затова маршрут може да изглежда правилен в ip route show table all и все пак да не пренася трафик. Прочетете правилото, което е съвпаднало, после таблицата, която то е избрало, после сравнете маршрутите в нея. Ако е избрана грешната таблица, никаква редакция на метриката в другата таблица няма да помогне.
Windows комбинира две метрики
Windows няма база с политики по подразбиране, но комбинира метрика на маршрута с метрика на интерфейса, а автоматичната метрика на интерфейса може да се променя със скоростта на връзката и състоянието на адаптера. Затова един и същ маршрут може да се държи различно след появата на докинг станция или виртуален адаптер. Find-NetRoute -RemoteIPAddress 203.0.113.10 показва избрания адрес на източника, следващия хоп и интерфейса, което е по-близо до истинското решение от суровата таблица.
Четете стойностите на маршрута и интерфейса заедно. Повишаването на метрика на интерфейса може да премести трафик без нито един запис за маршрут да се промени, а VPN клиент, който притежава маршрутите си, ще ги преинсталира при повторно свързване и ще отхвърли редакцията ви.
Дръжте крайната точка на тунела извън тунела
Всеки тунел се нуждае от път до собствения си сървър, който не минава през тунела. Клиентите инсталират хост маршрут за крайната точка през физическия шлюз и този маршрут трябва да остане по-конкретен от маршрута по подразбиране, който клиентът добавя. Изтрийте го или оставете тунела да спечели търсенето за този адрес — и инкапсулираните пакети ще се опитат да влязат в тунела, който трябва да изградят. Връзката се проваля или зацикля.
Проверявайте този хост маршрут преди и след всяка промяна на метриката: той трябва да сочи към физическия следващ хоп и да оцелее при повторно свързване. Ако клиентът го притежава, променете профила или управляваната конфигурация, а не стойност по време на изпълнение, която ще бъде презаписана.
Проверете двете семейства адреси и контекста на приложението
IPv4 и IPv6 са отделни решения с отделни таблици. VPN може да пренася IPv4, докато IPv6 продължава да използва локалния рутер, и промяна на метриката в едното семейство не казва нищо за другото. Проверете и двете, после проверете контекста на приложението. Процес, вързан към интерфейс, namespace на контейнер или VPN за отделно приложение може да вижда друга таблица от вашата обвивка.
Проверявайте с инструмента, който съобщава решението за реалната дестинация, а не с пълния списък на таблицата. Ако избраният маршрут е този, който дизайнът предвижда, спрете. Метрика, която не е най-малкото число на екрана, не е дефект и принудата тя да е най-малката може да счупи пътя до крайната точка, от който тунелът зависи.