Twee VPN-apps tegelijk: welke killswitch geldt er echt?
Een tweede VPN-client erft nooit de killswitch van de eerste. Drie voorwaarden bepalen welk beleid geldt, en hoe u het uwe controleert.
Twee VPN-clients kunnen naast elkaar draaien, maar hun killswitches smelten niet samen tot één beleid. Elke client installeert regels voor zijn eigen tunnel, en geen van beide weet dat de andere bestaat. Ik liep hier tegenaan met een werkclient die als eerste verbonden was: de tweede app kon zijn handshake niet afmaken, bleef tien minuten op „Connecting“ staan en de eerste tunnel vervoerde alles geruisloos. Of de tweede app beschermd wordt, hangt af van drie voorwaarden, niet van de vraag of beide pictogrammen Verbonden zeggen.
Waar een killswitch echt op is afgebakend
Niets in het besturingssysteem heeft één killswitch-vlag. Een client die er een adverteert, installeert een regelset: alles laten vallen wat niet via mijn tunnel naar buiten gaat, en vaak fail closed als de tunnel wegvalt. Op Linux is dat meestal een nftables- of iptables-keten, op Windows een reeks Windows Filtering Platform-filters, op Android en iOS de eigen routering van de tunneldienst plus de systeeminstelling die verbindingen zonder VPN blokkeert. De Android-VPN-gids beschrijft dat dienstmodel als u het platformperspectief wilt.
De reikwijdte is het deel dat ertoe doet. Een regel als „alleen pakketten op uitvoerinterface wg0 toestaan“ trekt zich er niets van aan of er een tweede tunnel bestaat. Brengt een andere client wg1 op, dan behandelen de regels van de eerste client die pakketten als gewoon verkeer: meestal weggegooid, soms toegestaan. Hoe dan ook beslist de eerste client, en die heeft geen idee dat een tweede app staat te wachten.
Drie voorwaarden die bepalen wie gedekt is
U hoeft niet elke combinatie af te lopen. Drie vragen beslechten het in een paar minuten.
- Staat het platform überhaupt een tweede tunnel toe? De meeste Android-telefoons en iPhones accepteren maar één actieve VPN-dienst per gebruikersprofiel, dus de tweede app heeft nooit een tunnel en dwingt nooit iets af. U krijgt één beleid, van de app die de plek won.
- Welk proces bezit de standaardroute? Windows, macOS en Linux dragen met plezier twee tunnels. De standaardroute is van de client die hem het laatst of met de betere metriek instelde, en de andere client is verbonden maar werkloos. Op Linux gebruikt de standaardroutemodus van wg-quick policy routing met een eigen tabel en een fwmark-regel, zodat een tweede wg-quick-tunnel een concurrerende regel toevoegt in plaats van de eerste te vervangen.
- Kan de tweede client zijn eigen server bereiken? Is de eerste killswitch default-deny, dan is het buitenste endpoint van de tweede app gewoon nog een weggegooid doel. Hij probeert het stil opnieuw en meldt nooit een fout.
De korte versie, voor supportforums:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Twee van die rijen zien er vanaf het systeemvakpictogram identiek uit, en daarom is dat pictogram hier het slechtste bewijs dat er is.
Wat het eerst faalt, en hoe dat eruitziet
Een client die op „Connecting“ blijft hangen terwijl de andere gezond is, betekent bijna altijd endpoint-uithongering: de actieve killswitch gooit de handshake van de tweede client naar zijn eigen server weg. Bevestig dat goedkoop door de blokkeerregels van de eerste client één poging lang te pauzeren. Verbindt de tweede meteen, dan is de vraag beantwoord.
DNS is de tweede storing. Clients stellen de resolverconfiguratie in voor hun eigen interface, en sommige overschrijven de globale resolverlijst gewoon. Met beide tunnels actief kunnen query’s via de ene kant naar buiten gaan terwijl de resolver bij de andere hoort. Verbreek de verbinding met een van beide apps en de overlevende houdt een onbereikbare nameserver: pagina’s blijven een minuut hangen en lossen daarna weer op, terwijl de VPN nog steeds verbonden toont.
De derde is route-flapping. Herverbindingen herordenen de standaardroute, en een aan een interface gebonden killswitch volgt die niet. Verkeer dat een moment geleden nog in de tunnel zat, valt nu onder een dropregel, wat aan de gebruikerskant leest als een VPN die willekeurig stopt met werken.
Controleren welk beleid echt van kracht is
Doe dit met onschuldig verkeer, niet met iets dat u zou missen.
Vraag op Linux aan de kernel wie wint en waaraan de firewall zich bindt. ip -4 route show default noemt de tunnel die de uitgang bezit. ip rule show laat zien of policy routing in het spel is. sudo nft list ruleset | grep -n oifname laat zien of drops gebonden zijn aan een interfacenaam, een mark of de hele uitvoerketen.
Op Windows leeft hetzelfde verhaal in de routemetriek en de filterlijst: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric en Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Op macOS netstat -rn -f inet | head -5 en scutil --dns | head -20.
Doe dan de stap die mensen overslaan: stop de tunnel met opzet en bevestig dat het verkeer waarvan u verwacht dat het faalt, echt faalt. Een verbonden pictogram is een UI-status, geen handhaving.
Wanneer twee clients het verkeerde ontwerp zijn
Is de enige eis achter de tweede app meer bescherming, verwijder hem dan. Twee op elkaar inwerkende blokkeerbeleiden zijn minder voorspelbaar dan één, en elke herverbinding is een kans om in een toestand te belanden die geen enkele leverancier test.
Hebt u echt ketening nodig, bijvoorbeeld een bedrijfsgateway via een commerciële hop, kies dan een ontwerp met één handhavingspunt. Dat betekent normaal een router of één client die de keten ondersteunt, niet twee desktopapps die om dezelfde standaardroute vechten. Op een beheerd apparaat houdt u de toegestane client en beschouwt u al het andere als buiten scope, wat het ook in zijn systeemvak toont.
Checklist voordat u beide houdt
Werk deze lijst op volgorde af; het eerste item dat faalt, is het item dat u moet oplossen.
- Bevestig dat precies één client de standaardroute en de resolver bezit.
- Wilt u de tweede client actief, sta dan expliciet het server-endpoint toe en controleer opnieuw na elke clientupdate.
- Schrijf de verwachte uitkomst op wanneer een van beide tunnels wegvalt en test precies dat geval.
- Controleer het faalpad na een herstart, wanneer de startvolgorde anders is.
- Stop op een beheerd profiel en vraag de eigenaar voordat u iets toevoegt.
Faalt stap drie, dan is het eerlijke antwoord dat slechts één client u een beleid geeft. Bepaal welke u vertrouwt en laat de andere gaan.