AllowedIPs es una lista de enrutamiento, no una regla de cortafuegos

La mayoría de la gente lee AllowedIPs como una lista de permisos, el conjunto de direcciones que pueden conectarse a un par, más bien como una regla de cortafuegos escrita para un túnel. No es eso. El campo es una tabla de enrutamiento que trabaja en ambas direcciones: elige un par para un paquete saliente y valida la fuente de uno entrante. Leerlo como una lista de acceso produce configuraciones que enrutan tráfico que nadie pidió.

Un campo, dos lectores: elección saliente y comprobación de fuente

En un cliente, los prefijos deciden qué destinos viajan a ese par y cuáles se quedan en la red ordinaria. Por eso una entrada para 0.0.0.0/0 captura todos los destinos IPv4, y por eso importar un perfil de túnel completo envía la navegación ordinaria a través de la máquina remota. Las entradas estrechas hacen lo contrario: enrutan solo las redes que enumeró y dejan todo lo demás donde estaba. La sección sobre enrutamiento de criptoclaves de la documentación de WireGuard expone ambas tareas en un solo lugar: la selección del par saliente y la validación de la fuente entrante.

En el servidor, el mismo campo describe qué direcciones de origen puede usar cada par. Es una comprobación criptográfica y no un filtro de paquetes: un paquete cuya fuente interna no coincida con la lista del par se descarta dentro de WireGuard antes de que lo vea cualquier cortafuegos del equipo. Ambas tareas comparten una sola lista, y por eso exactamente una lista copiada de otro sitio se comporta mal en un lugar que no consideró.

El bloque del cliente es donde empieza la mayor parte de esta confusión. Un túnel dividido nombra las redes remotas, y un túnel completo es el mismo campo con un prefijo predeterminado:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Ambas formas son completas por sí mismas, y son alternativas en lugar de pasos. La primera envía solo esas dos redes por el túnel; la segunda envía todos los destinos, con la entrada ::/0 añadiendo IPv6 al valor predeterminado IPv4. Elija la que elija, esos prefijos son toda la decisión de enrutamiento para ese par en cuanto wg-quick empieza a instalar rutas.

El concentrador necesita otra lista

Un concentrador enumera la dirección de túnel de cada cliente como prefijo de host, más cualquier red que esté realmente detrás de ese cliente. Copiar la lista amplia de un cliente a cada par del concentrador le dice al concentrador que muchos pares pueden usar las mismas direcciones como origen, y eso no es un plan de direccionamiento. El campo Endpoint pertenece a otra capa por completo: nombra la dirección y el puerto exteriores del par, nunca un destino dentro del túnel.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

El prefijo de host lleva la dirección del túnel y el prefijo de red lleva lo que está detrás del cliente, y ambos son necesarios. Sin el prefijo de host el concentrador no puede devolver el tráfico propio del cliente, y sin el prefijo de red la LAN que hay detrás queda inalcanzable; un par sin nada detrás solo recibe el prefijo de host.

Omitir la instalación de rutas deja un hueco

wg-quick, el ayudante que levanta una interfaz desde un archivo de configuración, instala direcciones de interfaz y rutas como parte de esa tarea. Establecer Table = off le dice al ayudante que omita el trabajo de rutas, lo que no instala sustitutos y no hace accesible la red privada. Cuando las rutas automáticas ya hacen el trabajo, nombrar los prefijos que necesita es la configuración más clara. Desactivar la gestión de rutas y dejar el sustituto sin escribir no es un diseño, es una omisión.

La herramienta básica wg se comporta de otra manera: configura la interfaz y nunca toca las rutas, así que una instalación construida directamente sobre ella necesita sus propios comandos de ruta. Las instrucciones escritas para una herramienta pueden parecer erróneas cuando se siguen con la otra. Un ping correcto también es una prueba débil, porque ejercita un solo camino en lugar de todos los caminos de aplicación que necesita.

DNS e IPv6 se deciden por separado

Compruebe la dirección del servidor DNS que anuncia el túnel y confirme que existe una ruta a esa dirección a través de los prefijos que eligió. Un ajuste de resolución no hace accesible el resolutor, y estrechar un túnel puede eliminar en silencio la ruta que solía llegar a él. Inspeccione IPv6 también por su cuenta, porque una división IPv4 correcta no dice nada sobre una ruta predeterminada IPv6 que aún apunta al enlace físico. Tres decisiones separadas pueden cambiar a la vez cuando edita un solo bloque de par.

Luego abra un recurso privado y un sitio web ordinario desde una configuración inicial conocida. Si el recurso responde y la navegación sigue saliendo por la conexión local, la división hace lo que pidió. Si la navegación se rompe en el mismo momento, el túnel tomó la ruta predeterminada y la lista de prefijos es donde hay que mirar.