Kill switch de VPN sin magia: cómo el núcleo del SO interrumpe el tráfico y protege tu privacidad

Introducción: ¿para qué sirve un kill switch de VPN en 2026?

Objetivos y realidad: qué protegemos realmente

Una pregunta sencilla pero con mucha importancia: ¿qué estás dispuesto a perder en un segundo sin VPN? ¿Tu dirección IP, el historial de consultas, los datos de tus aplicaciones? En 2026, cuando las apps sincronizan todo y los navegadores mantienen decenas de conexiones en segundo plano, el único seguro confiable es el kill switch de VPN. Hace algo radical: cuando el túnel se cae, bloquea todo el tráfico sin excepción. Sin "quizás", sin "probablemente resistirá". Apaga todo excepto el tráfico que pasa por la interfaz segura. ¿Parece simple? En realidad, bajo el capó hay un baile muy sofisticado entre el núcleo del SO, las tablas de enrutamiento, el marcado de paquetes, los controladores y las reglas del firewall.

Por qué es crítico justo ahora

Hoy los riesgos han aumentado. Cámaras del hogar, correo en la nube, mensajeros súper sensibles, billeteras de criptomonedas... Todo se conecta solo y todo el tiempo. El túnel se sacude un instante y puede suceder una fuga DNS o un endpoint de API puede enviar la IP real. Sí, solo un segundo. Hemos visto casos: actualización del controlador de red en Windows 11 24H2, microcuellos en Wi‑Fi, cambio de red en notebooks — y listo. El kill switch no negocia, actúa: corta. Y mantiene el control hasta que el túnel se estabilice.

En resumen: qué hace el kill switch

El kill switch no es un botón para "apagar internet". Es un conjunto de reglas integradas en la pila de red y el firewall del sistema que aseguran que solo los paquetes que van a través de la interfaz VPN (tun, tap, utun, wg, ikev2) puedan salir a la red; los paquetes que evadan esto se descartan temprano. También controla el DNS: la resolución va por VPN y los resolutores locales fuera del túnel están prohibidos. Y sí, todo esto debe funcionar a nivel del núcleo del SO. Si no, se generan condiciones de carrera y tu privacidad se echa a perder.

Cómo funciona el kill switch a nivel del núcleo: anatomía de la pila de red

Enrutamiento, sockets y hooks: dónde se interceptan los paquetes

En el núcleo del SO los paquetes pasan varias etapas: creación del socket por la aplicación, selección de ruta, aplicación de reglas de firewall, procesamiento por la interfaz, envío. El kill switch se coloca estratégicamente en dos sitios: en las tablas de enrutamiento (para que toda la ruta "por defecto" apunte al túnel) y en el firewall (para descartar inmediatamente todo lo que no esté marcado como "a través de VPN"). Esta doble capa previene condiciones de carrera: si la ruta cambia, el firewall lo cubre; si el firewall aún no reconoce la interfaz, la ruta no permitirá que el tráfico se escape.

Capa de núcleo en Windows: WFP y filtros NDIS

En Windows el trabajo pesado lo hace Windows Filtering Platform (WFP). El cliente VPN instala un controlador callout o usa capas del sistema, filtra en niveles de la pila de transporte y red, marca el tráfico de la interfaz VPN y bloquea todo lo demás. Además, se configuran perfiles de firewall con reglas que bloquean salidas salvo por la interfaz VPN. En la pila NIC pueden entrar controladores NDIS LWF, pero en 2026 la tendencia es WFP sin controladores adicionales para evitar romper la compatibilidad con Windows 11 24H2 y HVCI.

Linux: netfilter, nftables y cgroup-bpf

En Linux el kill switch suele construirse sobre netfilter. La recomendación actual es nftables (núcleos 5.10+ idealmente 6.x): creamos cadenas output/forward con política drop, permitiendo solo paquetes con marca o por una interfaz específica (por ejemplo, wg0). Además, policy routing: el tráfico con fwmark va por una tabla de enrutamiento separada con ruta por defecto hacia el túnel, y lo demás a un agujero negro. Para configuraciones avanzadas existe cgroup-bpf (BPF_CGROUP_INET_EGRESS): filtrado por procesos para que, por ejemplo, el ssh del administrador pueda saltarse el kill switch para depuración mientras que el resto no. Flexible y rápido.

macOS: Network Extension y PF

