Како да ги разликувате рутите што ги турка 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 го докажува патот во една насока и ништо за услугата, а услуга што одговара на кеширана врска докажува уште помалку.

Потоа повторете ја целата проверка по повторно поврзување. Вредноста на редоследот е што предвидува што ќе направи следното поврзување, затоа и споредбата и метриката припаѓаат во тикетот.