Dues aplicacions VPN alhora: quin kill switch s’aplica realment?
Un segon client VPN no hereta mai el kill switch del primer. Tres condicions decideixen quina política s’aplica i com verificar la vostra.
Dos clients VPN poden funcionar l’un al costat de l’altre, però els seus kill switches no es fusionen en una sola política. Cada client instal·la regles per al seu propi túnel, i cap dels dos no sap que l’altre existeix. M’hi vaig trobar amb un client de feina connectat primer: la segona aplicació no podia acabar l’encaixada de mans, va quedar-se a «Connecting» durant deu minuts i el primer túnel ho portava tot en silenci. Que la segona aplicació quedi protegida depèn de tres condicions, no de si les dues icones diuen Connectat.
A què està realment limitat un kill switch
Res del sistema operatiu no té una única bandera de kill switch. Un client que n’anuncia una instal·la un conjunt de regles: descarta tot el que no surti pel meu túnel i sovint tanca en fals quan el túnel desapareix. A Linux sol ser una cadena nftables o iptables, a Windows un conjunt de filtres Windows Filtering Platform, a Android i iOS l’encaminament propi del servei de túnel més el paràmetre del sistema que bloqueja les connexions sense VPN. La guia de VPN d’Android descriu aquest model de servei si voleu la visió de la plataforma.
L’abast és la part que importa. Una regla com «permet només paquets a la interfície de sortida wg0» no es preocupa per si existeix un segon túnel. Si un altre client aixeca wg1, les regles del primer client tracten aquests paquets com a trànsit ordinari: normalment descartats, de vegades permesos. En qualsevol cas decideix el primer client, i no té ni idea que una segona aplicació espera.
Tres condicions que decideixen qui queda cobert
No cal enumerar totes les combinacions. Tres preguntes ho resolen en uns minuts.
- La plataforma permet almenys un segon túnel? La majoria de telèfons Android i iPhones accepten només un servei VPN actiu per perfil d’usuari, així que la segona aplicació mai no té túnel ni imposa res. Obteniu una sola política, la de l’aplicació que va guanyar el lloc.
- Quin procés posseeix la ruta per defecte? Windows, macOS i Linux porten dos túnels sense problema. La ruta per defecte pertany al client que la va configurar últim o amb la millor mètrica, i l’altre client està connectat però inactiu. A Linux, el mode de ruta per defecte de wg-quick fa servir encaminament per polítiques amb una taula privada i una regla fwmark, de manera que un segon túnel wg-quick afegeix una regla concurrent en lloc de substituir la primera.
- El segon client pot arribar al seu propi servidor? Si el primer kill switch és de denegació per defecte, el punt final exterior de la segona aplicació és només una altra destinació descartada. Torna a intentar-ho en silenci i no informa mai d’un error.
La versió curta, per als fils 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 |
Dues d’aquestes files semblen idèntiques des de la icona de la safata, i per això la icona és la pitjor prova disponible aquí.
Què falla primer i com es veu
Un client encallat a «Connecting» mentre l’altre està sa és gairebé sempre fam de punt final: el kill switch actiu descarta l’encaixada de mans del segon client cap al seu propi servidor. Confirmeu-ho barat posant en pausa les regles de bloqueig del primer client durant un intent. Si el segon es connecta de seguida, la pregunta queda resposta.
El DNS és la segona fallada. Els clients configuren el resolutor per a la seva pròpia interfície, i alguns simplement sobreescriuen la llista global. Amb els dos túnels actius, les consultes poden sortir per una banda mentre el resolutor pertany a l’altra. Desconnecteu qualsevol de les dues aplicacions i la supervivent conserva un servidor de noms inabastable: les pàgines s’encallen un minut i després tornen a resoldre’s, mentre la VPN encara es mostra connectada.
La tercera és el flameig de rutes. Les reconnexions reordenen la ruta per defecte, i un kill switch lligat a una interfície no la segueix. El trànsit que fa un moment era dins del túnel ara coincideix amb una regla de descart, cosa que des del costat de l’usuari es llegeix com una VPN que deixa de funcionar a l’atzar.
Verifiqueu quina política és realment vigent
Feu-ho amb trànsit innòcu, no amb una cosa que trobaríeu a faltar.
A Linux, pregunteu al nucli qui guanya i a què s’enganxa el tallafoc. ip -4 route show default anomena el túnel que posseeix la sortida. ip rule show mostra si hi ha encaminament per polítiques en joc. sudo nft list ruleset | grep -n oifname mostra si els descarts estan lligats a un nom d’interfície, a una marca o a tota la cadena de sortida.
A Windows la mateixa història viu a la mètrica de ruta i a la llista de filtres: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric i Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". A macOS, netstat -rn -f inet | head -5 i scutil --dns | head -20.
Després feu el pas que la gent s’estalvia: atureu el túnel a propòsit i confirmeu que el trànsit que espereu que falli falla de debò. Una icona connectada és un estat de la interfície, no una imposició.
Quan dos clients és el disseny equivocat
Si l’únic requisit darrere de la segona aplicació és més protecció, elimineu-la. Dues polítiques de bloqueig que interactuen són menys predictibles que una, i cada reconnexió és una oportunitat d’acabar en un estat que cap proveïdor no prova.
Si realment necessiteu encadenament, per exemple una passarel·la corporativa arribada per un salt comercial, trieu un disseny amb un sol punt d’imposició. Això normalment vol dir un encaminador o un sol client que admeti la cadena, no dues aplicacions d’escriptori competint per la mateixa ruta per defecte. En un dispositiu gestionat, quedeu-vos amb el client autoritzat i tracteu tota la resta com a fora d’abast, faci el que faci a la safata.
Llista de comprovació abans de quedar-vos-en els dos
Recorreu la llista en ordre; el primer punt que falli és el que cal arreglar.
- Confirmeu que exactament un client posseeix la ruta per defecte i el resolutor.
- Si voleu el segon client actiu, permeteu explícitament el punt final del seu servidor i torneu a comprovar-ho després de cada actualització del client.
- Anoteu el resultat esperat quan caigui qualsevol dels túnels i proveu aquest cas concret.
- Comproveu el camí de fallada després d’un reinici, quan l’ordre d’arrencada és diferent.
- En un perfil gestionat, atureu-vos i pregunteu al propietari abans d’afegir res.
Si el tercer pas falla, la resposta honesta és que només un client us dona una política. Decidiu en quin confieu i deixeu anar l’altre.