Како разликовати руте које гура 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: пронађите уносе који надживљавају тунел

Статичке руте преживљавају прекид по дизајну и одатле долазе застарели уноси. Трајна рута ка интерфејсу који више не постоји може тихо прогутати подмрежу, а она ка поново употребљеном имену интерфејса може после рестарта послати приватни саобраћај кроз погрешна врата.

Проверите трајну страну на месту које користи ваша дистрибуција, било да је јединица systemd-networkd, профил NetworkManager или скрипта у up директоријуму клијента. Исправка живе табеле помоћу ip route del траје само до следећег повезивања. Третирајте то брисање као тест хипотезе, а не као поправку.

Где далеки крај даје погрешну покривеност, подигните то код оператера уместо да филтрирате све. Одбацивање свих гурнутих поставки одбацује и DNS и политику подељеног тунела од којих зависи профил.

Корак 5: потврдите повратни пут пре него што оптужите клијента

За везу локација-локација или подмрежу иза тунела, далека страна захтева руту назад ка адреси вашег клијента и укључено прослеђивање на пролазу. Једносмерни пут изгледа тачно као грешка рутирања клијента, само што руковање и излазни пакет обоје успевају.

Филтрирање повратног пута додаје другу замку на Linux пролазе. Одговор који стигне на други интерфејс од оног који рута предвиђа одбацује се у строгом режиму, а асиметрични путеви кроз два провајдера то поуздано покрећу. Бројачи одбацивања на пролазу, а не на клијенту, кажу да ли је филтрирање узрок.

Корак 6: тестирајте ресурс, не ping

Када је изабрана рута исправна, отворите стварни ресурс и потврдите повратни саобраћај. Одговор на ping доказује пут у једном смеру и ништа о услузи, а услуга која одговара на кеширану везу доказује још мање.

Затим поновите целу проверу после поновног повезивања. Вредност редоследа је у томе што предвиђа шта ће следеће повезивање урадити, зато и поређење и метрика припадају тикету.