El kill switch bloquea el servidor VPN antes de que fluya cualquier tráfico
Qué etapa bloquea un kill switch: la búsqueda del extremo, la ruta exterior, el camino de vuelta y las excepciones obsoletas de pares, con contadores en lugar de conjeturas.
Los kill switch fallan en una dirección que la gente no espera: están hechos para bloquear el tráfico mientras el túnel está caído, y los paquetes que construyen el túnel son ellos mismos tráfico. Ese es el error completo. Un conjunto de reglas que descarta todo lo que no sale por el túnel también descarta el handshake que debería levantarlo, así que el cliente reintenta en bucle y el error se atribuye a la etapa que se comprueba primero. Antes de ampliar un cortafuegos, averigüe cuál de las tres etapas se está denegando: la búsqueda del nombre, el paquete exterior hacia el par o la respuesta que vuelve.
Cómo dependen el uno del otro el túnel y su propio transporte
Lea un cliente VPN como dos estados de red que comparten una sola ruta de socket. Antes de que exista el túnel, el cliente abre un socket en el adaptador físico y envía tramas cifradas a la dirección y el puerto del par. Solo cuando ese intercambio tiene éxito crea el dispositivo de túnel e instala las rutas. Un kill switch es una política sobre el segundo estado, escrita con tal amplitud que se aplica a ambos.
Las reglas basadas en la interfaz son la forma habitual: acepte lo que sale por tun0 o wg0, descarte el resto del camino de salida. Esa formulación no puede eximir la propia conexión del cliente con el servidor, así que una implementación correcta añade esa excepción de forma explícita, y usted también lo hace cuando escribe reglas a mano. Las reglas por aplicación en Windows y macOS evitan parte de esto al coincidir con un proceso en lugar de una interfaz, pero el proceso sigue teniendo que salir antes de que exista el túnel.
Tres etapas, en el orden en que ocurren
La primera etapa es la resolución. Cuando el perfil guarda un nombre de host en lugar de una dirección literal, el cliente necesita una respuesta DNS antes de poder enviar nada. Un perfil que apunta el DNS al resolutor del túnel crea un bloqueo: solo se puede llegar al resolutor a través del túnel que la consulta debería habilitar. Resolver fuera del túnel, o fijar el extremo a una dirección, elimina la ambigüedad.
La segunda etapa es el paquete exterior, que tiene que sobrevivir al enrutamiento y luego al cortafuegos, en ese orden. wireguard-tools se encarga de la mitad de enrutamiento para WireGuard marcando sus propios paquetes y añadiendo una regla de política para que se salten la ruta por defecto que acaba de instalar; la página de manual de wg-quick describe esa regla y la tabla que utiliza. Reconstruya ese enrutamiento a mano, o deje que una segunda herramienta reescriba las reglas, y los paquetes marcados pueden enviarse de vuelta al túnel que deben establecer.
La tercera etapa es el camino de vuelta. Un handshake sin respuesta no es prueba de un descarte de salida; es igual de compatible con una regla de entrada del servidor o con un dispositivo NAT que olvidó la correspondencia. Separe eso antes de tocar al cliente.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Los clientes registran el síntoma que detectan, no la etapa que falló, así que la tabla suele ser más rápida que el registro.
Los contadores deciden más rápido que los registros
En Linux, nft list ruleset o iptables -vnL OUTPUT imprime un contador de paquetes por regla. Conéctese una vez, déjelo fallar y vuelva a leer los contadores. Una regla cuyo contador se ha movido es una regla que golpeó el handshake; si no se ha movido nada en ningún sitio, el paquete nunca llegó al cortafuegos. He visto a un conjunto de reglas descartar su propio handshake, y solo los contadores lo dijeron.
Para separar nunca llegó al cortafuegos de nunca salió del host, observe la propia interfaz. ip -s link show dev wlan0 informa de los paquetes enviados, y tcpdump -ni wlan0 udp port 51820 muestra las tramas. Si se queda plano mientras el cliente reintenta, la avería está por encima de netfilter: falta una ruta del par, una regla de política apunta a un dispositivo que aún no existe, o hay un error de socket que el cliente se traga.
Pruebe las excepciones contra direcciones de documentación como 203.0.113.10, para que un descuido no pueda sondear el host de otra persona.
Una excepción de extremo obsoleta se lee como una caída del servidor
La versión más engañosa aparece después de que cambie la dirección del par: un servicio de direcciones dinámicas la ha movido, el host se ha reconstruido o la dirección de salida de su red es distinta. La excepción sigue nombrando la dirección antigua, así que los paquetes hacia la nueva caen en la regla de descarte. La misma configuración funcionaba ayer, y por eso la gente empieza diagnosticando el servidor.
Un nombre de host dentro de una regla de cortafuegos no le salva. En nftables el nombre se resuelve al cargar el conjunto de reglas, así que fija la dirección que existía en ese momento y se vuelve obsoleto como una literal. La solución duradera es actualizar la excepción cuando cambia el extremo y mantenerla estrecha: una dirección de par, un puerto de transporte. Un rango lo bastante amplio para sobrevivir a un cambio de dirección también lo es para dejar salir tráfico no relacionado.
Cuando el kill switch se ejecuta en el host del servidor
La misma dependencia existe en el otro extremo, y allí es más fácil pasarla por alto. Si la máquina que actúa como su servidor VPN también ejecuta un cliente de escritorio con kill switch, o un perfil de cortafuegos copiado de un portátil, sus reglas de descarte se aplican al servicio que termina los túneles. Las respuestas al handshake de un cliente se descartan, así que todos los clientes no pueden conectar mientras el servidor parece sano y su interfaz de túnel queda sin uso.
Ese host necesita tres aceptaciones estrechas antes del descarte: el puerto de escucha en la interfaz física, la interfaz de túnel para el tráfico descifrado y el reenvío desde el túnel hacia lo que los clientes deben alcanzar. Lea el conjunto instalado con nft list ruleset, iptables -S, o pfctl -sr antes de cambiar nada, y recuerde que un conjunto de reglas guardado sobrevive a un reinicio, así que un error allí sobrevive al proceso que lo hizo.
Orden de recuperación que mantiene la máquina cerrada
Trabaje de dentro hacia fuera desde el perfil. Lea la dirección y el puerto del par que usa el cliente, confirme que el nombre de host se resuelve sin el túnel y luego añada una excepción para esa dirección y puerto solo en el adaptador físico. Vuelva a conectar y observe el contador de envío; un handshake completado es la señal de que la segunda etapa está arreglada.
Deje el resto de la política de descarte en su sitio mientras prueba. Una comprobación inocua es intentar una conexión a una dirección de documentación no relacionada y confirmar que sigue agotando el tiempo, lo que muestra que el kill switch funciona y no que está desactivado. Apriete la excepción cuando el túnel sea estable, y no deje un permiso permanente de todo para el binario del cliente solo porque es cómodo.
Si el túnel sube y la aplicación sigue fallando, las etapas restantes no son esta: el DNS dividido, la MTU y el enrutamiento por aplicación producen cada uno un túnel conectado con tráfico roto, y cada uno tiene una primera comprobación distinta.