¿Corte de emergencia o acceso a la LAN? Dos respuestas para WireGuard
El cliente de Windows bloquea el tráfico no tunelizado cuando el perfil indica 0.0.0.0/0. Decida qué propiedad necesita y exprese el valor predeterminado en consecuencia.
El saludo inicial se completa, la navegación funciona y la impresora, el NAS y los hosts SSH locales desaparecen. En el cliente de Windows esto normalmente no es un fallo de enrutamiento en absoluto: un par cuyos prefijos permitidos incluyen el valor predeterminado literal activa Bloquear el tráfico no tunelizado, y esa opción se implementa como reglas de firewall que descartan los paquetes que salen por cualquier otra interfaz. La tabla de rutas sigue mostrando la subred local como enlace directo, y por eso el síntoma parece una mentira. Tres condiciones deciden qué hacer al respecto, y solo una tiene que ver con el enrutamiento.
Dos fallos llevan el mismo síntoma
El primer fallo es el modo de cierre seguro del cliente, y su firma es que todo lo que está fuera del túnel se detiene mientras el túnel funciona a la perfección. El segundo es un problema real de accesibilidad: una ruta que falta, una entrada que falta en el servidor para una subred detrás del cliente, o dos redes que comparten el mismo rango de direcciones. Ambos producen una máquina que puede navegar y no puede imprimir, y sus soluciones son opuestas, así que el diagnóstico debe llegar antes de la configuración.
La observación decisiva es si la subred local sigue presente en la tabla de rutas mientras se descarta el tráfico hacia ella.
Tres condiciones deciden la respuesta
Primero, ¿necesita esta máquina el cierre seguro? Si la respuesta es sí, un túnel que caiga debe detener el tráfico en lugar de dejarlo volver a la interfaz física, y ese requisito pesa más que la comodidad local. Segundo, ¿deben los dispositivos locales seguir siendo accesibles mientras el túnel está activo? La impresión, el almacenamiento en red y las consolas de gestión locales son los motivos habituales, y son requisitos legítimos, no excepciones por las que disculparse. Tercero, ¿expresa el perfil el valor predeterminado como el literal 0.0.0.0/0? Ese detalle es lo que activa las reglas del cliente, y es editable.
Responda esas tres preguntas por escrito antes de tocar un perfil, porque cada respuesta apunta a una configuración distinta.
Elija el cierre seguro y renuncie a la LAN
Si las fugas importan más que la accesibilidad local, conserve el valor predeterminado literal y deje Bloquear el tráfico no tunelizado activado. Es una posición coherente: la máquina se trata como un dispositivo que o está dentro del túnel o está sin conexión, y los servicios locales se alcanzan desde otro dispositivo o a través del túnel si el servidor los enruta. El coste es real y debería figurar en las notas de despliegue, en lugar de que lo descubra la persona que necesita imprimir.
Esta es la elección correcta para máquinas que manejan trabajo que no debe aparecer en una red de cafetería cuando el túnel se cae. Es un mal valor predeterminado para un portátil doméstico que también necesita el escáner.
Elija el acceso a la LAN y exprese el valor predeterminado de otro modo
Si los dispositivos locales deben seguir siendo accesibles, exprese la misma cobertura sin el prefijo predeterminado literal. Dos medios prefijos cubren todas las direcciones IPv4, el par equivalente cubre IPv6, y el cliente ya no inserta las reglas de bloqueo porque falta la cadena que busca.
[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820
Desmarcar esa casilla hace que el cliente escriba los mismos dos pares en el perfil, así que comparar el archivo generado con el bloque de arriba es una forma rápida de confirmar el mecanismo en lugar de adivinarlo. Se derivan dos consecuencias. La cobertura es idéntica, así que nada más del túnel cambia. La protección no es idéntica: sin las reglas, un túnel que cae deja la máquina usando su interfaz física, que es precisamente lo que evitaba el cierre seguro.
Compruebe a los otros dos sospechosos de todos modos
Una vez resuelta la cuestión del firewall, confirme que la subred local está realmente enrutada y que el extremo remoto conoce todo lo que hay detrás de este cliente. Un servidor que debe alcanzar una LAN detrás de un cliente necesita ese prefijo en la lista permitida del cliente en el concentrador; si lo omite, el concentrador no puede elegir un par para esas direcciones, y ninguna cantidad de configuración del cliente crea uno.
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0
La categoría de red importa más de lo que la gente espera: un adaptador de túnel recién creado clasificado como público cambia qué reglas se le aplican, y el resultado puede parecer un bloqueo de firewall en el extremo remoto. La impresión de rutas muestra si hay un valor predeterminado en absoluto, lo que separa un problema de política de una ruta que falta.
Luego pruebe tres cosas en una sola sesión: internet, un host local por dirección y un host a través del túnel. El saludo inicial solo demuestra que las claves coinciden, así que las tres pruebas son lo que demuestra la política. Si el host local sigue negándose con la opción desactivada, los sospechosos restantes son la ruta, la lista permitida del extremo remoto y la subred duplicada, en ese orden.