Grupos de pares de WireGuard en el concentrador: propiedad del origen más política

Un concentrador que ejecuta WireGuard puede mantener separados los grupos de pares sin una interfaz ni una tabla de rutas aparte por grupo. Dos mecanismos hacen el trabajo, y confundirlos es la razón habitual de que una política parezca correcta y no haga nada. Una capa decide quién puede reclamar una dirección de origen. La otra decide hacia dónde se permite salir a ese paquete.

Dos tareas, mantenidas aparte

La capa de túnel responde a una pregunta estrecha: si la clave de este par autorizó esta dirección de origen interna. La capa de reenvío responde a una más amplia: si este paquete puede salir hacia ese destino. Ninguna responde a la pregunta de la otra, y ninguna es por sí sola una política de acceso completa.

Esa separación es la razón de que un par pueda estar autenticado, bien direccionado y aun así no poder alcanzar un equipo al que no debería llegar. También explica lo contrario: una regla de cortafuegos que lo permite todo no demuestra nada sobre quién puede reclamar qué dirección.

Diseñe las dos capas juntas y luego pruebe ambas. Una configuración correcta en una capa y sin probar en la otra falla abierta o cerrada según el valor predeterminado.

Dé a cada par solo su propia dirección

Los pares con varios equipos le tientan a conceder todo el rango del grupo en el lado del servidor. Ese permiso es una reclamación de dirección de origen, así que un cliente comprometido o mal configurado puede presentar cualquier dirección del rango y el túnel la aceptará. Asigne una /32 por par para su propia dirección interna. Configure rangos de grupo solo en los clientes, donde describen qué destinos puede alcanzar ese cliente en lugar de qué orígenes puede usar.

El cortafuegos entonces compara un origen en el que puede confiar. Una regla escrita para el rango del grupo sigue siendo una agrupación útil, y solo cobra sentido cuando ningún par individual puede reclamar una dirección que pertenece a otro miembro.

Escriba la política de reenvío que separa los grupos

El tráfico interesante aquí entra y sale por la misma interfaz de túnel, así que cruza la ruta de reenvío y no la ruta de entrada del equipo. Las reglas pertenecen a la cadena de reenvío existente del gestor de cortafuegos que sea dueño del equipo, y son fragmentos, no un conjunto de reglas completo.

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

Las dos primeras reglas permiten el tráfico dentro de cada grupo. La última bloquea todo lo demás que cruza esa interfaz, y eso es lo que produce el aislamiento entre los grupos. Añada reglas explícitas para la otra familia de direcciones si las necesita, porque un descarte escrito para IPv4 no autoriza ni describe el comportamiento de IPv6.

El orden decide si la política se aplica

El orden de las reglas importa más que el fragmento en sí. Una regla genérica que acepta conexiones establecidas y está colocada antes de estas entradas deja continuar un flujo antiguo entre grupos, así que el aislamiento solo se aplica a conexiones nuevas. Decida cuál de esos dos resultados quiere antes de recargar.

Un veredicto de aceptación tampoco es siempre definitivo entre cadenas en el mismo gancho. Si otra cadena base se ejecuta después, la política efectiva es la combinación, así que inspeccione los contadores en lugar del archivo que editó. Los contadores son la evidencia más barata disponible. Una regla sin recuento de paquetes no coincide, y una regla que coincide mientras una cadena posterior acepta le dice que el descarte está en el lugar equivocado.

Pruebe la matriz, no el número de archivos

Construya una matriz pequeña de resultados esperados y compruebe cada celda. Del grupo A al grupo A debería funcionar, del grupo B al grupo B debería funcionar, y de A a B no debería, en ambos sentidos y para ambas familias de direcciones si las admite.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

Las dos primeras muestran qué está configurado. El ping desde un miembro del grupo equivocado muestra qué ocurre en realidad. El listado de conntrack muestra si un flujo más antiguo sigue aceptándose, y así es como un cambio de aislamiento falla silenciosamente al entrar en vigor.

Los servicios de equipo en el concentrador y el acceso a una LAN detrás de él son rutas separadas con política separada. Anote cuáles de ellas cubre la matriz, porque una prueba que solo comprueba tráfico entre pares no dice nada sobre ninguna de las dos.