Bloquee un rango de destino para cada grupo de clientes VPN

Una regla puede mantener un grupo VPN admitido lejos de un rango de destino sin alterar nada más de lo que hace la pasarela. La regla en sí es corta; las partes que deciden si funciona son el hook en el que vive y su posición en la cadena. Equivocarse en esas dos produce un cortafuegos que parece correcto y se comporta de forma inconsistente. Empiece por lo que hace el paquete cuando la regla lo ve.

Qué compara realmente la regla

La regla compara tres cosas a la vez: una interfaz de entrada, un prefijo de origen y un prefijo de destino. Las tres deben ser ciertas antes de que se aplique el drop, y eso es lo que la mantiene estrecha. Leerla como una sola expresión es más fácil que leerla como tres políticas separadas.

La coincidencia de interfaz es lo que distingue el tráfico reenviado de los clientes de las conexiones propias de la pasarela. Sin ella, una regla que solo nombrara el grupo de origen también afectaría a paquetes que la propia pasarela genera desde esa dirección, si alguna vez lo hace. El prefijo de origen limita la política a los clientes admitidos, y el prefijo de destino la limita a un solo rango. Lea la regla como una intersección y no como una lista.

Anote los tres valores antes de editar nada: el nombre de la interfaz del túnel, el grupo que reparte el servidor y el prefijo que pretende denegar. Una errata en cualquiera de ellos produce una regla que se analiza limpiamente y no protege nada. Guarde esos tres valores en el registro de cambios junto a la regla.

El hook decide a quién se aplica la regla

Una cadena de netfilter se engancha a un hook, y el hook decide qué paquetes llega a ver la cadena. El hook forward ve el tráfico enrutado a través de la pasarela, que es justo el tráfico de cliente a destino. Todo lo demás de la cadena apunta a otro público.

El hook input ve el tráfico dirigido a la propia pasarela, así que una regla colocada ahí gobierna el acceso a sus propios servicios y no el tránsito. El hook output ve el tráfico que origina la pasarela, que es lo contrario de lo que necesita una política de grupo de clientes. Los nombres de cadena son etiquetas arbitrarias elegidas por quien escribió el conjunto de reglas, así que no deduzca el hook del nombre. Compruebe dónde se engancha la cadena antes de suponer qué puede comparar.

Leer el enganche es una comprobación de una línea que impide que una regla acabe en una cadena que nunca ve el paquete.

Coloque la regla antes de la aceptación amplia

Las reglas se evalúan en orden y el primer veredicto gana. Una aceptación amplia anterior en la cadena termina la evaluación de los paquetes que coincide, así que un drop añadido después nunca se ejecuta para ellos. Esa regla de orden es toda la razón por la que una regla de aspecto correcto puede no tener efecto.

Inserte la regla antes de la aceptación en lugar de añadirla al final. Si la cadena ya contiene una aceptación general para la interfaz del túnel, la nueva regla debe precederla o es decorativa. Compruebe el orden resultante y no el archivo que editó, porque un conjunto de reglas montado a partir de varios archivos puede no coincidir con ninguno de ellos. Después confírmelo con un paquete de prueba del grupo.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

El tercer comando analiza el archivo sin aplicarlo, lo que detecta errores de sintaxis antes de que se conviertan en una caída. Aplíquelo con un plan de reversión, porque una regla equivocada en una cadena forward puede cortar el túnel por el que trabaja.

Los flujos existentes no hacen caso de su regla nueva

Una entrada de conntrack creada antes de que existiera la regla sigue coincidiendo con la aceptación anterior. Por eso un drop nuevo a veces parece funcionar para conexiones nuevas y no hacer nada por la que se está probando.

Lea la coincidencia de estado en la parte superior de la cadena. Si acepta tráfico established y related antes de su regla, cada flujo ya en curso sigue fluyendo hasta que se cierra. Normalmente ese es el comportamiento que quiere para una regla de emergencia, y resulta confuso cuando espera un corte inmediato. Decida qué efecto quiere antes de desplegar. Una prueba que reutilice una conexión abierta le contará una historia equivocada.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

El primer comando muestra si existe un flujo, y el segundo muestra si una regla de estado temprana sigue aceptándolo. Ambos son de solo lectura y seguros durante un incidente.

Qué no es esta regla

La regla no es una lista negra de dominios, una política IPv6 ni una restricción sobre una cuenta de aplicación concreta.

Cada una de esas cosas necesita su propio mecanismo. Un bloqueo de dominio tiene que resolver nombres, algo que un filtro de paquetes no hace. El tráfico IPv6 necesita su propia coincidencia, porque una expresión ip no dice nada sobre paquetes ip6. Una restricción a nivel de aplicación pertenece al servicio o a un proxy autenticado, no a una coincidencia de prefijo. Mantener separados esos requisitos es lo que evita pedirle a una regla estrecha que haga cuatro trabajos.

El contrato que entrega esta regla es preciso: se deniega el tráfico de un grupo admitido hacia un prefijo de destino, mientras que el tráfico no relacionado de la pasarela conserva su política existente. Escriba esa frase junto a la regla, y la siguiente persona sabrá para qué servía.