Două aplicații VPN simultan: care kill switch se aplică de fapt?
Un al doilea client VPN nu moștenește niciodată kill switchul primului. Trei condiții decid ce politică se aplică și cum îl verificați pe al dumneavoastră.
Doi clienți VPN pot rula alături, dar kill switchurile lor nu fuzionează într-o singură politică. Fiecare client instalează reguli pentru propriul tunel, iar niciunul nu știe că celălalt există. Am dat peste asta cu un client de serviciu conectat primul: a doua aplicație nu putea termina handshake-ul, a stat pe „Connecting” zece minute, iar primul tunel a dus totul în liniște. Dacă a doua aplicație este protejată depinde de trei condiții, nu de faptul că ambele icoane spun Conectat.
La ce este de fapt limitat un kill switch
Nimic din sistemul de operare nu are un singur comutator de kill switch. Un client care anunță unul instalează un set de reguli: aruncă tot ce nu iese prin tunelul meu și, adesea, fail closed când tunelul dispare. Pe Linux e de obicei un lanț nftables sau iptables, pe Windows o serie de filtre Windows Filtering Platform, pe Android și iOS rutarea proprie a serviciului de tunel plus setarea de sistem care blochează conexiunile fără VPN. Ghidul VPN pentru Android descrie acel model de serviciu dacă vreți perspectiva platformei.
Domeniul de aplicare este partea care contează. O regulă de tipul „permite doar pachetele pe interfața de ieșire wg0” nu-i pasă dacă există un al doilea tunel. Dacă alt client ridică wg1, regulile primului client tratează pachetele ca trafic obișnuit: de obicei aruncate, uneori permise. În orice caz, primul client decide și nu are habar că o a doua aplicație așteaptă.
Trei condiții care decid cine este acoperit
Nu trebuie să enumerați fiecare combinație. Trei întrebări lămuresc lucrurile în câteva minute.
- Permite platforma măcar un al doilea tunel? Majoritatea telefoanelor Android și iPhone acceptă un singur serviciu VPN activ pe profil de utilizator, așa că a doua aplicație nu are niciodată un tunel și nu impune nimic. Primiți o singură politică, de la aplicația care a câștigat locul.
- Care proces deține ruta implicită? Windows, macOS și Linux duc fără probleme două tuneluri. Ruta implicită aparține clientului care a configurat-o ultimul sau cu metrica mai bună, iar celălalt client este conectat, dar inactiv. Pe Linux, modul de rută implicită al wg-quick folosește rutare bazată pe politici cu o tabelă privată și o regulă fwmark, astfel încât un al doilea tunel wg-quick adaugă o regulă concurentă în loc să o înlocuiască pe prima.
- Poate al doilea client să-și atingă propriul server? Dacă primul kill switch este default-deny, punctul final exterior al celei de-a doua aplicații este doar încă o destinație aruncată. Reîncearcă în tăcere și nu raportează niciodată o eroare.
Versiunea scurtă, pentru firele de suport:
| 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 |
Două dintre acele rânduri arată identic din icoana din tray, motiv pentru care icoana este cea mai slabă dovadă disponibilă aici.
Ce eșuează primul și cum arată
Un client blocat pe „Connecting” în timp ce celălalt este sănătos înseamnă aproape întotdeauna foamete de punct final: kill switchul activ aruncă handshake-ul celui de-al doilea client către propriul server. Confirmați ieftin pausând regulile de blocare ale primului client pentru o încercare. Dacă al doilea se conectează imediat, întrebarea are răspuns.
DNS este a doua defecțiune. Clienții setează configurația resolverului pentru propria interfață, iar unii pur și simplu suprascriu lista globală de resolvere. Cu ambele tuneluri active, interogările pot ieși pe o parte în timp ce resolverul aparține celeilalte. Deconectați oricare aplicație și supraviețuitorul păstrează un server de nume inaccesibil: paginile se blochează un minut și apoi se rezolvă din nou, în timp ce VPN-ul arată în continuare conectat.
A treia este flapping-ul rutelor. Reconectările reordonează ruta implicită, iar un kill switch legat de interfață nu o urmează. Traficul care acum un moment era în tunel corespunde acum unei reguli de aruncare, ceea ce din perspectiva utilizatorului se citește ca un VPN care se oprește aleatoriu din funcționare.
Verificați ce politică este realmente în vigoare
Faceți asta cu trafic inofensiv, nu cu ceva ce v-ar lipsi.
Pe Linux, întrebați kernelul cine câștigă și de ce se leagă firewallul. ip -4 route show default numește tunelul care deține ieșirea. ip rule show arată dacă rutarea bazată pe politici este în joc. sudo nft list ruleset | grep -n oifname arată dacă aruncările sunt legate de un nume de interfață, de un marcaj sau de întregul lanț de ieșire.
Pe Windows aceeași poveste stă în metrica rutei și în lista de filtre: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric și Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". Pe macOS, netstat -rn -f inet | head -5 și scutil --dns | head -20.
Apoi faceți pasul pe care oamenii îl sar: opriți tunelul intenționat și confirmați că traficul care ar trebui să eșueze eșuează cu adevărat. O icoană conectată este o stare de interfață, nu o impunere.
Când doi clienți sunt proiectul greșit
Dacă singura cerință din spatele celei de-a doua aplicații este mai multă protecție, eliminați-o. Două politici de blocare care interacționează sunt mai puțin previzibile decât una, iar fiecare reconectare este o șansă de a ajunge într-o stare pe care niciun furnizor nu o testează.
Dacă aveți cu adevărat nevoie de înlănțuire, de exemplu o poartă de firmă atinsă printr-un salt comercial, alegeți un proiect cu un singur punct de impunere. Asta înseamnă de obicei un router sau un singur client care acceptă lanțul, nu două aplicații desktop care se întrec pentru aceeași rută implicită. Pe un dispozitiv administrat, păstrați clientul aprobat și tratați orice altceva ca în afara scopului, indiferent ce arată în tray.
Listă de verificare înainte de a le păstra pe amândouă
Parcurgeți lista în ordine; primul punct care eșuează este cel de reparat.
- Confirmați că exact un client deține ruta implicită și resolverul.
- Dacă vreți al doilea client activ, permiteți explicit punctul final al serverului său și reverificați după fiecare actualizare a clientului.
- Notați rezultatul așteptat când cade oricare tunel și testați exact acel caz.
- Verificați calea de eșec după o repornire, când ordinea de pornire este diferită.
- Pe un profil administrat, opriți-vă și întrebați proprietarul înainte de a adăuga ceva.
Dacă pasul trei eșuează, răspunsul onest este că un singur client vă dă o politică. Decideți în care aveți încredere și lăsați-l pe celălalt să plece.