Por qué un kill switch corta el tráfico al cambiar de servidor
Por qué un kill switch bloquea el tráfico durante un cambio de servidor, qué hace el cliente en ese intervalo y cómo distinguir una pausa normal de un bloqueo atascado.
Eliges un servidor que parece más cercano, pulsas conectar y el navegador deja de cargar antes de que el túnel nuevo esté listo. El icono pasa a un estado de conexión y se queda ahí mientras cada pestaña agota el tiempo. Esa pausa suele ser el kill switch funcionando según su diseño: el tráfico queda bloqueado mientras el cliente no tiene túnel por el que enviarlo. Si la pausa es aceptable depende de lo que haga el cliente en esos segundos y de si el bloqueo se levanta cuando dice que lo hace.
Qué hace el cliente entre dos servidores
Cambiar de punto final son varios pasos, no un interruptor. El cliente desmonta el túnel actual, actualiza sus reglas de bloqueo, resuelve y alcanza el nuevo punto final fuera del túnel, y después instala las rutas nuevas y levanta el bloqueo. El hueco que notas vive entre el primer paso y el último.
Aquí el orden importa más que la velocidad. Si las reglas de bloqueo entran antes de la excepción para el nuevo punto final, el cliente no puede completar el saludo y se queda en conectando hasta un tiempo de espera. Si la excepción es una copia de la dirección del servidor antiguo, el nuevo saludo parece cualquier otro paquete saliente y se descarta. Ambos casos se ven iguales desde el navegador, y por eso un cambio que se recupera a los seis segundos y uno que nunca se recupera pueden compartir la causa.
El nuevo punto final necesita un agujero en el bloqueo
Para construir el túnel, el cliente debe enviar paquetes a la dirección y el puerto del servidor nuevo por la interfaz física, por ejemplo UDP 51820 en un perfil típico de WireGuard o 1194 y 443 para OpenVPN, sea lo que sea lo que especifique tu propio perfil. Ese tráfico no está dentro del túnel que está a punto de crear, así que un bloqueo de todo el dispositivo se lo traga salvo que exista una regla de permiso que encaje.
Los perfiles basados en nombre de host añaden un segundo requisito: la consulta en sí. Si el cliente resuelve el punto final antes de que suba el bloqueo, puede usar una dirección en caché, pero cuando el perfil rota las direcciones o la entrada de la caché se queda vieja, el saludo va hacia una dirección que la regla de permiso no cubre. IPv6 lo hace visible, porque un punto final de doble pila puede publicar tanto un registro A como un AAAA, y una regla de permiso que solo cubre la dirección v4 deja al cliente reintentando contra una dirección v6 bloqueada.
Los nombres de las opciones y los valores por defecto cambian según el cliente y la versión, así que lee la lista documentada del tuyo en lugar de adivinar a partir de capturas de pantalla. La referencia de ajustes de OpenVPN Connect en openvpn.net/connect-docs/app-settings-windows es un ejemplo de cómo un cliente describe sus opciones de bloqueo y de túnel dividido.
Fail-closed es una máquina de estados, no un interruptor
La mayoría de los clientes expresan el bloqueo como política de cortafuegos en tres estados: túnel arriba, con el tráfico pasando por el túnel y sin bloqueo; túnel abajo, con el bloqueo activo; y transición, con el bloqueo activo más excepciones temporales para el punto final. En el tercer estado viven los errores, porque tiene que cambiar dos veces en un par de segundos, y no salir de él se ve exactamente como un bloqueo permanente.
El mecanismo cambia según la plataforma, y el fallo también. Los filtros de Windows Filtering Platform llevan pesos, así que un filtro de bloqueo que supera tu permiso sigue descartando paquetes aunque el permiso exista, y los filtros que deja un proceso de cliente muerto pueden mantener la máquina sin conexión después de que la aplicación desaparezca. Los clientes de macOS suelen escribir reglas pf en un anchor, donde el orden de las reglas y las decisiones rápidas deciden qué regla se aplica. Los clientes de Linux suelen gestionar una cadena nftables o iptables con política drop y permisos explícitos para el punto final, la interfaz del túnel y el loopback. La VPN siempre activa de Android con la opción de bloquear conexiones sin VPN es la más estricta del grupo, porque el sistema aplica el bloqueo a todo el dispositivo y no por aplicación.
WireGuard necesita su propia nota, porque AllowedIPs es un selector de enrutamiento, no un bloqueador. Decide qué destinos entran en el túnel; no hace nada para impedir que un paquete que aún no tiene túnel salga por Wi-Fi. En una configuración solo con WireGuard y sin regla de cortafuegos, el kill switch es en realidad la ausencia de una ruta, y tras un saludo descartado puede salir un paquete real por la interfaz física.
Mide el hueco en lugar de mirar el icono
Vigila los paquetes, no la luz de estado. En Linux, lanza un ping lento contra una dirección pública en una terminal y captura el puerto de transporte del túnel en la interfaz física en otra:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Cambia de servidor en el cliente mientras ambos corren. Tres cosas importan: cuánto tiempo se detienen los ping, si la captura muestra el saludo llegando al nuevo punto final y si el tráfico vuelve antes o después de que el estado del cliente pase a conectado. Si el hueco de los ping termina primero, o el bloqueo se levantó pronto o el túnel ya está arriba antes de que el indicador lo admita. Si el hueco termina más tarde, el indicador es optimista.
En Windows, netsh wfp show state escribe una instantánea en la que puedes buscar filtros de bloqueo que siguen presentes mientras el cliente afirma estar desconectado. En macOS, sudo pfctl -sr lista las reglas cargadas y su orden. Combina cualquiera de las instantáneas con el registro propio del cliente; la línea de tiempo de tu ping te dice si el bloqueo terminó tarde o no terminó nunca.
Apagón normal frente a bloqueo atascado
Algo de interrupción es el propósito de la función, así que haz triaje antes de cambiar cualquier ajuste:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Si acabas en la segunda o la quinta fila, no desactives el kill switch para probar, porque eso convierte un error de enrutamiento en una fuga. Reinicia el servicio del cliente, o reinicia la máquina donde los filtros sobreviven a la muerte del proceso, y mira si el bloqueo se despeja. Si se despeja, el fallo está en la limpieza durante el cambio y no en el bloqueo.
Antes de tu próximo cambio, confirma cuatro cosas: el permiso del punto final cubre cada familia de direcciones que resuelve tu perfil, el registro del cliente muestra la transición completada, tu prueba de ping mide el hueco y no el icono, y cerrar el cliente restaura la conectividad normal. Un kill switch que aguanta durante el cambio y suelta después hace su trabajo. Uno que suelta pronto, o nunca, merece depurarse.