Conjunto nftables alimentado por DNS hacia WireGuard: cómo funciona el traspaso
Una respuesta DNS puede alimentar un conjunto nftables, pero un conjunto no enruta nada. Siga los cuatro traspasos y las tres vidas útiles que deciden si el direccionamiento funciona.
Los nombres se resuelven en direcciones, y esas direcciones pueden acabar en un conjunto del cortafuegos que después influye en el enrutamiento, lo que hace posible el direccionamiento basado en el nombre sin proxy. La trampa es que cuatro componentes tienen que entregarse correctamente: el resolutor, el conjunto, el clasificador que marca un flujo nuevo y el par que lo transporta. Cada traspaso falla de forma distinta y cada uno mantiene su propio tiempo.
Trate el diseño como una cadena y no como una configuración. La pregunta en cada paso es qué componente posee la decisión y qué ocurre cuando falta su entrada.
Qué puede y qué no puede hacer la respuesta DNS
dnsmasq puede copiar direcciones de las respuestas a un conjunto nftables, lo que es una alimentación y no una decisión de enrutamiento. Esa opción, documentada en el manual de dnsmasq, indica la familia, la tabla y el conjunto, y su 4# inicial selecciona solo registros A, así que los destinos v6 necesitan su propia disposición. El conjunto debe existir ya, porque el resolutor añade elementos a algo que creó el propietario del cortafuegos. Nada en ese paso elige una interfaz, una tabla ni un par.
El cliente también tiene que usar ese resolutor para el nombre. Una aplicación con su propio DNS cifrado, o una respuesta en caché de antes de que existiera la política, se conecta sin crear ninguna entrada en el conjunto.
El conjunto es una entrada, no una ruta
Un elemento de un conjunto es una condición de coincidencia. Algo tiene que mirarlo, decidir que este paquete inicia un flujo nuevo y aplicar la política que envía el flujo por el túnel. En Linux eso normalmente significa una ruta de salida con capacidad de enrutamiento que puede poner una marca, una regla que envía los paquetes marcados a una tabla dedicada y una ruta en esa tabla que apunta al dispositivo WireGuard. La pertenencia por sí sola no instala nada de eso.
nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips
El par aplica una segunda comprobación de cobertura que la gente olvida. WireGuard cifra un paquete solo para un par cuyas direcciones permitidas incluyen el destino, así que una ruta de política hacia la interfaz no basta cuando la lista del par excluye ese prefijo. Mantenga la lista bajo el control del propietario del enrutamiento en lugar de confiar en la creación de rutas que haga el gestor.
Marcas, tablas y cobertura del par
Las marcas son un espacio de nombres compartido, así que tanto el valor como la máscara deben acordarse con cualquier otra cosa que las use. Una regla que envía tráfico marcado a una tabla dedicada necesita un resultado definido cuando esa tabla no tiene ninguna ruta coincidente, porque una búsqueda sin respuesta puede continuar a la regla siguiente y sacar el paquete por la interfaz física. Una ruta por defecto blackhole dentro de la tabla dedicada convierte esa fuga silenciosa en una caída visible. Lo que el diseño aún no puede hacer es cerrarse ante un fallo para un destino que nunca entró en el conjunto.
Los paquetes exteriores del propio túnel tienen que escapar del clasificador. Las herramientas de WireGuard ofrecen una marca de socket precisamente para eso, y usarla evita que la encapsulación se enrute de vuelta a la interfaz que está construyendo.
Pruebe cada vida útil por separado
Tres almacenes envejecen según tres calendarios: la caché del resolutor, los elementos del conjunto y la conexión rastreada. Pruébelos en ese orden y observe si cada uno se mueve cuando debe. Los comandos siguientes leen el resolutor, el conjunto, la tabla de conexiones y las reglas de política sin cambiar nada.
dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show
Una consulta nueva que añade un elemento demuestra que la alimentación funciona, mientras que un elemento viejo que sobrevive a su respuesta es un desajuste de vida útil que merece anotarse. Una conexión nueva en la tabla de conexiones con la marca esperada muestra que el clasificador se ejecutó, y una conexión antigua que conserva su marca original es comportamiento correcto y no un error. El listado de reglas responde si la búsqueda de política existe, que es una pregunta distinta de si coincidió. Lea las cuatro salidas en ese orden y el traspaso que falla se delatará solo.
Cuando el requisito es que un nombre concreto use siempre un solo camino, un conjunto alimentado por DNS no puede demostrarlo, porque las direcciones compartidas también llevan otros nombres. Un proxy o un mecanismo a nivel de aplicación es la herramienta para esa garantía.