Start der brukaren startar: klientvindauget er borte, ikonet i systemkurva er forsvunne, og nettlesaren lastar eller lastar ikkje. Den observasjonen åleine kan ikkje fortelje om blokkeringa overlevde. Svaret avheng av kva komponent som held reglane, om den komponenten døydde saman med vindauget, og om plattforma held handhevinga utanfor programmet. Gå utover frå vindauget til prosessen, deretter til brannmuren, deretter til den faktiske vegen.

Ikkje start på nytt først; ein omstart øydelegg vanlegvis prova.

Start med det som framleis køyrer

Opne prosesslista før du rører noko. Ein skrivebordsklient deler seg vanlegvis i ein brukargrensesnittprosess og ein teneste eller daemon, og eit krasj i den første stoppar ikkje nødvendigvis den andre. På Windows kan tenesta framleis stå i lista, på Linux kan eininga framleis vere aktiv, og på Android eig systemet tunnelen når samtykke først er gjeve. Les dei tre fakta i den rekkjefølgja.

Er daemonen i live, er tunnelen truleg også i live, og det manglande vindauget er berre kosmetikk.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Les blokkeringa hos handhevaren, ikkje i appen

Viss klienten implementerer naudstoppet sitt ved å setje inn brannmurreglar, høyrer dei reglane til operativsystemet og overlever prosessen som oppretta dei. Eit krasj lèt deg då stå blokkert utan noko grensesnitt for å slå det av, og det ser meir ut som eit øydelagt nettverk enn som ei vern. Viss blokkeringa i staden bur inne i klienten sin eigen pakkeveg, fjernar drapet på prosessen blokkeringa i same augneblink.

Android handterer dette igjen annleis: always-on VPN med lockdown er ei plattforminnstilling, så blokkeringa varer uavhengig av app-prosessen, og systemet kan starte tenesta på nytt. Slå opp i plattformdokumentasjonen for den nøyaktige åtferda i staden for å anta at ho svarar til ein skrivebordsklient.

Skil ein rein avslutning frå eit krasj

Ein vanleg Quit køyrer vanlegvis avslutningsvegen til klienten, som fjernar reglar og lukkar tunnelen med vilje. Eit krasj hoppar over den vegen og lèt alt stå som handhevaren alt har installert. Skilnaden synest i tidsstempla til reglane relativt til avslutninga av prosessen, og i om det framleis finst eit foreldrelaust tunellgrensesnitt.

Den skilnaden avgjer gjenopprettinga di: ein rein avslutning kan trenge ei ny tilkopling, medan eit krasj kan krevje at dei attverande reglane vert fjerna via den støtta reparasjonshandlinga til klienten.

Gjenopprett utan å bryte andre kontrollar

Start klienten på nytt via den dokumenterte arbeidsflyten hans, og kontroller deretter begge halvdelane av kravet: tunnelen ber trafikk, og blokkeringa gjeld framleis når ho skal. Å skylje heile brannmuren for å få att tilkoplinga fjernar også urelaterte kontrollar, og den byttehandelen er sjeldan verdt det.

Ved eit gjenteke krasj, samle inn klientversjonen, plattformbygget og dei avgrensa loggane leverandøren ber om. Ein klientprofil, ein privat nøkkel eller ein full tilkoplingslogg for ein annan konto er ikkje nødvendig i ein krasjrapport, og å ta det med gjer ei støttesak til eit datahandteringsproblem.

Eitt krasj er ikkje prov på ein lekkasje. Prov er ein observert pakke som forlèt via ein veg som policyen skulle ha hindra, fanga i augneblinken klienten var nede. Test det med vilje, med ein ufarleg destinasjon, og skriv ned kva handhevingslag som heldt.

Relaterte artiklar