VPN-kiszolgáló helyreállásának tesztelése újraindítás után: mit ellenőrizzen először

Indítsa újra a kiszolgálót úgy, hogy senki nincs bejelentkezve, majd csatlakozzon egy olyan hálózatról, amelyet nem irányít. Ez az egyetlen teszt válaszol arra, hogy a helyreállás valódi-e, mert az az alagút, amely csak akkor működik, ha valaki kézzel futtat egy parancsot, nem helyreállás, hanem javítás. A legtöbb ellenőrzés túl korán megáll: a daemon aktívnak látszik, az interfész feljön, és az oldal mégsem töltődik be. A hiány szinte mindig az alagút körüli részek tartósságában van, nem magában az alagút parancsában.

Négy tulajdonos, négy különböző teszt

Az újraindítás előtt nevezze meg, minek kell visszahoznia az alagutat. A futtatott teszt és az alkalmazott javítás is ettől a választól függ, és négy gyakori tulajdonos van: egy systemd-egység a VPN-daemonhoz, egy wg-quick-példányegység a WireGuard-interfészhez, egy konténer-futtatókörnyezet vagy egy hálózatkezelő profil. Ha nem tudja megnevezni a tulajdonost, álljon meg és keresse meg, mert a várt indítási útvonal nélküli újraindítási teszt csak azt mondja meg, hogy történt valami.

Minden tulajdonos máshol tartja a konfigurációját. A systemd által kezelt OpenVPN-kiszolgáló indításkor olvassa a konfigurációját, tehát ami a fájlban van a rendszerindításkor, az fut. A wg-quick-interfész ugyanabból a fájlból származtatja a címeit, útvonalait és DNS-ét, ami azt jelenti, hogy a héjból kézzel felhozott és soha egységként nem engedélyezett interfész nem tér vissza. A konténer visszahozza a belépési pontját, de a gazdagép tűzfal-módosításait nem, hacsak azok a konténeren kívül élnek.

Először az alapállapot, különben az eredmény semmit sem jelent

Rögzítse a működő állapotot, amíg működik: címek az alagúton, útvonalak az ügyfél alhálózatához, NAT- vagy továbbítási szabályok, a figyelő socket és a továbbítási sysctl. ip addr show wg0, ip route, nft list ruleset vagy iptables-save, ss -lunp és sysctl net.ipv4.ip_forward a legtöbb gazdagépen elegendő.

Jegyezze fel, hogyan van a szolgáltatás az indításra beállítva, nem csak azt, hogy fut. systemctl is-enabled wg-quick@wg0 és systemctl is-active wg-quick@wg0 különböző kérdésekre válaszolnak, és a rendszerindításkor az engedélyezett állapot számít, ahogy a systemctl(1) leírja. Az OpenVPN esetében ellenőrizze, melyik sablont használja a gazdagép, mert a openvpn@server és a openvpn-server@server különböző egységek eltérő alapértelmezésekkel.

Hajtsa végre az újraindítást, és olvassa el az első hibát

Indítson újra szándékosan, egy Ön által választott időablakban, nyitott konzollal vagy sávon kívüli útvonallal. A végállapot helyett az események sorrendjét figyelje: a gazdagép elérhető, az egység aktiválva, az interfész jelen van, az útvonalak telepítve, a tűzfalszabályok jelen vannak, a figyelő hozzákötve, az ügyfél elfogadva. Az első lépés, amely nem történik meg, a lelet; minden utána zaj.

Egy daemon aktív lehet, miközben az alagút használhatatlan, és ez a leggyakoribb téves átmenet. Az indítás befejeződhet, mielőtt a hálózat online lenne, ha az egység csak a network.target-re vár a network-online.target helyett. A hivatkozott fájlok, például tanúsítványok, kulcsok vagy egy CRL, abban a pillanatban olvashatatlanok lehetnek, mert egy csatolás vagy egy titkos útvonal még nem kész. Egyik probléma sem jelenik meg a systemctl status-ben, amíg el nem olvassa az egység naplóját.

A gazdagépen kívülről teszteljen. Egy ügyfél ugyanabban a LAN-ban olyan útvonalon is sikerrel járhat, amelyet egyetlen távoli ügyfél sem használna, és a géphez intézett SSH-munkamenet semmit sem bizonyít az alagútról. Csatlakozzon, oldjon fel egy belső nevet, érje el a privát erőforrást, majd csatlakozzon még egyszer, hogy megerősítse a visszavonási állapot és a kulcsok érvényességét.

A három feltétel, amely eldönti a javítását

Ha az alagút visszatér, de az ügyfelek semmit sem érnek el, a hiba az útvonalkezelésben vagy a NAT tartósságában van. Ha az ügyfelek még a kézfogást sem tudják befejezni, a hiba az interfészben vagy a hitelesítési anyagban van. Ha a szolgáltatás soha nem indul el, a hiba az egységfájlban vagy annak függőségeiben van. Ez a három ág különböző javításokhoz vezet, ezért az alapállapot nélküli vak újraindítás több időt vesz igénybe, mint amennyit megtakarít.

A javítást ott végezze, ahol a beállítás tulajdonban van. Tegye a továbbítást egy sysctl drop-inba, a NAT-szabályokat a rendszerindításkor betöltődő szabálykészletbe, engedélyezze az egységet ahelyett, hogy elindítaná, és tartsa a titkokat olyan útvonalon, amely az egység indulása előtt létezik. Az egységhez adott alvás elrejti a függőséget ahelyett, hogy deklarálná.

Rögzítse az eredményt a runbookban

Írja le, mi tért vissza magától, mit kellett elindítania, és mennyi ideig tartott a hiány. Foglalja bele a pontos parancsokat, amelyekkel ellenőrzött, hogy a következő ember megismételje a tesztet, ne pedig újat találjon ki. Ha bármely lépéshez kézi parancs kellett, az a parancs a konfigurációhoz tartozik, nem a runbookhoz állandó lépésként.

Ezután ütemezze a következő tesztet a gazdagép hálózati veremének következő változása utánra, nem egy naptári dátumra hat hónappal későbbre. Az a hibaállapot, amely ellen védekezik, egy ideiglenes parancs, amely állandónak tűnt, és ezek pontosan akkor jelennek meg, amikor valaki tűzfalszabályokat szerkeszt vagy egy szolgáltatást új egységbe helyez.