En macOS nos apoyamos en Network Extension (NE) y el Packet Filter (PF) del sistema. El cliente NE maneja el túnel (interfaz utun) y PF, mediante anclas, implementa políticas restrictivas: bloquea todas las salidas salvo por la interfaz utunX y servicios permitidos en el túnel. El DNS se gestiona con NEAppProxyProvider o ajustes del resolutor para que las consultas salgan vía VPN. En macOS 14+ Apple mejoró la estabilidad de NE, y en 2026 la mayoría de clientes maduros mantienen reglas PF robustas sin conflictos al cambiar redes.

Enrutamiento y tablas: la manera fácil de arruinar o salvar la privacidad

Ruta por defecto como centro nervioso

Un error clásico: tener dos rutas por defecto — a la red física y al túnel. El SO elige la mejor según la métrica. Al reconectar, cambiar Wi‑Fi o despertar de suspensión, las métricas pueden variar y causar que parte del tráfico, especialmente consultas DNS rápidas, salga fuera del VPN. Un kill switch adecuado siempre apunta la ruta por defecto a la VPN y descarta todo lo demás, garantizando que la inserción de una interfaz física no restaure la ruta por defecto antigua.

Policy routing y fwmark: cirugía en Linux

En Linux la receta es sencilla y confiable. Se marcan los paquetes de las aplicaciones que deben ir por el túnel (o todos si la estrategia es total), se crea una tabla de enrutamiento separada con ruta por defecto hacia el túnel, y en la tabla principal no hay ruta por defecto o apunta a blackhole. Así, incluso si la interfaz cae, el tráfico sin túnel no encuentra salida. Este esquema es sólido, especialmente combinado con nftables, que permite definir condiciones finas: interfaz, grupo de procesos, uid, puertos, dominios mediante sets y maps.

Windows: métricas y perfiles de interfaz

Windows prefiere la "independencia". Por eso fijamos las métricas de interfaces: VPN tiene la métrica más baja y las físicas más altas. Configuramos reglas de firewall para permitir solo tráfico saliente por la interfaz VPN (basado en InterfaceAlias o InterfaceType). Si el túnel se cae, el firewall bloquea todo salvo, tal vez, direcciones locales 127.0.0.0/8 y link-local para mantener la estabilidad del SO. En 2026 muchos clientes implementaron corrección automática de métricas y recuperación de reglas tras reiniciar el servicio BFE, que antes era su talón de Aquiles.

macOS: rutas pegajosas y anclas PF

En macOS funciona bien la configuración con PF: se crea un ancla con política por defecto bloqueante, permitiendo solo reglas donde la interfaz sea utunX. Las rutas pegajosas para VPN se configuran automáticamente vía NE y PF no permite que ningún "filter" se escape. Importante: tras suspendido y cambio de redes hay que actualizar el número de la interfaz utun, que puede cambiar. Los clientes inteligentes hacen esto solos, capturando eventos vía NE.

Reglas de firewall: cómo se construye exactamente el bloqueo

Linux: nftables en lugar de iptables

En 2026 iptables sigue existiendo, pero está obsoleto. Nosotros creamos la tabla inet vpn, las cadenas input, forward y output, con política drop en output. Permitimos conexiones established, relacionadas; interfaz wg0 (o tun0); DNS sobre wg0; opcionalmente localhost. Se puede añadir una regla: si interface != wg0, drop, sino accept. Para mayor seguridad, en la tabla route de nftables se puede manejar el tráfico cuando el interfaz está caído, aunque suele bastar con output estricto.

Windows: AdvFirewall y WFP

El escenario es crear una regla "Block All" para tráfico saliente y luego una excepción que permita la interfaz VPN. En GUI es lento y tedioso, por eso usamos PowerShell. Añadimos una regla New-NetFirewallRule con Direction=Outbound y Action=Block para todos los perfiles, luego excepciones Allow por InterfaceAlias. Los clientes modernos van más allá: implementan WFP callouts que descartan paquetes antes de llegar a la pila TCP y marcan paquetes VPN garantizando que reglas Allow circunstanciales no afecten. Es más rápido y fiable que reglas de usuario.

macOS: PF con anclas y estados

PF domina la escena: set block-policy drop; set skip on lo0; anchor vpn-killswitch donde en la ancla hay reglas que permiten solo salida por utunX con estado y bloquean todo lo demás. El manejo stateful hace la experiencia agradable para las aplicaciones. Además, protección DNS: bloquear udp/53 en todas las interfaces salvo utun. Si usas DoH dentro del túnel, perfecto, bloquea el 53 UDP globalmente dejando tcp/443 por utun.

