Marcas de nftables y enrutamiento VPN: qué regla gana realmente
Una marca puesta en el cortafuegos aún puede fallar la regla de enrutamiento. Compruebe la máscara de la regla, el tipo de objeto y los demás escritores antes de añadir una cuarta.
Una marca puesta en nftables debería enviar una clase de tráfico por el túnel, y el tráfico sigue saliendo por la interfaz física. El conjunto de reglas parece correcto de forma aislada. Lo que suele haber ocurrido es que otra cosa escribió la misma marca, o que la regla de enrutamiento coincide con una máscara que el nuevo valor ya no satisface.
Comprobación 1: lea la regla con la que coincide el núcleo
Empiece por la regla de política y no por el cortafuegos. El núcleo consulta las reglas por orden de prioridad y la primera coincidencia decide la tabla. Lea el valor de fwmark y la máscara de la propia regla, y luego confirme que un paquete con la marca que puso coincide realmente con ella. Una regla que espera un valor completo de 32 bits no coincidirá con un paquete que solo lleva un bit.
Después confirme qué tabla selecciona esa regla y qué contiene la tabla. Una regla que apunta a una tabla vacía produce un fallo de búsqueda, lo que en muchos sistemas significa que el paquete cae a la regla siguiente y sale por la interfaz física.
Dos comandos lo resuelven: la lista de reglas y la búsqueda de ruta para el destino en esa tabla.
Comprobación 2: marca de paquete o marca de conexión
nftables puede poner una marca en el paquete y una marca en la entrada de seguimiento de conexiones, y son objetos distintos. La marca de paquete vive durante la pasada de procesamiento del paquete, mientras que la marca de conexión persiste para el flujo y debe copiarse deliberadamente. Poner una y esperar la otra es un arreglo a medias habitual.
Si la regla de enrutamiento se basa en la marca de paquete, restaurar la marca de conexión más adelante en la ruta no hace nada para esa decisión, porque la decisión ya se tomó.
Decida qué objeto posee la señal de enrutamiento y luego póngala en el punto donde se toma la decisión de enrutamiento.
Comprobación 3: quién más escribe esa marca
Las propias herramientas de WireGuard marcan sus paquetes UDP para que el transporte cifrado no se enrute de vuelta al túnel al que pertenece. Si su conjunto de reglas asigna un valor no relacionado al mismo campo, esa exclusión desaparece y el tráfico exterior del túnel intenta entrar en sí mismo. El síntoma es un túnel que se establece y luego deja de pasar tráfico.
Las marcas también las usan otras herramientas de cortafuegos, la red de contenedores y el enrutamiento por políticas para otros fines, así que dos subsistemas escribiendo todo el campo es un conflicto aunque cada uno sea correcto por separado.
Enumere los escritores antes de añadir otro.
Comprobación 4: la máscara decide qué conserva
Una marca es un campo de 32 bits, y las máscaras son la forma en que varios propietarios lo comparten. Poner un valor con máscara conserva los bits que usted no posee; poner todo el campo destruye los de todos los demás. Lea la máscara en cada regla que toque el campo, incluidas las que no escribió.
Documente la asignación de bits junto al conjunto de reglas.
De lo contrario, la siguiente persona reutilizará un valor que ya tiene propietario, y un conflicto aquí parece un error de enrutamiento cuando en realidad es un error de direccionamiento. La documentación de nftables sobre metadatos de paquetes describe las mismas operaciones de marca.
Comprobación 5: verifique con un flujo real, no con una búsqueda
Una búsqueda de ruta simple no lleva marca, así que puede mostrar un camino distinto del paquete real. Genere el tráfico que le interesa y observe los contadores, la entrada de seguimiento de conexiones y la interfaz por la que sale realmente. Pruebe tanto la clase incluida como la clase excluida, porque una marca demasiado amplia rompe la exclusión mientras parece exitosa. Si la clase incluida funciona y la clase excluida también entra en el túnel, la marca es demasiado amplia y no demasiado estrecha.
Evite vaciar el estado de conexiones para forzar una actualización durante una sesión activa, ya que los flujos nuevos y existentes pueden tomar caminos distintos legítimamente.
Registre la marca, la máscara y la tabla en un solo lugar, y la siguiente edición se vuelve revisable.