Как да различим маршрутите, изпратени от VPN, от статичните в Linux

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

Стъпка 1: назовете механизма, който инсталира префикси

Различните протоколи осигуряват достъпност по различни начини и наричането на всичко това обявление скрива разликата. Сървър OpenVPN изпраща директива за маршрут по контролния канал и клиентът я инсталира, освен ако pull филтър не я блокира. Конфигурацията на WireGuard изброява разрешените префикси локално и клиентът ги използва както за криптоключово маршрутизиране, така и за маршрутите, които добавя. Тунел IPsec се договаря селектори на трафик с партньора и ядрото инсталира маршрути от тези селектори.

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

Стъпка 2: сравнете таблицата при свързване

Запазете основната таблица при спрян тунел, вдигнете го, запазете я отново и сравнете двата записа. Всичко, което се е появило, принадлежи на жизнения цикъл на връзката, а всичко, което е останало, принадлежи на локалната конфигурация.

Запишете я с ip route show table main > /tmp/route-down.txt, свържете се и запишете отново. Направете същото за ip -6 route, ако сайтът използва IPv6, защото липсващ префикс там създава откази, които изглеждат несвързани с маршрутизирането.

Стъпка 3: четете метриката, не само наличието

Два записа за един и същ префикс могат да съществуват едновременно и ядрото избира по-ниската метрика. Статичен маршрут с метрика 50 ще продължава да побеждава изпратен маршрут с 100, дори и двата да са видими, затова „маршрутът е там“ и „трафикът го използва“ са различни твърдения.

Попитайте ядрото директно с ip route get 10.20.5.7 и прочетете интерфейса, който то посочва. Ако трафикът излиза през физическия адаптер, докато в таблицата стои маршрут на тунела, това се обяснява с метриката или дължината на префикса, а не с VPN клиента. Повторете проверката за хост, за който знаете, че е зад тунела, и за такъв, за който знаете, че не е, и разликата показва дали разделянето работи както е предвидено.

Стъпка 4: намерете записите, които надживяват тунела

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

Проверете постоянната страна на мястото, което използва дистрибуцията ви, било то unit на systemd-networkd, профил на NetworkManager или скрипт в директорията up на клиента. Поправката на живата таблица с ip route del се задържа само до следващото свързване. Приемайте това изтриване като проверка на хипотезата, а не като ремонта.

Когато далечният край осигурява грешно покритие, повдигнете въпроса при оператора, вместо да филтрирате всичко. Изхвърлянето на всички изпратени настройки също отнема DNS и политиката за разделен тунел, от които профилът зависи.

Стъпка 5: потвърдете обратния път, преди да обвинявате клиента

За връзка сайт-към-сайт или подмрежа зад тунела далечната страна се нуждае от маршрут обратно към адреса на вашия клиент и от включено препращане на шлюза. Еднопосочният път изглежда точно като грешка в маршрутизирането на клиента, освен че ръкостискането и изходящият пакет успяват и двете.

Филтрирането на обратния път добавя втори капан на шлюзовете с Linux. Отговор, който пристига на различен интерфейс от предвидения от маршрута, се изхвърля от строгия режим, а асиметричните пътища през два доставчика го задействат надеждно. Броячите на изхвърлените пакети на шлюза, а не на клиента, ще ви кажат дали причината е филтрирането.

Стъпка 6: тествайте ресурса, не ping

След като избраният маршрут е правилен, отворете действителния ресурс и потвърдете обратния трафик. Отговор на ping доказва пътя в една посока и нищо за услугата, а услуга, която отговаря на кеширана връзка, доказва още по-малко.

След това повторете цялата проверка след повторно свързване. Стойността на последователността е, че тя предсказва какво ще направи следващото свързване, затова и сравнението, и метриката принадлежат в билета.