Проверка на възстановяването на VPN сървър след рестарт: какво да проверите първо

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

Четири собственика, четири различни теста

Преди рестарта назовете какво трябва да върне тунела. Тестът, който изпълнявате, и поправката, която прилагате, зависят от този отговор, а има четири обичайни собственика: systemd unit за демона на VPN, unit на инстанция wg-quick за интерфейс WireGuard, runtime за контейнери или профил на мрежов мениджър. Ако не можете да назовете собственика, спрете и го намерете, защото тест за рестарт без очакван път за стартиране ви казва само, че нещо се е случило.

Всеки собственик пази конфигурацията си на различно място. OpenVPN сървър, управляван от systemd, чете конфигурацията си при стартиране, така че това, което е във файла при зареждане, е това, което се изпълнява. Интерфейс wg-quick получава адресите, маршрутите и DNS от същия файл, което означава, че интерфейс, вдигнат на ръка от шел и никога не активиран като unit, няма да се върне. Контейнерът връща своята входна точка, но не и промените в защитната стена на хоста, освен ако те не живеят извън контейнера.

Първо базовата линия, иначе резултатът не значи нищо

Запишете работещото състояние, докато то работи: адреси на тунела, маршрути за клиентската подмрежа, NAT или правила за препращане, слушащия сокет и sysctl за препращане. ip addr show wg0, ip route, nft list ruleset или iptables-save, ss -lunp и sysctl net.ipv4.ip_forward са достатъчни на повечето хостове.

Запишете как услугата е конфигурирана да стартира, а не само че работи. systemctl is-enabled wg-quick@wg0 и systemctl is-active wg-quick@wg0 отговарят на различни въпроси и именно активираното състояние има значение при зареждане, както е описано в systemctl(1). За OpenVPN проверете кой шаблон използва хостът, тъй като openvpn@server и openvpn-server@server са различни unit с различни настройки по подразбиране.

Изпълнете рестарта и прочетете първия отказ

Рестартирайте нарочно, в избран от вас прозорец, с отворена конзола или извънлентов път. Наблюдавайте реда на събитията, а не крайното състояние: хостът е достъпен, unit е активиран, интерфейсът е налице, маршрутите са инсталирани, правилата на защитната стена са налице, слушателят е свързан, клиентът е приет. Първата стъпка, която не се случи, е находката; всичко след нея е шум.

Демонът може да е активен, докато тунелът е неизползваем, и това е най-честият фалшив успех. Стартирането може да завърши преди мрежата да е онлайн, ако unit чака само network.target вместо network-online.target. Реферирани файлове като сертификати, ключове или CRL може да са нечетими в този момент, защото монтиране или път до тайни все още не е готов. Нито един от двата проблема не се показва в systemctl status, докато не прочетете журнала на unit.

Тествайте отвън хоста. Клиент в същата LAN може да успее през маршрут, който никой отдалечен клиент не би използвал, а SSH сесия към машината не доказва нищо за тунела. Свържете се, резолвнете вътрешно име, достигнете частния ресурс, след което се свържете отново веднъж, за да потвърдите, че състоянието на отзоваване и ключовете все още важат.

Трите условия, които определят поправката ви

Ако тунелът се върне, но клиентите не достигат до нищо, отказът е в маршрутизацията или постоянството на NAT. Ако клиентите дори не могат да завършат ръкостискане, отказът е в интерфейса или материала за удостоверяване. Ако услугата никога не стартира, отказът е в unit файла или неговите зависимости. Тези три клона водят до различни поправки, затова сляп рестарт без базова линия струва повече време, отколкото спестява.

Направете поправката там, където настройката се притежава. Поставете препращането в sysctl drop-in, поставете NAT правилата в набора от правила, който се зарежда при стартиране, активирайте unit вместо да го стартирате и пазете тайните на път, който съществува преди стартирането на unit. Добавянето на изчакване към unit скрива зависимост, вместо да я декларира.

Запишете резултата в runbook

Запишете какво се върна само, какво трябваше да стартирате и колко дълго продължи разликата. Включете точните команди, с които проверявахте, за да повтори следващият човек теста, вместо да измисля нов. Ако някоя стъпка е изисквала ръчна команда, тази команда принадлежи в конфигурацията, а не в runbook като постоянна стъпка.

След това планирайте следващия тест за след следващата промяна в мрежовия стек на хоста, а не за календарна дата след шест месеца. Режимът на отказ, от който се пазите, е временна команда, която е изглеждала постоянна, и те се появяват точно когато някой редактира правилата на защитната стена или мести услуга в нов unit.