DNS: un frente aparte

DNS es el canal más traicionero para fugas. La regla es simple: resolución solo por VPN o nada. En Linux redirigimos resolv.conf a un resolutor local que solo escucha en la interfaz tun o usamos systemd-resolved con enrutamiento de dominios. En Windows activamos "Block outside DNS" (OpenVPN tiene esta opción) y el firewall bloquea udp/53 fuera del VPN. En macOS definimos DNS scoped vía NE y bloqueamos 53 fuera de utun con PF. Y sí, revisa clientes DoH (los navegadores pueden engañar): deben usar la pila del sistema o un endpoint DoH accesible solo a través del túnel.

Cómo los clientes VPN implementan kill switch: análisis práctico

WireGuard: marcas y AllowedIPs

WireGuard es rápido, simple y transparente. Con wg-quick el kill switch se consigue con dos conceptos: AllowedIPs abarca todo el tráfico (0.0.0.0/0, ::/0) y tablas de enrutamiento más fwmark fuerzan que el tráfico pase por la interfaz wg. Si la interfaz falla, las políticas nftables bloquean la salida. Opcionalmente se puede activar Table=off y configurar policy routing manualmente para más flexibilidad y previsibilidad. En móviles es imprescindible recrear la interfaz al vuelo y conservar las reglas drop.

OpenVPN: bloqueo fuera del túnel y rutas

OpenVPN lleva tiempo en esto. En Windows el parámetro block-outside-dns cierra el hueco DNS y client-config-dir con scripts route-pre-down ayuda a manejar rutas correctamente. En Linux la buena práctica es usar nftables para soltar todo salvo tun0. En macOS combinamos PF con launchd para aplicar reglas de forma atómica. En reconexiones activas es vital que el bloqueo esté activo antes de levantar el descriptor TUN. Por eso, clientes avanzados primero bloquean todo el tráfico, luego levantan el túnel y por último abren tráfico por la interfaz.

IKEv2/IPsec: pilas del sistema y selectores

IKEv2 en Windows y macOS usa pilas IPsec del sistema. Aquí el kill switch suele implementarse a nivel OS: limitando salidas por la interfaz del adaptador virtual, prohibiendo 0.0.0.0/0 al exterior y definiendo explícitamente rutas para split-tunneling. Si la política es no-split, todo va por el túnel y las demás interfaces tienen bloqueo global. En Linux strongSwan integra políticas xfrm con nftables y policy routing, haciendo que el tráfico que no encaje en selectores se queme automáticamente.

Clientes híbridos 2026: eBPF, NE y WFP

Tendencia 2026: menos hacks y más integración. En Linux — eBPF para filtrado a nivel de cgroups, en macOS — Network Extension con configuración PF pulida y monitoreo de eventos, en Windows — WFP sin trucos de usuario. Además, telemetría de estado: si la interfaz está inestable, el cliente no cambia rutas mil veces por segundo, usa retardos y transacciones para evitar ventanas de fuga.

Configuración paso a paso: Windows, Linux, macOS

Windows 11: firewall y rutas

Plan básico: primero activamos el bloqueo total de salida, luego añadimos excepciones para la interfaz VPN. En PowerShell sería: crear regla bloqueando salida en todos los perfiles; permitir InterfaceAlias de tu VPN (ejemplo "WireGuard Tunnel" o "Ethernet 5" según driver); ajustar prioridades con Set-NetIPInterface desactivando AutomaticMetric y asignando InterfaceMetric bajo para VPN. Resultado: si el servicio VPN cae, el tráfico no sale porque el bloqueo está activo. Consejo útil: regla separada para loopback para evitar que algunas apps se quejen.

Linux (nftables + policy routing)

Procedimiento: crear tabla inet vpn, cadena output con política drop. Permitir: oifname "wg0" o "tun0", conexiones established, localhost. Marcar tráfico con fwmark (ejemplo 0x1), añadir ip rule lookup 100 para fwmark 0x1, y en tabla 100 ruta por defecto hacia VPN. En tabla principal no hay ruta por defecto o apunta a blackhole. Opcional: cgroup-bpf para whitelists de servicios de administración. Para comprobar: ping, curl con bind a la interfaz y tráfico del sistema (NTP, sincronización horaria) todo debe pasar por el túnel.

