Herstel van de VPN-server na een herstart testen: wat je eerst moet controleren

Herstart de server terwijl niemand is ingelogd en maak daarna verbinding vanuit een netwerk dat je niet beheert. Die ene test beantwoordt of het herstel echt is, want een tunnel die pas werkt nadat iemand met de hand een commando uitvoert, is geen herstel maar een reparatie. De meeste controles stoppen te vroeg: de dienst toont actief, de interface komt op, en de pagina laadt toch niet. De kloof zit bijna altijd in de persistentie van de onderdelen rond de tunnel, niet in het tunnelcommando zelf.

Vier eigenaren, vier verschillende tests

Benoem vóór de herstart wat de tunnel terug moet brengen. De test die je uitvoert en de oplossing die je toepast hangen beide van dat antwoord af, en er zijn vier gangbare eigenaren: een systemd-unit voor de VPN-dienst, een wg-quick-instantie-unit voor een WireGuard-interface, een container-runtime of een netwerkbeheerderprofiel. Als je de eigenaar niet kunt benoemen, stop en zoek hem, want een herstarttest zonder verwacht opstartpad vertelt je alleen dat er iets is gebeurd.

Elke eigenaar bewaart zijn configuratie ergens anders. Een door systemd beheerde OpenVPN-server leest zijn configuratie bij het starten, dus wat bij de boot in het bestand staat, is wat er draait. Een wg-quick-interface leidt adressen, routes en DNS af uit hetzelfde bestand, wat betekent dat een interface die met de hand uit een shell omhoog is gebracht en nooit als unit is ingeschakeld, niet terugkomt. Een container brengt zijn entrypoint terug, maar geen firewallwijzigingen op de host, tenzij die buiten de container leven.

Eerst een basislijn, anders betekent het resultaat niets

Leg de werkende toestand vast terwijl die werkt: adressen op de tunnel, routes voor het clientsubnet, NAT- of doorstuurregels, de luisterende socket en de doorstuur-sysctl. ip addr show wg0, ip route, nft list ruleset of iptables-save, ss -lunp en sysctl net.ipv4.ip_forward zijn op de meeste hosts genoeg.

Noteer hoe de dienst is geconfigureerd om te starten, niet alleen dat hij draait. systemctl is-enabled wg-quick@wg0 en systemctl is-active wg-quick@wg0 beantwoorden verschillende vragen, en de ingeschakelde toestand is degene die bij de boot telt, zoals beschreven in systemctl(1). Controleer voor OpenVPN welke sjabloon de host gebruikt, want openvpn@server en openvpn-server@server zijn verschillende units met verschillende standaardwaarden.

Voer de herstart uit en lees de eerste fout

Herstart bewust, in een venster dat je zelf hebt gekozen, met een console of een out-of-band-pad open. Let op de volgorde van gebeurtenissen in plaats van de eindtoestand: host bereikbaar, unit geactiveerd, interface aanwezig, routes geïnstalleerd, firewallregels aanwezig, luisteraar gebonden, client geaccepteerd. De eerste stap die niet gebeurt, is de bevinding; alles daarna is ruis.

Een dienst kan actief zijn terwijl de tunnel onbruikbaar is, en dat is de meest voorkomende valse doorkomst. Het opstarten kan klaar zijn voordat het netwerk online is als de unit alleen op network.target wacht in plaats van network-online.target. Bestanden waarnaar verwezen wordt, zoals certificaten, sleutels of een CRL, kunnen op dat moment onleesbaar zijn omdat een mount of een geheim pad nog niet klaar is. Geen van beide problemen verschijnt in systemctl status voordat je het journaal van de unit leest.

Test van buiten de host. Een client op dezelfde LAN kan slagen via een route die geen enkele externe client ooit zou gebruiken, en een SSH-sessie naar de machine bewijst niets over de tunnel. Maak verbinding, los een interne naam op, bereik de privé-resource en maak daarna nog één keer verbinding om te bevestigen dat de intrekkingsstatus en de sleutels nog gelden.

De drie voorwaarden die je oplossing bepalen

Als de tunnel terugkomt maar clients niets bereiken, zit de fout in routering of NAT-persistentie. Als clients niet eens een handshake kunnen afronden, zit de fout in de interface of het authenticatiemateriaal. Als de dienst nooit start, zit de fout in het unitbestand of zijn afhankelijkheden. Die drie takken leiden tot verschillende oplossingen, en daarom kost een blinde herstart zonder basislijn meer tijd dan hij bespaart.

Doe de oplossing waar de instelling thuishoort. Zet doorsturen in een sysctl drop-in, zet NAT-regels in de regelset die bij de boot wordt geladen, schakel de unit in in plaats van hem te starten, en houd geheimen op een pad dat bestaat voordat de unit start. Een slaap aan de unit toevoegen verbergt een afhankelijkheid in plaats van die te verklaren.

Noteer het resultaat in de runbook

Schrijf op wat vanzelf terugkwam, wat je moest starten en hoe lang de kloof duurde. Neem de exacte commando's op die je gebruikte om te verifiëren, zodat de volgende persoon de test herhaalt in plaats van er een te bedenken. Als een stap een handmatig commando nodig had, hoort dat commando in de configuratie, niet in de runbook als permanente stap.

Plan daarna de volgende test voor na de volgende wijziging aan de netwerkstack van de host, niet voor een kalenderdatum over zes maanden. De faalmodus waartegen je je beschermt, is een tijdelijk commando dat permanent voelde, en die verschijnen precies wanneer iemand firewallregels bewerkt of een dienst naar een nieuwe unit verplaatst.