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 връзката, или unit, подреден след вдигането на връзката за достъп. Статичен маршрут, добавен от кука, работи до следващата промяна на шлюза, а после се проваля по абсолютно същия начин. Ако все пак използвате кука, накарайте я да чете текущия шлюз по време на изпълнение, вместо да втвърдявате този, който виждате днес.

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

Тествайте жизнения цикъл, не само повторното свързване

Принудете подновяване с dhcpcd -n eth0 или чрез освобождаване и повторно вземане на наема, после проверете отново ip route get за крайната точка. Направете го два пъти, защото второто минаване хваща куки, които добавят дублиращи маршрути. После рестартирайте, защото устойчивостта е различно свойство от коректността.

Тунел, който оцелява след подновяване и рестарт, има собственик и работещо изключение. Такъв, който оцелява само след ръчен рестарт, няма нито едно от двете и ще се провали при следващото събитие, което не можете да планирате.