macOS (PF + NE)

Pasos: lanzar cliente VPN basado en Network Extension, identificar interfaz utunX. En /etc/pf.conf crear ancla "vpn-killswitch" con política block drop y skip en lo0. En la ancla definir reglas que permitan solo salida por utunX. Activar con pfctl cargando la ancla. En el cliente configurar DNS scoped para que la resolución no escape. Después de suspender, capturar eventos y actualizar utunX en reglas si cambió el número. Esta configuración previene fugas incluso con cambios abruptos de Wi‑Fi.

Gestión de aplicaciones y excepciones

A veces hacen falta excepciones: actualizaciones del SO, agentes corporativos, VoIP fuera de VPN. Hazlas conscientemente. En Linux usa cgroups con política específica. En Windows aplica callouts WFP o reglas por AppPath y servicios. En macOS, NEFilterDataProvider con reglas por app. Mantén un log completo de quién sale y por qué. El kill switch es duro por defecto; las excepciones son puntuales y controladas.

Verificación y pruebas: cómo asegurarte de que el kill switch realmente funciona

Comprobaciones rápidas de IP y DNS

1) Desactiva VPN y comprueba que no hay internet. Debe ser "no". 2) Activa VPN y entra a una web comprobadora de IP: debe mostrar la IP del proveedor VPN. 3) Rompe intencionadamente el túnel: para el servicio, desactiva la interfaz. Internet debe desaparecer. 4) Verifica DNS: realiza consultas y asegura que pasen por la interfaz VPN. Si la red sigue abierta al caer, el bloqueo tiene fugas.

Consulta de rutas e interfaces

Windows: route print, Get-NetRoute, Get-NetIPInterface para ver métricas, rutas por defecto, NextHop en VPN. Linux: ip route, ip rule, ip -4 -6 route show table 100 para revisar políticas. macOS: netstat -rn, scutil --dns para checar rutas por defecto y DNS scoped. Baja el túnel y revisa: desaparece la ruta por defecto y no aparece ninguna ruta externa sin bloqueo de firewall. Si aparece, ajusta la política.

Sniffer básico

Linux: tcpdump -i any not host dirección_VPN — no deben salir paquetes. Windows: pktmon integrado o Wireshark con filtro not ip.addr==VPN_IP y not interface==VPN. macOS: tcpdump -i en0 o en1 — silencio total si el túnel está caído. El sniffer es el mejor termómetro: si hay paquetes fuera, hay fuga.

Prueba de carrera y sleep-wake

Escenario avanzado pero revelador: descargas activas, videollamada, múltiples pestañas, luego duerme y despierta notebook, cambia Wi‑Fi por punto móvil, notebook rápido en dock. Un kill switch bien hecho sobrevivirá a todo sin filtrar un solo paquete fuera del túnel. Si ves breves escapes en logs, refuerza reglas a nivel núcleo y reduce ventanas entre levantar y quitar reglas en reconexión.

Errores comunes y casos reales

Doble ruta por defecto y métricas

Hemos visto el error clásico: en Windows la métrica para la interfaz física más baja que la de VPN. Tras actualizar drivers, las métricas "se optimizan automáticamente" y tráfico escapa. Solución: fija las métricas manualmente y controla las reglas de firewall donde el InterfaceAlias está explícito para VPN.

Fugas DNS por DoH

Los navegadores usan DoH con su propia lista de resolutores. Bloqueas 53/udp — bien, pero el navegador sigue enviando DoH por 443 fuera del túnel. Solución: fuerza que la app use el resolutor del sistema con política y en firewall permite DoH solo con oif=VPN. En Linux útil usar nftables sets para IPs de proveedores DoH autorizados y bloque global para lo demás.

Split-tunnel y factor humano

Las políticas corporativas a veces permiten que parte del tráfico vaya directo. Riesgo alto: una red mal configurada en excepciones puede perforar la privacidad. Enfoque: mínimo split necesario con auditoría clara. Listas blancas de dominios preferible resolverlas por VPN y luego liberar IPs concretos solo si es estrictamente necesario.

Redes móviles y NAT64

En LTE/5G a veces NAT64 y mecanismos puente hacen que parte del tráfico IPv6 trate de pasar fuera si solo filtras IPv4. Asegúrate que el kill switch cubra IPv4 e IPv6. En AllowedIPs pon 0.0.0.0/0 y ::/0. En nftables tablas inet para cubrir ambos stacks simultáneamente.

