Test gjenoppretting av VPN-tenaren etter omstart: kva du bør sjekke først
Start på nytt utan at nokon er innlogga, og kople deretter til utanfrå. Sjekk eininga, grensesnittet, rutene og brannmurreglane som skal kome tilbake av seg sjølv.
Start tenaren på nytt utan at nokon er innlogga, og kople deretter til frå eit nettverk du ikkje kontrollerer. Den eine testen avgjer om gjenopprettinga er ekte, fordi ein tunnel som først verkar etter at nokon køyrer ein kommando manuelt, ikkje er gjenoppretting, men ein reparasjon. Dei fleste kontrollane stoppar for tidleg: tenesta viser seg som aktiv, grensesnittet kjem opp, og sida lastar framleis ikkje. Gapet er nesten alltid om delane rundt tunnelen overlever, ikkje sjølve tunnelkommandoen.
Fire eigarar, fire ulike testar
Før omstarten må du namngje kva som skal bringe tunnelen tilbake. Testen du køyrer, og rettinga du brukar, er begge avhengige av det svaret, og det finst fire vanlege eigarar: ei systemd-eining for VPN-tenesta, ei wg-quick-førekomstseining for eit WireGuard-grensesnitt, ein container-runtime eller ein nettverkshandterarprofil. Viss du ikkje kan namngje eigaren, stopp og finn han, fordi ein omstartstest utan ein forventa oppstartsveg berre fortel deg at noko skjedde.
Kvar eigar oppbevarer konfigurasjonen sin ein annan stad. Ein systemd-styrt OpenVPN-tenar les konfigurasjonen ved oppstart, så det som står i fila ved boot, er det som køyrer. Eit wg-quick-grensesnitt leier ut adressene, rutene og DNS frå same fil, noko som betyr at eit grensesnitt som vert sett opp manuelt frå eit skal og aldri aktiverast som eining, ikkje kjem tilbake. Ein container bringar tilbake inngangspunktet sitt, men ikkje brannmur-endringar på verten med mindre desse lever utanfor containeren.
Basislinje først, elles tyder resultatet ingenting
Registrer den fungerande tilstanden medan han verkar: adresser på tunnelen, ruter for klientens undernett, NAT- eller vidaresendingsreglar, lyttesocketen og vidaresendings-sysctl. ip addr show wg0, ip route, nft list ruleset eller iptables-save, ss -lunp og sysctl net.ipv4.ip_forward er nok på dei fleste vertar.
Noter korleis tenesta er konfigurert til å starte, ikkje berre at ho køyrer. systemctl is-enabled wg-quick@wg0 og systemctl is-active wg-quick@wg0 svarar på ulike spørsmål, og den aktiverte tilstanden er den som tyder noko ved boot, som skildra i systemctl(1). For OpenVPN, sjekk kva mal verten brukar, sidan openvpn@server og openvpn-server@server er ulike einingar med ulike standardverdiar.
Køyr omstarten og les den første feilen
Start på nytt med vilje, i eit vindauge du har valt, med ein konsoll eller ein out-of-band-veg open. Følg rekkjefylgja av hendingar i staden for sluttilstanden: verten er tilgjengeleg, eininga aktivert, grensesnittet til stades, rutene installerte, brannmurreglane til stades, lyttaren bunden, klienten godteken. Det første trinnet som ikkje skjer, er funnet; alt etter det er støy.
Ei tenesta kan vere aktiv medan tunnelen er ubrukeleg, og det er den vanlegaste falske gjennomkøyringa. Oppstarten kan fullførast før nettverket er på nett viss eininga berre ventar på network.target i staden for network-online.target. Refererte filer som sertifikat, nøklar eller ein CRL kan vere uleselege i det augneblunken fordi ei montering eller ein hemmeleg stig ikkje er klar enno. Ingen av problema viser seg i systemctl status før du les journalen for eininga.
Test utanfrå verten. Ein klient på same LAN kan lukkast gjennom ei rute som ingen fjernklient nokon gong ville bruke, og ei SSH-økt til maskina beviser ingenting om tunnelen. Kople til, slå opp eit internt namn, nå den private ressursen, og kople deretter til ein gong til for å stadfeste at tilbakekallingstilstanden og nøklane framleis gjeld.
Dei tre vilkåra som avgjer rettinga di
Viss tunnelen kjem tilbake, men klientane ikkje når noko, ligg feilen i ruting eller NAT-persistens. Viss klientane ikkje ein gong kan fullføre eit handtrykk, ligg feilen i grensesnittet eller autentiseringsmaterialet. Viss tenesta aldri startar, ligg feilen i einingafila eller avhengnadene hennar. Dei tre greinene fører til ulike rettingar, og difor kostar ein blind omstart utan basislinje meir tid enn han sparar.
Gjer rettinga der innstillinga er eigd. Legg vidaresending i ein sysctl drop-in, legg NAT-reglane i regelsettet som vert lasta ved boot, aktiver eininga i staden for å starte ho, og hald hemmelegheiter på ein stig som finst før eininga startar. Å leggje til ein pause i eininga løyner ein avhengnad i staden for å erklære han.
Noter resultatet i runbooken
Skriv ned kva som kom tilbake av seg sjølv, kva du måtte starte, og kor lenge gapet varte. Ta med dei nøyaktige kommandoane du brukte for å verifisere, slik at neste person gjer testen om att i staden for å finne opp ein ny. Viss eit trinn trong ein manuell kommando, høyrer den kommandoen heime i konfigurasjonen, ikkje i runbooken som eit permanent trinn.
Deretter planlegg du neste test til etter neste endring i nettverksstakken til verten, ikkje til ein kalenderdato om seks månader. Feilmodusen du vernar mot, er ein mellombels kommando som kjendest permanent, og dei dukkar opp nettopp når nokon redigerer brannmurreglar eller flyttar ei tenesta til ei ny eining.