WAN IP се смени и тунелот падна: проверките по ред

Тунелот паѓа, рутерот запишува повторно поврзување, а на LAN ништо не се помести. Новата WAN адреса ја поништува надворешната врска без да смени ништо внатре: изворната адреса на клиентот се смени, старата NAT состојба покажува на извор што повеќе не постои, а оддалечениот партнер можеби сe уште испраќа на претходната адреса. Враќањето е нормално однесување, а корисното прашање е која состојба не се ажурира.

Именувајте го настанот пред да го читате дневникот

Проверете што навистина се случило на слојот за пристап. Обновувањето на закупот од провајдерот е еден настан. Повторно поврзаната PPPoE сесија е друг. Рестартиран оптички модем или префрлање на WAN од еден на друг канал ја менува надворешната адреса или нејзиниот пат на трет начин. Тоа не е истиот настан и не оставаат исти остатоци.

Линијата за повторно поврзување во дневникот на VPN исто така не е доказ за промена на WAN. Временското ограничување за неактивност, интервалот за повторна автентикација и откривањето мртов партнер сите создаваат повторни поврзувања без никаква промена на адресата. Пред да заклучите нешто, споредете ги временските ознаки од дневникот за пристап со дневникот на VPN и држете го прозорецот за споредба доволно широк за да фатите промена што се случила ноќе.

Роамингот и повторното поврзување се различни протоколи

WireGuard има автентициран роаминг вграден во протоколот: кога партнерот прима правилно автентициран пакет од нова изворна адреса, ја ажурира крајната точка на тој партнер. Брзиот почеток на WireGuard ја опишува конфигурацијата на партнерот што го овозможува тоа, поради што клиент на променлива адреса често се враќа без видлив рестарт.

OpenVPN стандардно се однесува поинаку. UDP сесијата може да заврши и повторно да се поврзе, а опционалното однесување float му дозволува на автентициран партнер да продолжи од нова адреса таму каде што конфигурацијата го дозволува. Тунелите засновани на TCP се построги, бидејќи самата врска е врзана за парот адреси. Таа разлика одлучува дали враќањето ќе изгледа невидливо или ќе се објави во дневникот секој пат.

Ниту едно од двете однесувања не кажува ништо за апликациите внатре. Вратен тунел не враќа TCP сесија што партнерот веќе ја сметал за мртва.

Состојба што тунелот не ја поседува

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

Рутите и правилата за политика може да укажуваат на старата порта или интерфејс. Збир правила што бил точен пред префрлање на WAN може да покажува на уред што сега е исклучен, што создава тунел што се пријавува како поврзан и сообраќај што не оди никаде. Динамичниот DNS за сервер што го хостирате е одделен проблем од клиент што добива нов извор. Записот треба да се ажурира за да ве најдат оддалечените клиенти, и ниту една конфигурација на страната на клиентот не компензира адреса што преводот повисоко нема да ја пренесе.

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

Редоследот подолу оди од надворешната врска навнатре, и запирањето на првиот чекор што не успеал е она што го прави корисен: секоја проверка го исклучува слојот над неа. Држете го тој редослед дури и кога дефектот изгледа очигледен.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Првата команда ја покажува тековната крајна точка и возраста на ракувањето за секој партнер. Втората и третата покажуваат дали надворешниот интерфејс и рутата до крајната точка сe уште имаат смисла. Бројот на conntrack е груба проверка за состојба што останала од претходната адреса, а дневникот е местото каде што се запишува причината за повторното поврзување.

Потоа тестирајте од клиент на LAN, а не од рутерот. Ping што го праќа самиот рутер користи друг пат од препратениот сообраќај, па успешен ping од рутерот докажува дека тунелот постои и ништо за достапноста на клиентот.

Одредете го очекуваното однесување и запишете го

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

Запишувајте ги настаните за пристап и времињата на повторно поврзување заедно една недела. Повторените промени без соодветен настан за пристап укажуваат на услугата за пристап, и замената на профилот на VPN нема да поправи канал што постојано преговара одново. Еден пар записи во истата минута го решава прашањето за тој инцидент и му дава на следниот основна линија.