Зошто избришана VPN рута се враќа по повторно поврзување

Рутата што сте ја избришале рачно се враќа по следното повторно поврзување, а табелата изгледа точно како порано. Ова не е грешка во рутирањето: нешто повторно го создава записот од конфигурацијата или од дејство во животниот циклус на врската. Повеќето runbook-ови застануваат кај активната табела, затоа бришењето изгледа дека работи една минута, а потоа не успева. Идентификувајте го сопственикот, сменете го и докажете го при повторно поврзување.

Кој ја инсталирал рутата

Започнете со список на кандидати, а не со поправка. VPN профилот може да носи свои рути, серверот може да ги push-ува при поврзување, профилот на мрежниот менаџер може да ги декларира, boot единица или скрипта може да ги додаде, а IPsec имплементациите инсталираат рути за селекторите на сообраќај што ги договараат. Правилата за рутирање по политика исто така можат целосно да го пренасочат сообраќајот кон друга табела.

Времето ги одделува побрзо од конфигурациската археологија. Записот што се појавува во моментот кога интерфејсот се подига му припаѓа на клиентот; оној што пристигнува една секунда подоцна обично доаѓа од server push; оној што постои при подигање им припаѓа на зачуваната конфигурација. Забележете ја табелата пред и по поврзување, исклучување и рестарт, и шемата ќе го именува сопственикот. Рутата што се враќа само кога услугата се рестартира укажува на единица, а не на VPN.

Прочитајте ја табелата пред да ја уредите

Гледајте го сопствениот поглед на јадрото, а не зачувана датотека. Колоната за протокол покажува што го инсталирало секој запис:

ip route show
ip route show table all
ip rule show

Полето за протокол, метриката и бројот на табелата ви кажуваат дали гледате статичен запис, запис создаден од јадрото или нешто додадено од демон. Списокот со правила е важен затоа што пребарувањето може целосно да ја напушти главната табела, што го прави уредувањето таму невидливо за апликацијата што ја дебагирате. Прочитајте ја линијата од лево кон десно: дестинација, порта, уред, протокол и метрика.

Потоа прашајте го јадрото која рута навистина би ја користело. Заштитената адреса е подобра сонда од јавната:

ip route get 10.20.5.7

Сменете го сопственикот, а не симптомот

Откако сопственикот ќе биде познат, промената му припаѓа на тој сопственик. Отстранете ја рутата од профилот на клиентот, поправете ја push-уваната рута на серверот или уредете ја врската на мрежниот менаџер наместо да додадете конкурентна постојана рута што победува по метрика. Две правила што се борат едно против друго создаваат табела што подоцна никој не може да ја објасни.

Задржете го исклучувањето на крајната точка. Рутата до хост што ја испраќа сопствената јавна адреса на VPN серверот преку физичката порта е она што ги одржува надворешните тунелски пакети во движење; избришете ја и тунелот се обидува да се носи себеси. Во split-tunnel профил, истата грижа важи за локалните подмрежи што треба да го заобиколат тунелот.

Поврзете се повторно и проверете ги двата пата

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

ip route get 10.20.5.7
ip route get 198.51.100.20

Првата треба да се реши преку тунелскиот интерфејс, а втората преку физичката порта. Ако двете се решат преку тунелот, исклучувањето недостига; ако ниту една, промената на профилот не стапила во сила и гледате друг сопственик од оној што мислевте.

Запишете ја целта на рутата, нејзиниот сопственик и колку долго треба да живее. Таа белешка е она што го спречува следниот човек да го повтори истиот циклус на бришење и повторно поврзување.