Túnel dividido de WireGuard: configúrelo sin ruta predeterminada

Un túnel dividido se define por lo que deja fuera, y WireGuard toma esa decisión en un solo campo. AllowedIPs del par del cliente elige a la vez qué destinos pasan por el túnel y filtra qué direcciones de origen internas se aceptan, y wg-quick convierte la misma lista en rutas de host. Si la lista está mal, el túnel o se lo traga todo o no transporta nada.

Decida primero la lista de prefijos

Anote los destinos que deben usar el túnel antes de tocar ningún archivo de configuración. Subredes de oficina, un rango de base de datos, una red de gestión: cada uno es un prefijo con un motivo. Todo lo que no está en la lista se queda en la ruta física, y ese es todo el sentido del diseño.

Si la lista contiene 0.0.0.0/0 o ::/0, ha construido un túnel completo y debería decirlo, porque los modos de fallo y las expectativas de DNS son distintos.

Mantenga la lista lo bastante corta para que un revisor pueda contrastarla después con la tabla de enrutamiento.

Configuración del cliente: par, AllowedIPs, DNS

El bloque de interfaz del cliente contiene su propia dirección de túnel y su clave privada. El bloque de par contiene la clave pública del servidor, el extremo y los prefijos del primer paso:

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

AllowedIPs en el cliente es el conjunto de destinos remotos, no la dirección propia del cliente. La línea DNS solo surte efecto mediante la integración del resolutor de wg-quick, así que un host sin soporte de resolvconf o systemd-resolved la ignorará. PersistentKeepalive mantiene vivo un mapeo NAT y no hace falta en una ruta directa.

Comente cada prefijo con el servicio al que sirve, o la próxima edición será una conjetura.

Configuración del servidor: el punto de vista opuesto

En el servidor, la entrada de par representa al cliente, así que su AllowedIPs es la dirección de túnel del cliente, normalmente una /32. No es la subred de oficina. Copiar la lista del cliente en la entrada del servidor es el error más común del túnel dividido, y o bien amplía el acceso o bien rompe la comprobación de origen interno en el momento del handshake.

La dirección de interfaz del servidor y las rutas que necesita hacia la oficina son independientes de cualquier entrada de par.

Dos archivos, dos puntos de vista, un conjunto de prefijos repartido entre ambos.

Levántelo y lea las rutas

Inicie la interfaz con el gestor compatible y luego mire lo que ha instalado, no lo que pretendía. wg-quick deriva las rutas de AllowedIPs; si el perfil establece Table = off, no se instala nada y el enrutamiento es cosa suya. Lea la ruta de cada prefijo y confirme que apunta a la interfaz de WireGuard. Una lista de rutas vacía suele significar que el perfil aplicado no es el que ha editado.

Revise también los contadores de handshake, porque un par sin handshake tiene un problema de clave, extremo o accesibilidad, no de enrutamiento.

Escriba el comando exacto que utilizó, porque la siguiente persona lo ejecutará bajo presión.

Verifique ambos lados y luego anote la reversión

Pruebe una dirección privada, su nombre interno y un destino que debe permanecer directo. Si la dirección privada funciona y la directa ahora sale por el túnel, la lista de prefijos es demasiado amplia. Si el nombre falla mientras la dirección funciona, la línea DNS no ha surtido efecto. La reversión es un comando, y pertenece a la misma nota.

Tras una reconexión, confirme que las rutas siguen ahí, porque un gestor que vuelve a aplicar el perfil puede sustituir las rutas manuales.

Mantenga un solo propietario de la configuración, porque dos gestores que producen la misma interfaz acabarán discrepando. El manual de wg-quick documenta el comportamiento de rutas y DNS que ofrece.