Dos aplicaciones VPN a la vez: ¿qué kill switch se aplica realmente?
Un segundo cliente VPN nunca hereda el kill switch del primero. Tres condiciones deciden qué política se aplica y cómo verificar la suya.
Dos clientes VPN pueden ejecutarse en paralelo, pero sus kill switches no se fusionan en una sola política. Cada cliente instala reglas para su propio túnel, y ninguno sabe que el otro existe. Me pasó con un cliente de trabajo conectado primero: la segunda aplicación no lograba terminar su handshake, se quedó en «Connecting» durante diez minutos y el primer túnel llevó todo en silencio. Que la segunda aplicación quede protegida depende de tres condiciones, no de que ambos iconos digan «Conectado».
A qué está realmente limitado un kill switch
Nada en el sistema operativo tiene una única bandera de kill switch. Un cliente que anuncia una instala un conjunto de reglas: descartar todo lo que no salga por mi túnel y, a menudo, cerrar en falso cuando el túnel desaparece. En Linux suele ser una cadena de nftables o iptables, en Windows un conjunto de filtros de Windows Filtering Platform, en Android e iOS el enrutamiento propio del servicio de túnel más el ajuste del sistema que bloquea las conexiones sin VPN. La guía de VPN de Android describe ese modelo de servicio si quiere la visión de la plataforma.
El alcance es la parte que importa. Una regla como permitir solo los paquetes de la interfaz de salida wg0 no se preocupa de si existe un segundo túnel. Si otro cliente levanta wg1, las reglas del primer cliente tratan esos paquetes como tráfico normal: casi siempre descartados, a veces permitidos. En cualquier caso decide el primer cliente, y no tiene ni idea de que una segunda aplicación está esperando.
Tres condiciones que deciden quién queda cubierto
No hace falta enumerar todas las combinaciones. Tres preguntas lo resuelven en unos minutos.
- ¿Permite la plataforma un segundo túnel siquiera? La mayoría de los teléfonos Android y los iPhone aceptan un solo servicio VPN activo por perfil de usuario, así que la segunda aplicación nunca tiene un túnel ni aplica nada. Obtiene una sola política, la de la aplicación que ganó el sitio.
- ¿Qué proceso es dueño de la ruta por defecto? Windows, macOS y Linux transportan dos túneles sin problema. La ruta por defecto pertenece al cliente que la configuró en último lugar o con la mejor métrica, y el otro cliente está conectado pero inactivo. En Linux, el modo de ruta por defecto de wg-quick usa enrutamiento por políticas con una tabla privada y una regla fwmark, de modo que un segundo túnel wg-quick añade una regla competidora en lugar de reemplazar la primera.
- ¿Puede el segundo cliente llegar a su propio servidor? Si el primer kill switch es de denegación por defecto, el extremo exterior de la segunda aplicación es solo otro destino descartado. Reintenta en silencio y nunca informa de un error.
La versión corta, para los hilos 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 |
Dos de esas filas se ven idénticas desde el icono de la bandeja, y por eso el icono es la peor prueba disponible aquí.
Qué falla primero y cómo se ve
Un cliente atascado en «Connecting» mientras el otro está sano es casi siempre inanición del extremo: el kill switch en marcha descarta el handshake del segundo cliente hacia su propio servidor. Confírmelo barato pausando las reglas de bloqueo del primer cliente durante un intento. Si el segundo se conecta de inmediato, la pregunta está respondida.
El DNS es el segundo fallo. Los clientes configuran el resolutor para su propia interfaz, y algunos sobrescriben la lista global sin más. Con ambos túneles activos, las consultas pueden salir por un lado mientras el resolutor pertenece al otro. Desconecte cualquiera de las dos aplicaciones y la superviviente conserva un servidor de nombres inalcanzable: las páginas se atascan un minuto y luego vuelven a resolver, mientras la VPN sigue mostrándose conectada.
El tercero es el aleteo de rutas. Las reconexiones reordenan la ruta por defecto, y un kill switch atado a una interfaz no la sigue. El tráfico que hace un momento estaba dentro del túnel ahora coincide con una regla de descarte, lo que del lado del usuario se lee como una VPN que deja de funcionar al azar.
Verificar qué política está realmente en vigor
Hágalo con tráfico inofensivo, no con algo que echaría de menos.
En Linux, pregunte al núcleo quién gana y a qué se ata el cortafuegos. ip -4 route show default nombra el túnel dueño de la salida. ip rule show muestra si hay enrutamiento por políticas en juego. sudo nft list ruleset | grep -n oifname muestra si los descartes están atados a un nombre de interfaz, a una marca o a toda la cadena de salida.
En Windows la misma historia vive en la métrica de ruta y la lista de filtros: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric y Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". En macOS, netstat -rn -f inet | head -5 y scutil --dns | head -20.
Luego haga el paso que la gente se salta: detenga el túnel a propósito y confirme que el tráfico que espera que falle falla de verdad. Un icono conectado es un estado de la interfaz, no una imposición.
Cuándo dos clientes es el diseño equivocado
Si el único requisito detrás de la segunda aplicación es más protección, elimínela. Dos políticas de bloqueo que interactúan son menos predecibles que una, y cada reconexión es una ocasión de acabar en un estado que ningún proveedor prueba.
Si de verdad necesita encadenamiento, como una pasarela corporativa alcanzada por un salto comercial, elija un diseño con un solo punto de aplicación. Eso suele significar un router o un único cliente que soporte la cadena, no dos aplicaciones de escritorio compitiendo por la misma ruta por defecto. En un dispositivo gestionado, quédese con el cliente autorizado y trate todo lo demás como fuera de alcance, muestre lo que muestre en su bandeja.
Lista de comprobación antes de quedarse con los dos
Recorra esta lista en orden; el primer punto que falle es el que hay que arreglar.
- Confirme que exactamente un cliente es dueño de la ruta por defecto y del resolutor.
- Si quiere el segundo cliente activo, permita explícitamente el extremo de su servidor y vuelva a comprobarlo tras cada actualización del cliente.
- Anote el resultado esperado cuando caiga cualquiera de los túneles y pruebe ese caso concreto.
- Compruebe la ruta de fallo tras un reinicio, cuando el orden de arranque es distinto.
- En un perfil gestionado, deténgase y pregunte al propietario antes de añadir nada.
Si el tercer paso falla, la respuesta honesta es que solo un cliente le está dando una política. Decida en cuál confía y deje ir al otro.