Twa VPN-apps tagelyk: hokker kill switch jildt echt?
In twadde VPN-klant erft nea de kill switch fan de earste. Trije betingsten beslisse hokker belied jildt, en hoe't jo dy fan jo kontrolearje.
Twa VPN-klanten kinne njonken inoar draaie, mar har kill switches smelte net gear ta ien belied. Elke klant ynstallearret regels foar syn eigen tunnel, en gjinien wit dat de oare bestiet. Ik kaam dit tsjin mei in wurkklant dy't earst ferbûn wie: de twadde app koe syn hânskodding net ôfmeitsje, siet tsien minuten op „Connecting“ en de earste tunnel droech alles stilwei. Oft de twadde app beskerme wurdt, hinget fan trije betingsten ôf, net fan oft beide byldkaikes Ferbûn sizze.
Wêr't in kill switch echt ta beheind is
Neat yn it bestjoeringssysteem hat ien inkele kill switch-flagge. In klant dy't ien advertearret, ynstallearret in regelset: smyt alles fuort dat net troch myn tunnel nei bûten giet, en faak fail closed as de tunnel ferdwynt. Op Linux is dat meastentiids in nftables- of iptables-ketting, op Windows in set Windows Filtering Platform-filters, op Android en iOS de tunneltsjinst syn eigen rûtelegging plus de systeemynstelling dy't ferbiningen sûnder VPN blokkeart. De Android-VPN-gids beskriuwt dat tsjinstmodel as jo it eachpunt fan it platfoarm wolle.
De omfang is it part dat fan belang is. In regel lykas „lit allinne pakketten op útgeande ynterface wg0 ta“ skiter der net om oft der in twadde tunnel bestiet. As in oare klant wg1 omheech bringt, behannelje de regels fan de earste klant dy pakketten as gewoan ferkear: meastentiids fuortsmiten, soms tastien. Hoe dan ek beslútmint de earste klant, en hy hat gjin idee dat in twadde app wachtet.
Trije betingsten dy't beslisse wa't dekt wurdt
Jo hoege net elke kombinaasje te neamen. Trije fragen beslisse it yn in pear minuten.
- Lit it platfoarm hielendal in twadde tunnel ta? De measte Android-tillefoans en iPhones akseptearje mar ien aktyf VPN-tsjinst per brûkersprofyl, dat de twadde app hat nea in tunnel en twingt nea wat ôf. Jo krije ien belied, fan de app dy't it plak wûn.
- Hokker proses besit de standertrûte? Windows, macOS en Linux drage mei gemak twa tunnels. De standertrûte heart by de klant dy't him it lêst of mei de bettere mjitte ynstelde, en de oare klant is ferbûn mar ledich. Op Linux brûkt de standertrûtemodus fan wg-quick beliedsrûtelegging mei in priveetabel en in fwmark-regel, dat in twadde wg-quick-tunnel foeget in konkurrearjende regel ta ynstee fan de earste te ferfangen.
- Kin de twadde klant syn eigen tsjinner berikke? As de earste kill switch standert-wegering is, is it bûtenste einpunt fan de twadde app gewoan noch in fuortsmiten bestimming. Hy besiket it stil op 'e nij en rapportearret nea in flater.
De koarte ferzje, foar stipe-triedden:
| 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 |
Twa fan dy rigen lykje identyk fan it byldkaike yn 'e systeemlade, en dêrom is it byldkaike hjir it minste bewiis dat beskikber is.
Wat it earst mist, en hoe't dat der útsjocht
In klant dy't fêstsit op „Connecting“ wylst de oare sûn is, is hast altyd einpunt-honger: de wurkjende kill switch smyt de hânskodding fan 'e twadde klant nei syn eigen tsjinner fuort. Befêstigje dat goedkeap troch de blokregels fan de earste klant ien poging lang te pauzearen. As de twadde daliks ferbynt, is de fraach beantwurde.
DNS is de twadde faling. Klanten stelle de oplosserkonfiguraasje foar har eigen ynterface yn, en guon skriuwe gewoan de globale list oer. Mei beide tunnels omheech kinne fragen troch de iene kant nei bûten gean wylst de oplosser by de oare heart. Untkoppelje ien fan 'e apps en de oerlibbene hâldt in ûnberikbere nametsjinst: siden hinge in minút en lossen dan wer op, wylst de VPN noch altyd ferbûn toant.
De tredde is rûte-flapping. Werferbiningen oardene de standertrûte opnij, en in oan in ynterface bûne kill switch folget dy net. Ferkear dat in momint lyn noch yn 'e tunnel siet, past no by in smytregel, wat oan 'e brûkerskant lêst as in VPN dy't willekeurich ophâldt te wurkjen.
Kontrolearje hokker belied echt fan krêft is
Doch dit mei ûnskealik ferkear, net mei eat dat jo misse soene.
Freegje op Linux de kearn wa't wint en wêroan de fjoermuorre him bynt. ip -4 route show default neamt de tunnel dy't de útgong besit. ip rule show lit sjen oft beliedsrûtelegging yn it spul is. sudo nft list ruleset | grep -n oifname lit sjen oft smytregels oan in ynterfacenamme, in mark of de hiele útgongskeatling bûn binne.
Op Windows wennet itselde ferhaal yn 'e rûtemjitte en de filterlist: 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.
Doch dan de stap dy't minsken oerslaan: stop de tunnel mei opsetsin en befêstigje dat it ferkear dat jo ferwachtsje dat it mist, echt mist. In ferbûn byldkaike is in ynterfacestatus, net hanthavening.
Wannear't twa klanten it ferkearde ûntwerp is
As de iennichste eask efter de twadde app mear beskerming is, ferwiderje him. Twa op inoar ynwurkjende blokbeliedens binne minder foarsisber as ien, en elke werferbining is in kâns om yn in steat te belânjen dy't gjin leveransier testet.
As jo echt ketening nedich hawwe, bygelyks in bedriuwsgateway berikt oer in kommersjele hop, kies dan in ûntwerp mei ien hanthaveningspunt. Dat betsjut normaal in router of ien klant dy't de keatling stipet, net twa buroblêd-apps dy't om deselde standertrûte fjochtsje. Op in beheard apparaat hâldt jo de goedkarde klant en behannelje al it oare as bûten omfang, wat it ek yn 'e systeemlade toant.
Kontrolelist foardat jo beide hâlde
Wurkje de list yn folchoarder ôf; it earste item dat mist, is it item dat reparearre wurde moat.
- Befêstigje dat krekt ien klant de standertrûte en de oplosser besit.
- As jo de twadde klant hawwe wolle, lit syn tsjinner syn einpunt dan eksplisyt ta en kontrolearje op 'e nij nei elke klantfernijing.
- Skriuw de ferwachte útkomst op as ien fan 'e tunnels falt, en test krekt dat gefal.
- Kontrolearje it mistpaad nei in werstart, wannear't de startfolchoarder oars is.
- Op in beheard profyl, stop en freegje de eigner foardat jo eat tafoegje.
As stap trije mist, is it earlike antwurd dat mar ien klant jo in belied jout. Beslis hokker jo fertrouwe en lit de oare gean.