Dúas aplicacións VPN á vez: cal kill switch se aplica realmente?
Un segundo cliente VPN nunca herda o kill switch do primeiro. Tres condicións deciden que política se aplica e como verificar a súa.
Dous clientes VPN poden funcionar un ao lado do outro, pero os seus kill switches non se fusionan nunha soa política. Cada cliente instala regras para o seu propio túnel, e ningún sabe que o outro existe. Atopei isto cun cliente de traballo conectado primeiro: a segunda aplicación non podía rematar o aperto de mans, quedou en «Connecting» durante dez minutos e o primeiro túnel levaba todo en silencio. Se a segunda aplicación queda protexida depende de tres condicións, non de que ambas as iconas digan Conectado.
A que está realmente limitado un kill switch
Nada no sistema operativo ten unha única bandeira de kill switch. Un cliente que anuncia unha instala un conxunto de regras: descarta todo o que non saia polo meu túnel e a miúdo pecha en falso cando o túnel desaparece. En Linux adoita ser unha cadea nftables ou iptables, en Windows un conxunto de filtros Windows Filtering Platform, en Android e iOS o encamiñamento propio do servizo de túnel máis o axuste do sistema que bloquea as conexións sen VPN. A guía de VPN de Android describe ese modelo de servizo se queres a visión da plataforma.
O alcance é a parte que importa. Unha regra como «permitir só paquetes na interface de saída wg0» non se preocupa de se existe un segundo túnel. Se outro cliente levanta wg1, as regras do primeiro cliente tratan eses paquetes como tráfico normal: normalmente descartados, ás veces permitidos. En calquera caso decide o primeiro cliente, e non ten nin idea de que unha segunda aplicación está a esperar.
Tres condicións que deciden quen queda cuberto
Non cómpre enumerar todas as combinacións. Tres preguntas resólveno nuns minutos.
- Permite a plataforma sequera un segundo túnel? A maioría dos teléfonos Android e os iPhone aceptan só un servizo VPN activo por perfil de usuario, así que a segunda aplicación nunca ten túnel nin impón nada. Obtés unha soa política, a da aplicación que gañou o sitio.
- Que proceso posúe a ruta por defecto? Windows, macOS e Linux levan dous túneles sen problema. A ruta por defecto pertence ao cliente que a configurou último ou coa mellor métrica, e o outro cliente está conectado pero inactivo. En Linux, o modo de ruta por defecto de wg-quick usa encamiñamento por políticas cunha táboa privada e unha regra fwmark, de xeito que un segundo túnel wg-quick engade unha regra competidora en vez de substituír a primeira.
- Pode o segundo cliente chegar ao seu propio servidor? Se o primeiro kill switch é de denegación por defecto, o punto final exterior da segunda aplicación é só outro destino descartado. Volve tentar en silencio e nunca informa dun erro.
A versión curta, para os fíos de soporte:
| 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 |
Dúas desas filas parecen idénticas desde a icona da bandexa, e por iso a icona é a peor proba dispoñible aquí.
Que falla primeiro e como se ve
Un cliente atascado en «Connecting» mentres o outro está san é case sempre fame de punto final: o kill switch activo descarta o aperto de mans do segundo cliente cara ao seu propio servidor. Confírmao barato pausando as regras de bloqueo do primeiro cliente durante un intento. Se o segundo se conecta de inmediato, a pregunta queda respondida.
O DNS é a segunda falla. Os clientes configuran o resolutor para a súa propia interface, e algúns simplemente sobreescriben a lista global. Cos dous túneles activos, as consultas poden saír por unha banda mentres o resolutor pertence á outra. Desconecta calquera das dúas aplicacións e a supervivente conserva un servidor de nomes inalcanzable: as páxinas atascan un minuto e despois volven resolverse, mentres a VPN segue mostrándose conectada.
A terceira é o flameo de rutas. As reconexións reordenan a ruta por defecto, e un kill switch ligado a unha interface non a segue. O tráfico que hai un momento estaba dentro do túnel agora coincide cunha regra de descarte, o que do lado do usuario se le como unha VPN que deixa de funcionar ao azar.
Verifica que política está realmente vixente
Faino con tráfico inocuo, non con algo que botarías de menos.
En Linux, pregunta ao núcleo quen gaña e a que se liga o devasado. ip -4 route show default nomea o túnel que posúe a saída. ip rule show mostra se hai encamiñamento por políticas en xogo. sudo nft list ruleset | grep -n oifname mostra se os descartes están ligados a un nome de interface, a unha marca ou a toda a cadea de saída.
En Windows a mesma historia vive na métrica de ruta e na lista de filtros: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric e Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". En macOS, netstat -rn -f inet | head -5 e scutil --dns | head -20.
Despois fai o paso que a xente salta: detén o túnel a propósito e confirma que o tráfico que esperas que falle falla de verdade. Unha icona conectada é un estado da interface, non unha imposición.
Cando dous clientes é o deseño equivocado
Se o único requisito detrás da segunda aplicación é máis protección, elimínaa. Dúas políticas de bloqueo que interactúan son menos previsibles ca unha, e cada reconexión é unha oportunidade de acabar nun estado que ningún provedor proba.
Se de verdade necesitas encadeamento, por exemplo unha pasarela corporativa alcanzada por un salto comercial, escolle un deseño cun único punto de imposición. Iso normalmente significa un encamiñador ou un único cliente que admita a cadea, non dúas aplicacións de escritorio competindo pola mesma ruta por defecto. Nun dispositivo xestionado, queda co cliente autorizado e trata todo o demais como fóra de alcance, mostre o que mostre na bandexa.
Lista de comprobación antes de quedar cos dous
Percorre a lista por orde; o primeiro punto que falle é o que hai que arranxar.
- Confirma que exactamente un cliente posúe a ruta por defecto e o resolutor.
- Se queres o segundo cliente activo, permite explicitamente o punto final do seu servidor e volve comprobar despois de cada actualización do cliente.
- Anota o resultado esperado cando caia calquera dos túneles e proba ese caso concreto.
- Comproba o camiño de falla tras un reinicio, cando a orde de arranque é diferente.
- Nun perfil xestionado, detente e pregunta ao propietario antes de engadir nada.
Se o terceiro paso falla, a resposta honesta é que só un cliente che dá unha política. Decide en cal confías e deixa ir o outro.