Técnicas avanzadas y tendencias 2026

eBPF en Linux: filtrado por procesos

Con eBPF nos alejamos de bloqueos globales rígidos hacia políticas inteligentes. cgroup-bpf permite decir: por defecto procesos no salen fuera de wg0, pero servicio "actualización de hora" tiene permitido solo ese rango IP. Esto reduce problemas cuando algo crítico falla con política estricta y hace el kill switch más amigable sin sacrificar seguridad.

Windows: WFP con telemetría de estado

Clientes modernos usan WFP callouts que no solo descartan, sino que "entienen" el estado del túnel. Si el túnel no está activo — bloqueo duro; si está autorizado — permiten tráfico por interfaz. Esto reduce las ventanas donde reglas aún aplican pero el tráfico ya salió. Además generan logs detallados: qué proceso intentó salir, dónde, qué protocolo — invaluable para investigaciones.

macOS: NE + PF con actualizaciones atómicas

En 2026 muchos clientes usan actualizaciones atómicas de anclas PF: generan nuevo config, lo cargan en un ancla nuevo y hacen un swap limpio. Sin caídas ni errores de sincronización. Además usan capacidades NE para monitorear estado de redes: cambiaron Wi‑Fi — cliente actualiza interfaz y DNS scoped al instante.

Protección contra canales "ocultos"

Algunas apps usan QUIC, uTP, proxies integrados para "optimizar" red. El kill switch debe considerarlos potenciales escapes. La solución: bloquear todo el tráfico saliente en interfaces que no sean VPN según estado del socket, no por puertos; solo se permite si coinciden interfaz o marca. Así la ofuscación por puerto no permite evadir las políticas.

Lista de verificación para implementar: pasos que no debes saltarte

Diseño de la política

Define si el túnel será total o parcial. Lista de excepciones si son inevitables. Requisitos DNS (DoH, DoT). SOs y versiones soportadas (Windows 11 24H2+, kernel Linux 6.x, macOS 14+). Escenarios de suspensión, roaming entre Wi‑Fi y Ethernet, red móvil.

Implementación técnica

Windows: reglas AdvFirewall + WFP; Linux: nftables + policy routing + eBPF si hace falta; macOS: NE + anclas PF. Elementos obligatorios: bloquear todo salvo salida por interfaz VPN; prohibir DNS fuera de VPN; ruta por defecto por túnel; agujero negro para tráfico cuando interfaz falle.

Pruebas y monitoreo

Sniffer, pruebas de estrés en reconexiones, registro de procesos, verificación IPv6, chequear DoH, probar apps "problemáticas" (launchers de juegos, torrents, agentes corporativos). Monitoreo: alertas para aparición de ruta por defecto fuera de VPN, notificaciones de caída de interfaz, telemetría de intentos de bypass.

Operación y reversión

Prepara una "clave de emergencia": cómo quitar el kill switch si el cliente VPN falla y necesitas internet urgente. En Windows un script para eliminar reglas, en Linux un archivo con nft flush ruleset y respaldo de configuración, en macOS pfctl -d con cuidado y restauración de perfil NE. Haz esto solo en escenarios offline o con autorización para no comprometer seguridad.

Comandos prácticos y ejemplos: resumen compacto

Windows PowerShell

Agregar bloqueo total de salida: New-NetFirewallRule -DisplayName "Block All Outbound" -Direction Outbound -Action Block -Profile Any. Permitir para interfaz VPN: New-NetFirewallRule -DisplayName "Allow VPN Outbound" -Direction Outbound -Action Allow -InterfaceAlias "Nombre_Interfaz_VPN" -Profile Any. Fijar métricas: Set-NetIPInterface -InterfaceAlias "Nombre_Interfaz_VPN" -AutomaticMetric Disabled -InterfaceMetric 5; para físicas 50 o más.

Linux nftables

Crear tabla y política: add table inet vpn; add chain inet vpn output { type filter hook output priority 0; policy drop; }; add rule inet vpn output oifname "wg0" accept; add rule inet vpn output meta oifname "lo" accept; add rule inet vpn output ct state established,related accept. Policy routing: ip rule add fwmark 0x1 table 100; ip route add default dev wg0 table 100. En tabla principal sin ruta por defecto o con blackhole default dev lo.

macOS PF

