Test obnovy VPN serveru po restartu: co zkontrolovat nejdřív

Restartujte server, když nikdo není přihlášen, a poté se připojte ze sítě, kterou nekontrolujete. Tento jediný test odpovídá na otázku, zda je obnova skutečná, protože tunel, který funguje jen poté, co někdo ručně spustí příkaz, není obnova, ale oprava. Většina kontrol končí příliš brzy: démon se hlásí jako aktivní, rozhraní se zvedne, a stránka se přesto nenačte. Mezera je téměř vždy v trvalosti částí kolem tunelu, ne v samotném příkazu tunelu.

Čtyři vlastníci, čtyři různé testy

Před restartem pojmenujte, co má tunel vrátit. Test, který provádíte, i oprava, kterou aplikujete, závisí na této odpovědi, a existují čtyři obvyklí vlastníci: systemd unit pro démona VPN, unit instance wg-quick pro rozhraní WireGuard, runtime kontejnerů nebo profil správce sítě. Pokud vlastníka nedokážete pojmenovat, zastavte se a najděte ho, protože test restartu bez očekávané cesty spuštění vám řekne jen to, že se něco stalo.

Každý vlastník drží svou konfiguraci jinde. Server OpenVPN spravovaný systemd čte konfiguraci při spuštění, takže to, co je v souboru při bootu, je to, co běží. Rozhraní wg-quick odvozuje adresy, trasy a DNS ze stejného souboru, což znamená, že rozhraní zvednuté ručně z shellu a nikdy nepovolené jako unit se nevrátí. Kontejner vrátí svůj vstupní bod, ale ne změny firewallu hostitele, pokud ty nežijí mimo kontejner.

Nejprve základní stav, jinak výsledek nic neznamená

Zachyťte pracovní stav, dokud funguje: adresy na tunelu, trasy pro klientskou podsíť, pravidla NAT nebo přesměrování, naslouchající socket a sysctl přesměrování. ip addr show wg0, ip route, nft list ruleset nebo iptables-save, ss -lunp a sysctl net.ipv4.ip_forward na většině hostitelů stačí.

Zapište, jak je služba nakonfigurována ke spuštění, ne jen že běží. systemctl is-enabled wg-quick@wg0 a systemctl is-active wg-quick@wg0 odpovídají na různé otázky a při bootu rozhoduje povolený stav, jak je popsáno v systemctl(1). U OpenVPN zkontrolujte, kterou šablonu hostitel používá, protože openvpn@server a openvpn-server@server jsou různé unity s různými výchozími hodnotami.

Proveďte restart a přečtěte první selhání

Restartujte záměrně, v okně, které jste si vybrali, s otevřenou konzolí nebo mimopásmovou cestou. Sledujte pořadí událostí, ne konečný stav: hostitel dostupný, unit aktivován, rozhraní přítomno, trasy nainstalovány, pravidla firewallu přítomna, naslouchač svázán, klient přijat. První krok, který se nestane, je zjištění; vše po něm je šum.

Démon může být aktivní, zatímco tunel je nepoužitelný, a to je nejčastější falešný průchod. Spuštění může skončit dřív, než je síť online, pokud unit čeká jen na network.target místo network-online.target. Odkazované soubory jako certifikáty, klíče nebo CRL mohou být v tu chvíli nečitelné, protože připojení nebo cesta k tajemstvím ještě není připravena. Ani jeden z problémů se neukáže v systemctl status, dokud nepřečtete journal unit.

Testujte zvenčí hostitele. Klient na stejné LAN může uspět přes trasu, kterou by žádný vzdálený klient nepoužil, a SSH relace na stroj o tunelu nic nedokazuje. Připojte se, přeložte interní jméno, dosáhněte soukromého zdroje a pak se jednou znovu připojte, abyste potvrdili, že stav odvolání a klíče stále platí.

Tři podmínky, které rozhodují o vaší opravě

Pokud se tunel vrátí, ale klienti se nikam nedostanou, selhání je v směrování nebo trvalosti NAT. Pokud klienti nedokážou ani dokončit handshake, selhání je v rozhraní nebo v autentizačním materiálu. Pokud se služba nikdy nespustí, selhání je v souboru unit nebo v jeho závislostech. Tyto tři větve vedou k různým opravám, a proto slepý restart bez základního stavu stojí víc času, než ušetří.

Opravu proveďte tam, kde je nastavení vlastněno. Dejte přesměrování do sysctl drop-inu, dejte pravidla NAT do sady pravidel, která se načítá při bootu, povolte unit místo jeho spouštění a držte tajemství na cestě, která existuje před spuštěním unit. Přidání spánku do unit závislost skrývá, místo aby ji deklarovalo.

Zapište výsledek do runbooku

Zapište, co se vrátilo samo, co jste museli spustit a jak dlouho mezera trvala. Uveďte přesné příkazy, kterými jste ověřovali, aby další člověk test zopakoval, místo aby vymýšlel nový. Pokud některý krok vyžadoval ruční příkaz, ten příkaz patří do konfigurace, ne do runbooku jako trvalý krok.

Potom naplánujte další test na dobu po další změně síťového zásobníku hostitele, ne na kalendářní datum za šest měsíců. Režim selhání, před kterým se chráníte, je dočasný příkaz, který působil trvale, a ty se objevují přesně tehdy, když někdo upraví pravidla firewallu nebo přesune službu do nového unitu.