Test obnovy VPN servera po reštarte: čo skontrolovať najskôr

Reštartujte server, keď nikto nie je prihlásený, a potom sa pripojte zo siete, ktorú nekontrolujete. Tento jediný test odpovedá, či je obnova skutočná, pretože tunel, ktorý funguje až po tom, čo niekto ručne spustí príkaz, nie je obnova, ale oprava. Väčšina kontrol končí príliš skoro: démon sa hlási ako aktívny, rozhranie sa zdvihne, a stránka sa napriek tomu nenačíta. Medzera je takmer vždy v trvalosti častí okolo tunela, nie v samotnom príkaze tunela.

Štyria vlastníci, štyri rôzne testy

Pred reštartom pomenujte, čo má tunel vrátiť. Test, ktorý vykonávate, a oprava, ktorú aplikujete, závisia oba od tejto odpovede, a existujú štyri obvyklí vlastníci: systemd unit pre démona VPN, unit inštancie wg-quick pre rozhranie WireGuard, runtime kontajnerov alebo profil správcu siete. Ak vlastníka neviete pomenovať, zastavte sa a nájdite ho, pretože test reštartu bez očakávanej cesty spustenia vám povie len to, že sa niečo stalo.

Každý vlastník drží svoju konfiguráciu inde. Server OpenVPN spravovaný systemd číta konfiguráciu pri spustení, takže to, čo je v súbore pri boote, je to, čo beží. Rozhranie wg-quick odvodzuje adresy, trasy a DNS z toho istého súboru, čo znamená, že rozhranie zdvihnuté ručne zo shellu a nikdy nepovolené ako unit sa nevráti. Kontajner vráti svoj vstupný bod, ale nie zmeny firewallu hostiteľa, ak tieto nežijú mimo kontajnera.

Najprv základný stav, inak výsledok nič neznamená

Zachyťte pracovný stav, kým funguje: adresy na tuneli, trasy pre klientsku podsievť, pravidlá NAT alebo presmerovania, počúvajúci socket a sysctl presmerovania. ip addr show wg0, ip route, nft list ruleset alebo iptables-save, ss -lunp a sysctl net.ipv4.ip_forward na väčšine hostiteľov stačia.

Zapíšte, ako je služba nakonfigurovaná na spustenie, nielen že beží. systemctl is-enabled wg-quick@wg0 a systemctl is-active wg-quick@wg0 odpovedajú na rôzne otázky a pri boote rozhoduje povolený stav, ako je opísané v systemctl(1). Pri OpenVPN skontrolujte, ktorú šablónu hostiteľ používa, pretože openvpn@server a openvpn-server@server sú rôzne unity s rôznymi predvolenými hodnotami.

Vykonajte reštart a prečítajte prvé zlyhanie

Reštartujte zámerne, v okne, ktoré ste si vybrali, s otvorenou konzolou alebo mimopásmovou cestou. Sledujte poradie udalostí, nie konečný stav: hostiteľ dostupný, unit aktivovaný, rozhranie prítomné, trasy nainštalované, pravidlá firewallu prítomné, počúvajúci zviazaný, klient prijatý. Prvý krok, ktorý sa nestane, je zistenie; všetko po ňom je šum.

Démon môže byť aktívny, kým je tunel nepoužiteľný, a to je najčastejší falošný prechod. Spustenie sa môže dokončiť skôr, než je sieť online, ak unit čaká len na network.target namiesto network-online.target. Odkazované súbory ako certifikáty, kľúče alebo CRL môžu byť v tom momente nečitateľné, pretože pripojenie alebo cesta k tajomstvám ešte nie je pripravená. Ani jeden z problémov sa neukáže v systemctl status, kým neprečítate journal unit.

Testujte zvonku hostiteľa. Klient v tej istej LAN môže uspieť cez trasu, ktorú by žiadny vzdialený klient nevyužil, a SSH relácia na stroj o tuneli nič nedokazuje. Pripojte sa, preložte interné meno, dosiahnite súkromný zdroj a potom sa raz znova pripojte, aby ste potvrdili, že stav odvolania a kľúče stále platia.

Tri podmienky, ktoré rozhodujú o vašej oprave

Ak sa tunel vráti, ale klienti sa nikam nedostanú, zlyhanie je v smerovaní alebo trvalosti NAT. Ak klienti nedokážu ani dokončiť handshake, zlyhanie je v rozhraní alebo v autentizačnom materiáli. Ak sa služba nikdy nespustí, zlyhanie je v súbore unit alebo v jeho závislostiach. Tieto tri vetvy vedú k rôznym opravám, a preto slepý reštart bez základného stavu stojí viac času, než ušetrí.

Opravu urobte tam, kde je nastavenie vlastnené. Dajte presmerovanie do sysctl drop-inu, dajte pravidlá NAT do sady pravidiel, ktorá sa načítava pri boote, povoľte unit namiesto jeho spúšťania a držte tajomstvá na ceste, ktorá existuje pred spustením unit. Pridanie spánku do unit závislosť skrýva, namiesto aby ju deklarovalo.

Zapíšte výsledok do runbooku

Zapíšte, čo sa vrátilo samo, čo ste museli spustiť a ako dlho medzera trvala. Uveďte presné príkazy, ktorými ste overovali, aby ďalší človek test zopakoval, a nie vymýšľal nový. Ak niektorý krok vyžadoval ručný príkaz, ten príkaz patrí do konfigurácie, nie do runbooku ako trvalý krok.

Potom naplánujte ďalší test na čas po ďalšej zmene sieťového zásobníka hostiteľa, nie na kalendárny dátum o šesť mesiacov. Režim zlyhania, pred ktorým sa chránite, je dočasný príkaz, ktorý pôsobil trvalo, a tie sa objavujú presne vtedy, keď niekto upraví pravidlá firewallu alebo presunie službu do nového unitu.