En pf.conf: set block-policy drop; set skip on lo0; anchor "vpn-killswitch"; en el ancla: block out on ! utunX from any to any; pass out on utunX from any to any keep state; block out proto { udp, tcp } to port 53 on ! utunX. Activar: pfctl -f /etc/pf.conf; pfctl -E. Actualizar utunX al reconectar cliente.

Diagnóstico DNS

Windows: Resolve-DnsName con tracing; verifica que servidores de Get-DnsClientServerAddress pertenezcan a VPN. Linux: resolvectl dns y resolvectl status; asegúrate que la interfaz sea tun/wg. macOS: scutil --dns para ver resolutores scoped; servicios sistema deben referir utun.

Por qué a veces el kill switch no funciona "de repente" y cómo arreglarlo

Condiciones de carrera en reconexión

Si el cliente quita reglas antes de levantar el nuevo túnel, hay una ventana de milisegundos o segundos donde el tráfico sale. Solución: transacciones atómicas. Primero mantener bloqueo global, luego levantar túnel y después abrir reglas por interfaz. Solo así.

Servicios del SO con privilegios especiales

Antivirus, agentes corporativos, actualizaciones pueden saltarse reglas normales. Hay que capturarlos a nivel núcleo: WFP callout en Windows, cgroup-bpf en Linux, NEFilterDataProvider en macOS. Si no, un "servicio mágico" hará una brecha.

Incompatibilidad IPv6

Filtrar solo IPv4 es la mitad del trabajo. En 2026 IPv6 está en todas partes. Revisa ::/0, RA, SLAAC y bloquea salidas en la interfaz física para ambas familias. Tablas inet en nftables son tus aliados; PF y WFP también lo manejan.

Navegadores y pila de red propia

Algunos navegadores usan su propio stack DNS, QUIC, proxies. Desactiva "DNS-over-HTTPS siempre" si tu escenario no considera su túnel. Sino DoH escapará fuera. Mejor opción: DoH hacia tu resolutor dentro del VPN y bloqueo estricto del resto.

Resumen: cómo saber que tienes un kill switch "correcto"

Indicadores de una implementación madura

No hay internet cuando cae VPN. Ruta por defecto apunta al túnel. DNS solo por VPN. IPv6 considerado. Excepciones pocas, puntuales y loggeadas. Sniffer no detecta fugas. Suspensión, roaming, reconexión sin escapes.

Qué aporta en la práctica

Tranquilidad. Realmente. Cuando sabes que aunque la interfaz falle ningún byte sale sin protección puedes trabajar, ver videos, sincronizar archivos sin miedo a la "segundada" peligrosa. El kill switch es el seguro que no falla.

Call to action

Revisa tu configuración hoy. Corrige dobles rutas por defecto. Refuerza reglas. Bloquea DNS. Y confirma con logs: cuando VPN calla el tráfico también. Lo demás serán solo detalles.

FAQ: preguntas frecuentes sobre VPN kill switch

¿Se puede hacer un kill switch sin permisos de administrador?

De forma confiable — no. Necesitas permisos para cambiar rutas y firewall. Si no, es un juego, no seguridad.

¿En qué se diferencia un kill switch de solo "bloquear internet cuando se pierde VPN" en el cliente?

Un kill switch correcto vive en el núcleo y el firewall. Los bloqueos simples en la app llegan tarde y pierden condiciones de carrera. Hace falta WFP, nftables, PF.

Si tengo split-tunnel, ¿pierdo el sentido del kill switch?

No. Sigue bloqueando tráfico no autorizado, pero aumentan riesgos. El split es más complejo y requiere ajustes precisos.

¿Hay que bloquear IPv6 si el proveedor no lo da?

Sí. Las apps pueden crear sesiones IPv6 locales por otras redes. Bloquea ambos stacks.

¿Cómo asegurar que DoH no salga fuera del VPN?

Sniffer en la interfaz física y reglas firewall: permite DoH solo por interfaz VPN, el resto drop.

¿WireGuard tiene kill switch incorporado?

Casi. Si AllowedIPs=0.0.0.0/0, ::/0 y rutas bien configuradas. Pero sin firewall quedan ventanas en reconexión. Necesitas reglas drop fuera de wg.

¿Por qué al caer VPN sigo accediendo a la red local?

Así están configuradas las reglas. Permitir link-local y LAN a veces es necesario. Si quieres más duro, bloquéalos, pero podrías perder impresoras y compartidos.