Test gjenoppretting av VPN-server etter omstart: hva du bør sjekke først
Start på nytt uten at noen er logget inn, og koble deretter til utenfra. Sjekk enheten, grensesnittet, rutene og brannmurreglene som skal komme tilbake av seg selv.
Start serveren på nytt uten at noen er logget inn, og koble deretter til fra et nettverk du ikke kontrollerer. Den ene testen avgjør om gjenopprettingen er ekte, fordi en tunnel som først virker etter at noen kjører en kommando manuelt, ikke er gjenoppretting, men en reparasjon. De fleste kontroller stopper for tidlig: tjenesten vises som aktiv, grensesnittet kommer opp, og siden lastes fortsatt ikke. Gapet er nesten alltid om delene rundt tunnelen overlever, ikke selve tunnelkommandoen.
Fire eiere, fire forskjellige tester
Før omstarten må du navngi hva som skal bringe tunnelen tilbake. Testen du kjører, og rettelsen du bruker, avhenger begge av det svaret, og det finnes fire vanlige eiere: en systemd-enhet for VPN-tjenesten, en wg-quick-forekomstsenhet for et WireGuard-grensesnitt, en container-runtime eller en nettverksbehandlerprofil. Hvis du ikke kan navngi eieren, stopp og finn den, fordi en omstartstest uten en forventet oppstartsvei bare forteller deg at noe skjedde.
Hver eier oppbevarer konfigurasjonen sin et annet sted. En systemd-styrt OpenVPN-server leser konfigurasjonen ved oppstart, så det som står i filen ved boot, er det som kjører. Et wg-quick-grensesnitt utleder adressene, rutene og DNS fra samme fil, noe som betyr at et grensesnitt som settes opp manuelt fra et skall og aldri aktiveres som enhet, ikke kommer tilbake. En container bringer tilbake inngangspunktet sitt, men ikke brannmur-endringer på verten med mindre disse lever utenfor containeren.
Basislinje først, ellers betyr resultatet ingenting
Registrer den fungerende tilstanden mens den virker: adresser på tunnelen, ruter for klientens undernett, NAT- eller videresendingsregler, lyttesocketen og videresendings-sysctl. 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 verter.
Noter hvordan tjenesten er konfigurert til å starte, ikke bare at den kjører. systemctl is-enabled wg-quick@wg0 og systemctl is-active wg-quick@wg0 svarer på forskjellige spørsmål, og den aktiverte tilstanden er den som betyr noe ved boot, som beskrevet i systemctl(1). For OpenVPN, sjekk hvilken mal verten bruker, siden openvpn@server og openvpn-server@server er forskjellige enheter med forskjellige standardverdier.
Kjør omstarten og les den første feilen
Start på nytt med vilje, i et vindu du har valgt, med en konsoll eller en out-of-band-vei åpen. Følg rekkefølgen av hendelser i stedet for sluttilstanden: verten er tilgjengelig, enheten aktivert, grensesnittet til stede, rutene installert, brannmurreglene til stede, lytteren bundet, klienten godtatt. Det første trinnet som ikke skjer, er funnet; alt etter det er støy.
En tjeneste kan være aktiv mens tunnelen er ubrukelig, og det er den vanligste falske gjennomkjøringen. Oppstarten kan fullføres før nettverket er på nett hvis enheten bare venter på network.target i stedet for network-online.target. Refererte filer som sertifikater, nøkler eller en CRL kan være uleselige i det øyeblikket fordi en montering eller en hemmelig sti ikke er klar ennå. Ingen av problemene vises i systemctl status før du leser journalen for enheten.
Test utenfra verten. En klient på samme LAN kan lykkes gjennom en rute som ingen fjernklient noen gang ville bruke, og en SSH-økt til maskinen beviser ingenting om tunnelen. Koble til, slå opp et internt navn, nå den private ressursen, og koble deretter til én gang til for å bekrefte at tilbakekallingstilstanden og nøklene fortsatt gjelder.
De tre betingelsene som avgjør rettelsen din
Hvis tunnelen kommer tilbake, men klientene ikke når noe, ligger feilen i ruting eller NAT-persistens. Hvis klientene ikke engang kan fullføre et håndtrykk, ligger feilen i grensesnittet eller autentiseringsmaterialet. Hvis tjenesten aldri starter, ligger feilen i enhetsfilen eller dens avhengigheter. De tre grenene fører til forskjellige rettelser, og derfor koster en blind omstart uten basislinje mer tid enn den sparer.
Gjør rettelsen der innstillingen eies. Legg videresending i en sysctl drop-in, legg NAT-reglene i regelsettet som lastes ved boot, aktiver enheten i stedet for å starte den, og hold hemmeligheter på en sti som finnes før enheten starter. Å legge til en pause i enheten skjuler en avhengighet i stedet for å erklære den.
Noter resultatet i runbooken
Skriv ned hva som kom tilbake av seg selv, hva du måtte starte, og hvor lenge gapet varte. Ta med de nøyaktige kommandoene du brukte for å verifisere, slik at neste person gjentar testen i stedet for å finne opp en ny. Hvis et trinn trengte en manuell kommando, hører den kommandoen hjemme i konfigurasjonen, ikke i runbooken som et permanent trinn.
Deretter planlegger du neste test til etter neste endring i vertens nettverksstakk, ikke til en kalenderdato om seks måneder. Feilmodusen du verner mot, er en midlertidig kommando som føltes permanent, og de dukker opp nettopp når noen redigerer brannmurregler eller flytter en tjeneste til en ny enhet.