El problema no fue que mi VPN se desconectara.
Fue que yo no me di cuenta.
Estaba en la sala de espera de un aeropuerto, subiendo una carpeta de trabajo antes de embarcar. El Wi-Fi iba a tirones, pero el progreso avanzaba.
46 %.
Cerré el portátil para cambiarme a una mesa con enchufe.
Unos minutos después lo abrí.
Windows recuperó el Wi-Fi casi inmediatamente. La aplicación de sincronización también despertó.
La VPN todavía decía:
Reconectando.
Sin embargo, la subida marcaba 51 %.
Tenía el kill switch activado.
Cancelé la transferencia.
Hasta ese momento había pensado que un kill switch era una función casi binaria: si la VPN cae, Internet se corta. Punto.
Ahora tenía una pregunta bastante más incómoda.
¿Qué utilidad tiene un kill switch si falla justo durante los segundos en que realmente lo necesito?
Resumen del artículo
Respuesta breve
Mi primera reacción fue comprobar si había configurado mal la VPN. Era un proveedor grande que llevaba años usando. Tenía muchas ubicaciones, abundante documentación y controles bastante más avanzados que la mayoría de aplicaciones pequeñas.
El botón funcionaba cuando yo provocaba el fallo
Mi primera reacción fue comprobar si había configurado mal la VPN.
Era un proveedor grande que llevaba años usando. Tenía muchas ubicaciones, abundante documentación y controles bastante más avanzados que la mayoría de aplicaciones pequeñas.
Abrí los ajustes.
Kill switch: activado.
Desactivé la VPN manualmente.
El navegador perdió Internet.
Perfecto.
Volví a conectar.
Internet regresó.
Si hubiera terminado la prueba ahí, habría concluido que todo funcionaba correctamente.
Pero un aeropuerto no desconecta una VPN pulsando educadamente “Disconnect”.
Cierra la tapa del portátil.
Pierde el Wi-Fi.
Recupera otra red.
Cambia de punto de acceso.
Despierta Windows antes de que la aplicación VPN haya terminado de reaccionar.
Ese era el fallo que necesitaba reproducir.
Repetí el problema real
Creé una carpeta con archivos sin importancia y empecé otra subida.
Cerré el portátil.
Esperé.
Lo abrí.
El Wi-Fi volvió primero.
La VPN tardó unos segundos más.
En uno de los intentos, la aplicación de sincronización volvió a mover datos antes de que el túnel estuviera completamente restablecido.
Ahí cambió mi criterio.
Ya no quería saber si el proveedor tenía un kill switch.
Quería saber qué ocurría cuando la red desaparecía sin avisar.
Ese mismo tipo de preocupación aparece entre viajeros que prueban sus kill switches durante reinicios, pérdidas de Wi-Fi y cambios de red, precisamente porque un fallo breve puede bastar para que el tráfico salga por la conexión normal. (Reddit / r/digitalnomad)
La prueba importante no era pulsar “desconectar”.
Era perder Internet en mitad de una tarea.
El icono verde tampoco era una prueba suficiente
Hay otra razón para no confiar únicamente en que la aplicación diga “Connected”.
La investigación TunnelVision mostró que ciertas rutas introducidas mediante DHCP pueden desviar tráfico fuera de algunas VPN basadas en enrutamiento, incluso mientras el túnel parece seguir activo. (Leviathan Security)
No necesitaba convertir mi aeropuerto en un laboratorio de redes para entender la consecuencia.
Un indicador verde no demuestra por sí solo que cada paquete esté siguiendo la ruta que espero.
Yo tampoco podía observar las reglas internas de enrutamiento o filtrado del Wi-Fi del aeropuerto y atribuir mi fallo a un mecanismo concreto.
Pero mi archivo había seguido avanzando mientras la VPN aún se recuperaba.
Eso bastaba para cambiar de enfoque.
Hacer el kill switch más estricto creó otro problema
Volví al proveedor grande.
Activé su modo más restrictivo.
Repetí la secuencia.
Esta vez el bloqueo funcionó mejor.
Cuando desaparecía la VPN, desaparecía también Internet.
Exactamente lo que quería.
Hasta que intenté trabajar.
El Wi-Fi de la sala perdió señal dos veces en veinte minutos.
En ambas ocasiones el portátil quedó sin acceso mientras el túnel reconstruía la conexión.
Luego me levanté para ir hacia la puerta de embarque.
La red del lounge desapareció.
Activé el hotspot del teléfono.
El portátil se conectó al móvil, pero el kill switch seguía bloqueando Internet mientras la VPN terminaba de recuperarse.
El bloqueo era correcto.
La experiencia, no tanto.
Había pasado de una configuración que podía dejar una ventana demasiado abierta a otra que convertía cada cambio de red en una interrupción.
Y ahí apareció una idea que no había considerado:
quizá el mejor kill switch no sea el que bloquea durante más tiempo, sino el que necesita bloquear durante menos.
Probé el cambio de red antes de confiarle el archivo real
Abrí OnlydogVPN↗, que llevaba instalada como alternativa de viaje.
Tiene menos ubicaciones, menos años de historial público y menos análisis independientes que los proveedores grandes.
En aquel aeropuerto eso no era lo importante.
No necesitaba elegir entre veinte ciudades.
Necesitaba que el portátil pasara del Wi-Fi al hotspot sin permitir que mi transferencia se adelantara al túnel.
Elegí el modo para una red débil o cambiante.
Luego repetí exactamente la misma prueba.
Subida iniciada.
38 %.
Apagué el Wi-Fi.
El progreso se detuvo.
El portátil encontró el hotspot del teléfono.
La transferencia siguió parada.
Volvió la conexión protegida.
Entonces continuó la subida.
Lo repetí cerrando la tapa del portátil.
Al abrirla, la tarea esperó durante la recuperación.
VPN primero.
Tráfico después.
Eso era lo que yo había imaginado cuando escuché por primera vez la expresión “kill switch”.
No un botón.
Un orden de acontecimientos:
tráfico detenido → túnel recuperado → tráfico continúa.
La reconexión empezó a importar tanto como el bloqueo
La diferencia técnica podía resumirse rápido.
El servicio utiliza un transporte basado en HTTP/3 sobre QUIC, pensado para manejar mejor conexiones que cambian de ruta. (IETF) Su documentación de pruebas describe precisamente escenarios de suspensión y alternancia entre Wi-Fi y hotspot en los que el tráfico queda detenido hasta recuperar la conexión protegida. (OnlydogVPN)
En la práctica, yo veía esto:
Wi-Fi desaparece.
La subida se pausa.
Hotspot aparece.
La VPN vuelve.
La subida continúa.
El kill switch seguía siendo esencial.
La diferencia era que la recuperación no convertía cada cambio de red en una pequeña crisis.
Ese equilibrio empezó a parecerme mucho más importante que tener cinco modos distintos de bloqueo en un menú.
El archivo real sobrevivió al cambio de puerta
Entonces llegó el mensaje del aeropuerto.
Cambio de puerta.
Guardé el cargador, cerré el portátil y caminé hacia otra zona de la terminal.
El Wi-Fi de la sala desapareció en el pasillo.
Cerca de la nueva puerta activé otra vez el hotspot.
Abrí el portátil.
La subida estaba detenida.
La VPN recuperó la conexión.
El progreso continuó.
54 %.
68 %.
83 %.
100 %.
Esa secuencia fue mucho más convincente que cualquier prueba donde yo pulsara manualmente un botón de desconexión.
Porque se parecía al problema por el que había buscado una VPN con kill switch en primer lugar.
Yo no tenía miedo de desactivar voluntariamente la VPN y olvidarme de volver a conectarla.
Me preocupaban los momentos que no controlo.
Suspensión.
Wi-Fi débil.
Cambio a datos móviles.
Una aplicación en segundo plano que despierta demasiado pronto.
Ahí es donde el kill switch se gana el nombre.
Bloquear Internet no es toda la tarea
Después de aquella prueba dejé de valorar esta función por cuántas palabras aparecían en el menú.
Standard.
Advanced.
Permanent.
Always-on.
Son controles útiles. Algunos sistemas operativos incluso ofrecen mecanismos propios para impedir conexiones cuando no hay una VPN activa. (Proton VPN)
Pero para mi uso había una pregunta anterior:
¿qué ocurre después de que el kill switch haga su trabajo?
Si la recuperación es lenta, cada cambio de red puede convertirse en un corte largo.
Si el tráfico vuelve antes que el túnel, el kill switch llega tarde.
Lo que yo quería era más sencillo:
detener la tarea cuando desaparece la protección y recuperarla en cuanto vuelve la ruta segura.
OnlydogVPN consiguió que esa secuencia resultara aburrida.
Y, para un mecanismo de seguridad, aburrido era exactamente lo que quería.
La VPN grande seguía teniendo ventajas reales
Mi proveedor anterior no perdió de repente sus puntos fuertes.
Tenía más ubicaciones.
Más controles avanzados.
Más años de pruebas públicas.
Más documentación.
Para quien quiera configurar reglas complejas, split tunneling, servidores específicos o distintos niveles de bloqueo, esa madurez puede ser muy valiosa.
La aplicación pequeña tiene menos ubicaciones y un historial independiente bastante más corto.
Pero mi comparación ya no era sobre amplitud.
Era sobre unos pocos segundos.
El proveedor grande había pasado la prueba fácil:
pulsar “Disconnect”.
Lo que decidió mi elección fue la prueba difícil:
cerrar el portátil, perder una red y abrirlo en otra sin que los datos se adelantaran a la VPN.
Entonces, ¿cuál es el mejor VPN con kill switch?
Para mí ya no es simplemente el que incluye esa frase en su lista de funciones.
Es el que maneja bien los fallos que realmente ocurren.
No probaría un kill switch solo desconectando la VPN manualmente.
Empezaría una transferencia sin importancia.
Apagaría el Wi-Fi.
Cambiaría al hotspot.
Suspendería y despertaría el portátil.
Y observaría una sola cosa:
¿el tráfico espera hasta que vuelve la ruta protegida?
Ese criterio cambió por completo mi comparación.
El proveedor grande me ofrecía un kill switch más visible y más opciones para configurarlo.
La alternativa pequeña hizo algo que terminó importándome más:
la subida se detuvo, la VPN volvió y la subida continuó.
El mejor kill switch no fue el que cerró Internet con más dramatismo, sino el que consiguió que mis archivos nunca se adelantaran al túnel.
Preguntas frecuentes sobre este problema
¿Cuál es la causa principal en este caso?
Mi primera reacción fue comprobar si había configurado mal la VPN. Era un proveedor grande que llevaba años usando. Tenía muchas ubicaciones, abundante documentación y controles bastante más avanzados que la mayoría de aplicaciones pequeñas.
¿Qué conviene comprobar primero?
Creé una carpeta con archivos sin importancia y empecé otra subida. En uno de los intentos, la aplicación de sincronización volvió a mover datos antes de que el túnel estuviera completamente restablecido.
¿Qué cambia la respuesta en la práctica?
La investigación TunnelVision mostró que ciertas rutas introducidas mediante DHCP pueden desviar tráfico fuera de algunas VPN basadas en enrutamiento, incluso mientras el túnel parece seguir activo. ( Leviathan Security )
¿Cuándo tiene sentido usar otro enfoque de VPN?
Esta vez el bloqueo funcionó mejor. Cuando desaparecía la VPN, desaparecía también Internet.