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

Тунелът пада, рутерът записва повторно свързване, а в локалната мрежа нищо не се е преместило. Нов адрес на WAN обезсилва външната връзка, без да променя нищо отвътре: адресът на източника на клиента се е променил, старото състояние на NAT сочи към източник, който вече не съществува, а отдалеченият партньор може все още да изпраща към предишния адрес. Възстановяването е нормално поведение и полезният въпрос е кое състояние не се е обновило.

Наименувайте събитието, преди да четете журнала

Проверете какво всъщност се е случило на слоя за достъп. Подновяването на лизинга от доставчика е едно събитие. 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

Първата команда показва текущата крайна точка и възрастта на ръкостискането за всеки партньор. Втората и третата показват дали външният интерфейс и маршрутът към крайната точка все още имат смисъл. Броят на conntrack е груба проверка за състояние, останало от предишния адрес, а журналът е мястото, където се записва причината за повторното свързване.

След това тествайте от клиент в локалната мрежа, а не от рутера. Ping с източник самия рутер използва различен път от препращания трафик, така че успешният ping от рутера доказва, че тунелът съществува, и нищо за достъпността на клиента.

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

Повторното свързване е правилно поведение за повечето внедрявания, така че целта не е да се предотврати. Решете вместо това какво да се случва с трафика по време на прекъсването: да се спре, да се задържи или да се премине към друг път. Това решение принадлежи на защитната стена и политиката за маршрутизация, а не на профила на VPN.

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