Twee VPN-programme gelyktydig: watter kill switch geld eintlik?
’n Tweede VPN-kliënt erf nooit die eerste kliënt se kill switch nie. Drie voorwaardes bepaal watter beleid geld, en hoe om joune te verifieer.
Twee VPN-kliënte kan langs mekaar loop, maar hulle kill switches smelt nie in een beleid saam nie. Elke kliënt installeer reëls vir sy eie tonnel, en nie een weet dat die ander bestaan nie. Ek het dit teegekom met ’n werkkliënt wat eerste gekoppel was: die tweede program kon nie sy handdruk voltooi nie, het tien minute op „Connecting“ gesit, en die eerste tonnel het alles stil-stil gedra. Of die tweede program beskerm word, hang van drie voorwaardes af, nie van of albei ikone Geskakel sê nie.
Waarop ’n kill switch werklik beperk is
Niks in die bedryfstelsel het ’n enkele kill switch-vlag nie. ’n Kliënt wat een adverteer, installeer ’n reëlstel: gooi alles weg wat nie deur my tonnel uitgaan nie, en dikwels fail closed wanneer die tonnel verdwyn. Op Linux is dit gewoonlik ’n nftables- of iptables-ketting, op Windows ’n stel Windows Filtering Platform-filters, op Android en iOS die tonneldiens se eie routering plus die stelselinstelling wat verbindings sonder VPN blokkeer. Die Android-VPN-gids beskryf daardie diensmodel as jy die platform se siening wil hê.
Die omvang is die deel wat saak maak. ’n Reël soos „laat net pakkette op uitvoerkoppelvlak wg0 toe“ steur hom nie daaraan of ’n tweede tonnel bestaan nie. As ’n ander kliënt wg1 opbring, behandel die eerste kliënt se reëls daardie pakkette as gewone verkeer: gewoonlik weggegooi, soms toegelaat. Hoe dit ook al sy, die eerste kliënt besluit, en hy het geen idee dat ’n tweede program wag nie.
Drie voorwaardes wat bepaal wie gedek word
Jy hoef nie elke kombinasie te lys nie. Drie vrae beslis dit in ’n paar minute.
- Laat die platform enige tweede tonnel toe? Die meeste Android-fone en iPhones aanvaar net een aktiewe VPN-diens per gebruikersprofiel, so die tweede program het nooit ’n tonnel nie en dwing nooit iets af nie. Jy kry een beleid, van die program wat die plek gewen het.
- Watter proses besit die verstekroete? Windows, macOS en Linux dra twee tonnels maklik. Die verstekroete behoort aan die kliënt wat dit laas of met die beter maatstaf opgestel het, en die ander kliënt is gekoppel maar ledig. Op Linux gebruik wg-quick se verstekroetemodus beleidsroutering met ’n private tabel en ’n fwmark-reël, so ’n tweede wg-quick-tonnel voeg ’n mededingende reël by eerder as om die eerste te vervang.
- Kan die tweede kliënt sy eie bediener bereik? As die eerste kill switch verstek-weier is, is die tweede program se buitenste eindpunt net nog ’n weggegooide bestemming. Dit probeer weer in stilte en rapporteer nooit ’n fout nie.
Die kort weergawe, vir ondersteuningsdrade:
| 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 daardie rye lyk identies vanaf die ikoon in die systeemkas, en daarom is die ikoon die swakste bewyse hier beskikbaar.
Wat eerste faal, en hoe dit lyk
’n Kliënt wat op „Connecting“ vashaak terwyl die ander gesond is, is byna altyd eindpunt-honger: die werkende kill switch gooi die tweede kliënt se handdruk na sy eie bediener weg. Bevestig dit goedkoop deur die eerste kliënt se blokreëls vir een poging te pouseer. As die tweede dadelik koppel, is die vraag beantwoord.
DNS is die tweede faling. Kliënte stel die oplosser se konfigurasie vir hul eie koppelvlak op, en sommige skryf die globale oplosserlys eenvoudig oor. Met albei tonnels op kan navrae deur die een kant uitgaan terwyl die oplosser aan die ander behoort. Ontkoppel enige program en die oorlewende hou ’n onbereikbare naamdiens: bladsye hang ’n minuut en los dan weer op, terwyl die VPN steeds gekoppel wys.
Die derde is roete-flapping. Herverbindings herrangskik die verstekroete, en ’n koppelvlakgebonde kill switch volg dit nie. Verkeer wat ’n oomblik gelede in die tonnel was, pas nou by ’n weggooireël, wat aan die gebruiker se kant lees as ’n VPN wat willekeurig ophou werk.
Verifieer watter beleid werklik van krag is
Doen dit met onskadelike verkeer, nie met iets wat jy sou mis nie.
Vra op Linux die kern wie wen en waaraan die vuurmuur bind. ip -4 route show default noem die tonnel wat die uitgang besit. ip rule show wys of beleidsroutering in die spel is. sudo nft list ruleset | grep -n oifname wys of weggooiings aan ’n koppelvlaknaam, ’n merk of die hele uitvoerketting gebind is.
Op Windows woon dieselfde verhaal in die roetemaatstaf en die filterlys: 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.
Doen dan die stap wat mense oorslaan: stop die tonnel doelbewus en bevestig dat die verkeer wat jy verwag moet faal, werklik faal. ’n Gekoppelde ikoon is ’n koppelvlaktoestand, nie handhawing nie.
Wanneer twee kliënte die verkeerde ontwerp is
As die enigste vereiste agter die tweede program meer beskerming is, verwyder dit. Twee interaktiewe blokbeleide is minder voorspelbaar as een, en elke herverbinding is ’n kans om in ’n toestand te beland wat geen verskaffer toets nie.
As jy werklik koppeling nodig het, soos ’n korporatiewe poort bereik oor ’n kommersiële hop, kies ’n ontwerp met een handhawingspunt. Dit beteken gewoonlik ’n roeteerder of een kliënt wat die ketting ondersteun, nie twee lessenaarprogramme wat om dieselfde verstekroete meeding nie. Op ’n bestuurde toestel hou die goedgekeurde kliënt en behandel alles anders as buite omvang, wat dit ook al in die systeemkas wys.
Kontrolelys voordat jy albei hou
Werk die lys in volgorde deur; die eerste item wat faal, is die een om reg te maak.
- Bevestig dat presies een kliënt die verstekroete en die oplosser besit.
- As jy die tweede kliënt wil hê, laat sy bediener se eindpunt uitdruklik toe en kontroleer weer ná elke kliëntopdatering.
- Skryf die verwagte uitkoms neer wanneer enige tonnel val, en toets daardie spesifieke geval.
- Kontroleer die falingpad ná ’n herbegin, wanneer die beginorde anders is.
- Op ’n bestuurde profiel, stop en vra die eienaar voordat jy iets byvoeg.
As stap drie faal, is die eerlike antwoord dat net een kliënt vir jou ’n beleid gee. Besluit watter een jy vertrou en laat die ander gaan.