Testa återställning av VPN-servern efter omstart: vad du bör kontrollera först

Starta om servern utan att någon är inloggad och anslut sedan från ett nätverk du inte kontrollerar. Det enda testet avgör om återställningen är verklig, eftersom en tunnel som bara fungerar efter att någon kört ett kommando manuellt inte är återställning utan en reparation. De flesta kontroller stannar för tidigt: tjänsten visas som aktiv, gränssnittet kommer upp och sidan laddas ändå inte. Gapet ligger nästan alltid i om delarna runt tunneln överlever, inte i själva tunnelkommandot.

Fyra ägare, fyra olika test

Före omstarten, namnge vad som ska få tunneln tillbaka. Testet du kör och rättelsen du använder beror båda på det svaret, och det finns fyra vanliga ägare: en systemd-enhet för VPN-tjänsten, en wg-quick-instansenhet för ett WireGuard-gränssnitt, en container-runtime eller en nätverkshanterarprofil. Om du inte kan namnge ägaren, stanna och hitta den, eftersom ett omstartstest utan en förväntad uppstartsväg bara säger att något hände.

Varje ägare förvarar sin konfiguration på olika ställen. En systemd-styrd OpenVPN-server läser konfigurationen vid start, så det som står i filen vid boot är det som körs. Ett wg-quick-gränssnitt hämtar adresser, rutter och DNS från samma fil, vilket innebär att ett gränssnitt som lyfts manuellt från ett skal och aldrig aktiverats som enhet inte kommer tillbaka. En container tar tillbaka sin entrypoint men inte brandväggsändringar på värden, om dessa inte lever utanför containern.

Baslinje först, annars betyder resultatet ingenting

Registrera det fungerande tillståndet medan det fungerar: adresser på tunneln, rutter för klientens subnät, NAT- eller vidarebefordringsregler, lyssnande socket och vidarebefordrings-sysctl. ip addr show wg0, ip route, nft list ruleset eller iptables-save, ss -lunp och sysctl net.ipv4.ip_forward räcker på de flesta värdar.

Notera hur tjänsten är konfigurerad att starta, inte bara att den körs. systemctl is-enabled wg-quick@wg0 och systemctl is-active wg-quick@wg0 svarar på olika frågor, och det är det aktiverade tillståndet som spelar roll vid boot, som beskrivs i systemctl(1). För OpenVPN, kontrollera vilken mall värden använder, eftersom openvpn@server och openvpn-server@server är olika enheter med olika standardvärden.

Kör omstarten och läs det första felet

Starta om med avsikt, i ett fönster du valt, med en konsol eller en out-of-band-väg öppen. Följ händelseordningen i stället för sluttillståndet: värden nåbar, enheten aktiverad, gränssnittet närvarande, rutterna installerade, brandväggsreglerna närvarande, lyssnaren bunden, klienten accepterad. Det första steget som inte sker är fyndet; allt efter det är brus.

En tjänst kan vara aktiv medan tunneln är oanvändbar, och det är den vanligaste falska genomgången. Starten kan slutföras innan nätverket är online om enheten bara väntar på network.target i stället för network-online.target. Refererade filer som certifikat, nycklar eller en CRL kan vara oläsbara i det ögonblicket eftersom en montering eller en hemlig sökväg inte är klar än. Inget av problemen syns i systemctl status förrän du läser enhetens journal.

Testa utifrån värden. En klient i samma LAN kan lyckas via en rutt som ingen fjärrklient någonsin skulle använda, och en SSH-session till maskinen bevisar ingenting om tunneln. Anslut, slå upp ett internt namn, nå den privata resursen och anslut sedan en gång till för att bekräfta att återkallningsstatus och nycklar fortfarande gäller.

De tre villkoren som avgör din rättelse

Om tunneln kommer tillbaka men klienterna inte når något ligger felet i routning eller NAT-beständighet. Om klienterna inte ens kan slutföra ett handskak ligger felet i gränssnittet eller autentiseringsmaterialet. Om tjänsten aldrig startar ligger felet i enhetsfilen eller dess beroenden. De tre grenarna leder till olika rättelser, och därför kostar en blind omstart utan baslinje mer tid än den sparar.

Gör rättelsen där inställningen ägs. Lägg vidarebefordran i en sysctl drop-in, lägg NAT-reglerna i den regeluppsättning som laddas vid boot, aktivera enheten i stället för att starta den och håll hemligheter på en sökväg som finns innan enheten startar. Att lägga till en sömn i enheten döljer ett beroende i stället för att deklarera det.

Notera resultatet i runbooken

Skriv ner vad som kom tillbaka av sig självt, vad du var tvungen att starta och hur länge gapet varade. Ta med de exakta kommandon du använde för att verifiera, så att nästa person upprepar testet i stället för att hitta på ett nytt. Om något steg krävde ett manuellt kommando hör det kommandot hemma i konfigurationen, inte i runbooken som ett permanent steg.

Planera sedan nästa test till efter nästa ändring i värdens nätverksstack, inte till ett kalenderdatum om sex månader. Det felfall du skyddar dig mot är ett tillfälligt kommando som kändes permanent, och de dyker upp precis när någon redigerar brandväggsregler eller flyttar en tjänst till en ny enhet.