OpenVPN паѓа по обновување на DHCP: задржете ја рутата до крајната точка

Тунелот се поврзува, потоа обновувањето на закупот на пристапната врска го убива, и дневникот го обвинува истекот на време наместо рута. Ништо во конфигурацијата на VPN не се промени, и тоа е трагата: нешто надвор од неа се промени. Настан на DHCP ја препиша адресата или портата, и рутата до домаќин што ја држеше крајната точка на тунелот достапна сега покажува кон следен скок што повеќе не постои. Ова е проблем на сопственост пред да биде проблем на рутирање.

Споредете го симптомот со полустандардните рути

Со redirect-gateway def1, OpenVPN инсталира 0.0.0.0/1 и 128.0.0.0/1 наместо да ја замени стандардната рута. Заедно двете го покриваат целиот адресен простор, и тие ја победуваат 0.0.0.0/0 само по должина на префиксот. Затоа секое одредиште без поконкретно совпаѓање влегува во тунелот.

Крајната точка бара исклучок. OpenVPN додава рута до домаќин кон адресата на серверот преку првобитната пристапна порта пред да влезат полустандардните, за да можат инкапсулираните пакети да излезат. Кога тој исклучок исчезнува, или задржува следен скок што повеќе не постои, сопствените надворешни пакети на тунелот се совпаѓаат со полустандардна рута и се враќаат назад во тунелот. Резултатот е врска што умира при следниот keepalive или ракување, без ништо во дневникот што личи на грешка во рутирањето.

Потврдете го обликот на табелата пред да допрете нешто друго. ip route show треба да ги наведе двете половини плус рута до домаќин за адресата на серверот; кога рутата до домаќин недостига, остатокот од истрагата има очигледна појдовна точка.

Зошто полустандардните победуваат без промена на метриката

Помала метрика не победува подолг префикс. Рутите /1 победуваат бидејќи јадрото прво го совпаѓа најконкретниот пат, така што покачувањето на метриката на стандардната рута не менува ништо за тоа каде оди сообраќајот наменет за тунелот. Бркањето метрики е најчестата погрешна свртница во оваа дијагноза.

Проверете го изборот со ip route get 203.0.113.10, заменувајќи го со вистинската адреса на серверот. Одговорот го именува интерфејсот и следниот скок што јадрото навистина би ги користело, што е поинформативно отколку да читате табела и да размислувате за неа.

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

Направете три снимки, не една

Соберете ја пристапната адреса, пристапната порта, одредиштето на крајната точка, избраната рута и сите правила за политика во три моменти: откако пристапната врска е конфигурирана, откако VPN се поврзал и по настанот на закупот или операторот. Секоја снимка е грст команди, и тие имаат смисла само заедно. Една снимка по дефектот ја запишува состојбата, а не преминот. Запишете ги командите во мала скрипта за секоја снимка да се направи на ист начин.

Чувајте ги снимките во една датотека со временски ознаки, бидејќи интересното прашање подоцна е редоследот. Дали настанот на DHCP дојде пред или откако OpenVPN ја освежи својата рута? Одговорот одлучува кој треба да го поправи. Временска ознака од погрешен часовник е полоша од никаква, па земете ја од домаќинот што ја поседува табелата за рутирање.

Кога крајната точка е конфигурирана како име наместо адреса, разрешете го и во секоја снимка. Промена на DNS на пристапната врска може да ја премести крајната точка без воопшто да се допре некоја рута.

Одлучете која компонента го освежува исклучокот

На систем со dhcpcd, куките се извршуваат од директориумот за куки и од излезната кука, а режимот на менаџерот се разликува по опфат од режимот по интерфејс. Што и да прави куката, таа мора да биде идемпотентна, бидејќи обновувањата можат да доаѓаат во налет.

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

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

Тестирајте го животниот циклус, не само повторното поврзување

Присилете обновување со dhcpcd -n eth0 или со ослободување и повторно земање на закупот, потоа проверете повторно ip route get за крајната точка. Направете го тоа двапати, бидејќи второто поминување ги фаќа куките што додаваат дупликат рути. Потоа рестартирајте, бидејќи постојаноста е друго својство од исправноста.

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