Test gendannelse af VPN-server efter genstart: hvad du skal kontrollere først

Genstart serveren, uden at nogen er logget ind, og opret derefter forbindelse fra et netværk, du ikke kontrollerer. Den ene test afgør, om gendannelsen er ægte, fordi en tunnel, der først virker, når nogen kører en kommando manuelt, ikke er gendannelse, men en reparation. De fleste kontroller stopper for tidligt: dæmonen vises som aktiv, grænsefladen kommer op, og siden indlæses stadig ikke. Hullet er næsten altid, om delene omkring tunnelen overlever, ikke selve tunnelkommandoen.

Fire ejere, fire forskellige tests

Før genstarten skal du navngive, hvad der skal bringe tunnelen tilbage. Den test, du kører, og den rettelse, du anvender, afhænger begge af det svar, og der er fire almindelige ejere: en systemd-enhed til VPN-dæmonen, en wg-quick-instansenhed til en WireGuard-grænseflade, en container-runtime eller en netværksmanagerprofil. Hvis du ikke kan navngive ejeren, så stop og find den, fordi en genstartstest uden en forventet opstartsvej kun fortæller dig, at noget skete.

Hver ejer opbevarer sin konfiguration et andet sted. En systemd-styret OpenVPN-server læser sin konfiguration ved opstart, så det, der står i filen ved boot, er det, der kører. En wg-quick-grænseflade udleder sine adresser, ruter og DNS fra samme fil, hvilket betyder, at en grænseflade, der startes manuelt fra en shell og aldrig aktiveres som enhed, ikke vender tilbage. En container bringer sit entrypoint tilbage, men ikke ændringer i værtens firewall, medmindre de lever uden for containeren.

Baseline først, ellers betyder resultatet intet

Registrér den fungerende tilstand, mens den virker: adresser på tunnelen, ruter til klientens undernet, NAT- eller videresendelsesregler, lytte-socketten og videresendelses-sysctl'en. ip addr show wg0, ip route, nft list ruleset eller iptables-save, ss -lunp og sysctl net.ipv4.ip_forward er nok på de fleste værter.

Notér, hvordan tjenesten er konfigureret til at starte, ikke bare at den kører. systemctl is-enabled wg-quick@wg0 og systemctl is-active wg-quick@wg0 besvarer forskellige spørgsmål, og den aktiverede tilstand er den, der betyder noget ved boot, som beskrevet i systemctl(1). For OpenVPN skal du kontrollere, hvilken skabelon værten bruger, da openvpn@server og openvpn-server@server er forskellige enheder med forskellige standardindstillinger.

Kør genstarten og læs den første fejl

Genstart med vilje i et vindue, du har valgt, med en konsol eller en out-of-band-vej åben. Hold øje med rækkefølgen af begivenheder frem for sluttilstanden: vært tilgængelig, enhed aktiveret, grænseflade til stede, ruter installeret, firewallregler til stede, lytter bundet, klient accepteret. Det første trin, der ikke sker, er fundet; alt derefter er støj.

En dæmon kan være aktiv, mens tunnelen er ubrugelig, og det er det mest almindelige falske gennemløb. Opstarten kan være færdig, før netværket er online, hvis enheden kun venter på network.target i stedet for network-online.target. Refererede filer som certifikater, nøgler eller en CRL kan være ulæselige i det øjeblik, fordi et mount eller en hemmelig sti ikke er klar endnu. Ingen af problemerne vises i systemctl status, før du læser journalen for enheden.

Test udefra værten. En klient på samme LAN kan lykkes gennem en rute, som ingen fjernklient nogensinde ville bruge, og en SSH-session til maskinen beviser intet om tunnelen. Opret forbindelse, slå et internt navn op, nå den private ressource, og opret derefter forbindelse igen for at bekræfte, at tilbagekaldelsestilstanden og nøglerne stadig gælder.

De tre betingelser, der afgør din rettelse

Hvis tunnelen vender tilbage, men klienterne ikke kan nå noget, ligger fejlen i routing eller NAT-persistens. Hvis klienterne ikke engang kan gennemføre et handshake, ligger fejlen i grænsefladen eller autentificeringsmaterialet. Hvis tjenesten aldrig starter, ligger fejlen i enhedsfilen eller dens afhængigheder. De tre grene fører til forskellige rettelser, og derfor koster en blind genstart uden baseline mere tid, end den sparer.

Foretag rettelsen der, hvor indstillingen ejes. Læg videresendelse i en sysctl drop-in, læg NAT-regler i det regelsæt, der indlæses ved boot, aktivér enheden i stedet for at starte den, og hold hemmeligheder på en sti, der findes, før enheden starter. At tilføje en sleep til enheden skjuler en afhængighed i stedet for at erklære den.

Notér resultatet i runbooken

Skriv ned, hvad der kom tilbage af sig selv, hvad du måtte starte, og hvor længe hullet varede. Medtag de præcise kommandoer, du brugte til at verificere, så den næste person gentager testen i stedet for at opfinde en. Hvis et trin krævede en manuel kommando, hører den kommando til i konfigurationen, ikke i runbooken som et permanent trin.

Planlæg derefter den næste test til efter den næste ændring af værtens netværksstak, ikke til en kalenderdato om seks måneder. Den fejltilstand, du værner imod, er en midlertidig kommando, der føltes permanent, og de dukker netop op, når nogen redigerer firewallregler eller flytter en tjeneste til en ny enhed.