VPN-app gecrasht: staat je killswitch nog aan?

Begin waar een gebruiker begint: het clientvenster is weg, het pictogram in het systeemvak is verdwenen, en de browser laadt of hij laadt niet. Die waarneming alleen kan je niet vertellen of de blokkade overleefde. Het antwoord hangt ervan af welke component de regels vasthoudt, of die component met het venster stierf, en of het platform de handhaving buiten de toepassing houdt. Loop van het venster naar het proces, dan naar de firewall, dan naar het werkelijke pad.

Herstart niet meteen; een herstart vernietigt meestal het bewijs.

Begin bij wat nog draait

Open de proceslijst voordat je iets aanraakt. Een desktopclient splitst zich meestal in een gebruikersinterfaceproces en een dienst of daemon, en een crash in de eerste stopt niet noodzakelijk de tweede. Op Windows staat de dienst misschien nog in de lijst, op Linux is de unit misschien nog actief, en op Android is de tunnel eigendom van het systeem zodra toestemming is gegeven. Lees die drie feiten in die volgorde.

Als de daemon leeft, leeft de tunnel waarschijnlijk ook, en het ontbrekende venster is alleen cosmetisch.

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

Lees de blokkade bij de afdwinger, niet in de app

Als de client zijn killswitch implementeert door firewallregels in te voegen, behoren die regels toe aan het besturingssysteem en overleven ze het proces dat ze heeft aangemaakt. Een crash laat je dan geblokkeerd achter zonder enige interface om het uit te zetten, wat op een kapot netwerk lijkt in plaats van op een bescherming. Als de blokkade daarentegen in het eigen pakketpad van de client zit, verwijdert het doden van het proces de blokkade op hetzelfde moment.

Android behandelt dit weer anders: always-on VPN met lockdown is een platforminstelling, dus de blokkade blijft onafhankelijk van het app-proces bestaan, en het systeem kan de dienst herstarten. Raadpleeg de platformdocumentatie voor het exacte gedrag in plaats van aan te nemen dat het overeenkomt met een desktopclient.

Onderscheid een schone afsluiting van een crash

Een normale Quit voert meestal het afsluitpad van de client uit, dat regels verwijdert en de tunnel met opzet sluit. Een crash slaat dat pad over en laat staan wat de afdwinger al heeft geïnstalleerd. Het verschil is te zien in de tijdstempels van de regels ten opzichte van het proceseinde, en in of er nog een oude tunnelinterface zonder eigenaar bestaat.

Dat onderscheid bepaalt je herstel: een schone afsluiting kan een nieuwe verbinding nodig hebben, terwijl een crash kan vereisen dat de overgebleven regels via de ondersteunde reparatieactie van de client worden verwijderd.

Herstel zonder andere controles te breken

Herstart de client via de gedocumenteerde werkwijze en controleer dan beide helften van de eis: de tunnel draagt verkeer, en de blokkade geldt nog wanneer dat moet. De hele firewall leegmaken om de verbinding terug te krijgen verwijdert ook ongerelateerde controles, en die ruil is zelden de moeite waard.

Verzamel bij een herhaalde crash de clientversie, de platformbuild en de beperkte logs die de leverancier vraagt. Een clientprofiel, een privésleutel of een volledig verbindingslog voor een ander account is niet nodig voor een crashrapport, en het toevoegen ervan maakt van een supportcase een gegevensverwerkingsprobleem.

Eén crash is geen bewijs van een lek. Bewijs is een waargenomen pakket dat vertrekt via een pad dat het beleid had moeten tegenhouden, vastgelegd op het moment dat de client uit stond. Test dat bewust, met een onschadelijke bestemming, en schrijf op welke handhavingslaag standhield.