Buitengesloten van je VPN-server: houd een tweede weg naar binnen
Een kapotte tunnel mag je niet ook nog het vermogen ontnemen om de server te repareren. Plan, test en herzie een onafhankelijke beheerroute voordat je die nodig hebt.
Je opent de console, wijzigt één firewallregel, en de tunnel waar je verbinding mee had verdwijnt. De wijziging was juist, het herladen niet, en nu is de enige route terug naar de machine degene die je net hebt gebroken. Een tweede weg naar binnen is een ontwerpbeslissing, en die moet bestaan vóór de storing, niet tijdens.
Loop na wat je nog hebt
Begin bij het consolescherm voor je en noem de wegen die niet van de tunnel afhangen. Een webconsole van de provider met een seriële sessie of VNC is er één. Een beheerinterface op een apart netwerk is er nog één. Fysieke toegang is de derde, en dat is degene waarvan mensen op het slechtste moment ontdekken dat hij ontbreekt.
| Path | Depends on | Usually fails when |
|---|---|---|
| Provider console | Account access and the provider's own API | Credentials live in a wiki only reachable over the tunnel |
| Management subnet | A second interface and its own routing | The bad change was a global route or firewall policy |
| Second tunnel | A different listener, port and credentials | Both listeners were changed in the same edit |
| Physical or local console | Being in the building | Nobody has been in the building for a year |
Lees de derde kolom als een foutlijst en niet als een abstractie. Twee van die wegen falen meestal om dezelfde reden. De tabel is hoe je dat opmerkt voordat een storing het je uitlegt.
Onafhankelijkheid is een kwestie van afhankelijkheden
Een herstelaccount is niet onafhankelijk als het wachtwoord in een dienst staat die je via de tunnel bereikt. Een tweede VPN op dezelfde host, dezelfde poort en hetzelfde firewallbeleid is ook niet onafhankelijk, want de wijziging die de eerste brak, breekt beide.
Loop de keten af en benoem wat elke stap nodig heeft. Netwerkbereikbaarheid, naamresolutie, een authenticatiebron en de beheerdienst zelf zijn vier afzonderlijke afhankelijkheden, en een weg die er daarvan één deelt, erft die fout.
De nooit geteste weg verdient zijn eigen wantrouwen. Een console die maanden niet is geopend, kan een wachtwoordreset per e-mail vereisen, en dat postbus kan op de machine staan die je niet bereikt. Test de weg terwijl alles werkt, en je vindt dit op een rustige middag.
Gebruik de tweede weg voor één gecontroleerde wijziging
Neem vanaf de console een momentopname of kopieer de configuratie die je gaat bewerken. Wijzig één ding. Herlaad de dienst en lees het resultaat voordat je iets anders aanraakt, want twee wijzigingen tegelijk maken van een herstel een experiment.
Houd de herstelsessie open terwijl je dat doet. De hele waarde van de tweede weg is dat die overwint wat je aan het wijzigen bent, dus als je hem eerst sluit, verwijder je de enige eigenschap die hem bruikbaar maakte.
Controleer vanaf de herstelroute, niet uit je geheugen
De controle die telt is of de normale weg terugkomt, en de herstelsessie is waar je dat in volgorde bevestigt:
systemctl status openvpn-server@server --no-pager ss -lntup | grep -E ':(1194|443)\b' nft list ruleset | sed -n '1,40p' journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30
Lees eerst de dienststatus, dan de listener, dan de regels, dan het journaal. Een dienst die draait zonder listener wijst op de dienstconfiguratie, terwijl een listener zonder bereikbare regels op filtering wijst. De volgorde is belangrijk omdat elke stap de volgende vernauwt, en naar het journaal springen betekent meestal fouten lezen die het symptoom beschrijven en niet de oorzaak.
De systemctl-documentatie behandelt het status- en herstartgedrag dat hier wordt gebruikt, inclusief hoe een mislukte herlaadbeurt het vorige proces laat doorlopen. Een samenhangende revisie herstellen is beter dan steeds opnieuw verbinden vanaf een client die de server niet kan repareren. Als de terugrolvoorwaarde die je vóór de wijziging hebt gedefinieerd is vervuld, herstel dan en stop.
Houd de inventaris bij
Herzie de toegangslijst wanneer mensen of infrastructuur veranderen. Test de herstelroute terwijl alles werkt. Trek de accounts in die niemand sinds de laatste reorganisatie heeft gebruikt. Twee verouderde accounts en één verlopen certificaat zijn een kleine opruiming op dinsdag en een storing op zondag.
Leg vast wie elke weg mag gebruiken, wat die toestaat en hoe de inloggegevens worden geroteerd. Een herstelroute zonder eigenaar wordt een vergeten ingang, en dat is een ander soort fout dan buitengesloten zijn.