VPN-appen kraschade: är nödstoppet fortfarande på?

Börja där användaren börjar: klientfönstret är borta, ikonen i aktivitetsfältet är försvunnen, och webbläsaren laddar antingen eller inte. Den observationen ensam kan inte säga om blockeringen överlevde. Svaret beror på vilken komponent som håller reglerna, om den komponenten dog med fönstret, och om plattformen håller upprätthållandet utanför programmet. Gå utåt från fönstret till processen, sedan till brandväggen, sedan till den faktiska vägen.

Starta inte om först; en omstart förstör oftast bevisen.

Börja med det som fortfarande körs

Öppna processlistan innan du rör något. En skrivbordsklient delas oftast upp i en användargränssnittsprocess och en tjänst eller daemon, och en krasch i den första stoppar inte nödvändigtvis den andra. På Windows kan tjänsten fortfarande stå i listan, på Linux kan enheten fortfarande vara aktiv, och på Android ägs tunneln av systemet när samtycke väl getts. Läs de tre fakta i den ordningen.

Är daemonen vid liv är tunneln förmodligen också vid liv, och det saknade fönstret är bara kosmetik.

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

Läs blockeringen hos upprätthållaren, inte i appen

Om klienten implementerar sitt nödstopp genom att infoga brandväggsregler, tillhör de reglerna operativsystemet och överlever processen som skapade dem. En krasch lämnar dig då blockerad utan något gränssnitt för att stänga av det, vilket ser ut som ett trasigt nätverk snarare än ett skydd. Om blockeringen i stället bor inne i klientens egen paketväg tar det bort blockeringen i samma ögonblick som processen dödas.

Android hanterar det här återigen annorlunda: always-on VPN med lockdown är en plattformsinställning, så blockeringen består oberoende av appprocessen, och systemet kan starta om tjänsten. Slå upp det exakta beteendet i plattformens dokumentation i stället för att anta att det motsvarar en skrivbordsklient.

Skilj en ren avslutning från en krasch

Ett vanligt Quit kör oftast klientens avstängningsväg, som tar bort regler och stänger tunneln med avsikt. En krasch hoppar över den vägen och lämnar allt som upprätthållaren redan har installerat. Skillnaden syns i reglernas tidsstämplar i förhållande till processens avslut, och i om det fortfarande finns ett föräldralöst gammalt tunnelgränssnitt.

Den skillnaden avgör din återställning: en ren avslutning kan behöva en ny anslutning, medan en krasch kan kräva att de kvarvarande reglerna tas bort via klientens stödda reparationsåtgärd.

Återställ utan att bryta andra kontroller

Starta om klienten via dess dokumenterade arbetsflöde och kontrollera sedan båda halvorna av kravet: tunneln bär trafik, och blockeringen gäller fortfarande när den ska. Att spola hela brandväggen för att få tillbaka anslutningen tar också bort orelaterade kontroller, och den byteshandeln är sällan värd det.

Vid en upprepad krasch, samla in klientversionen, plattformens build och de begränsade loggar som leverantören begär. En klientprofil, en privat nyckel eller en fullständig anslutningslogg för ett annat konto behövs inte för en kraschrapport, och att ta med dem gör ett supportärende till ett datahanteringsproblem.

En krasch är inte bevis på en läcka. Bevis är ett observerat paket som lämnar via en väg som policyn skulle ha förhindrat, fångat i det ögonblick klienten var nere. Testa det med avsikt, med en ofarlig destination, och skriv ned vilket upprätthållandelager som höll.