La regla de enrutamiento lee la marca del paquete, no conntrack

Cuatro comprobaciones separan una regla de marca que funciona de una ruta que funciona: qué marca lee la regla, si el paquete todavía la lleva en el momento de la consulta, si se restauró una marca de conexión en paquetes posteriores y si la máscara y la prioridad de la regla correspondiente le permiten activarse. Un contador que se incrementa solo demuestra que alguna regla coincidió con algo. No dice nada sobre lo que llevaba el paquete cuando el núcleo eligió su camino.

Las dos marcas viven en lugares distintos y caducan según calendarios distintos.

Dos marcas, dos vidas

Una marca de paquete pertenece a un solo skb, viaja con él por los hooks y la consume el selector fwmark del enrutamiento por políticas. Una marca de conexión pertenece a la entrada de conntrack, persiste a través de los paquetes de ese flujo y es invisible para la regla de enrutamiento hasta que algo la vuelve a copiar. Guardar una marca de paquete en la conexión es un almacenamiento; restaurarla es una acción aparte. Ninguna de las dos ocurre de forma implícita.

Por eso un conjunto de reglas puede parecer coherente mientras la decisión de enrutamiento ve cero: el valor se guardó y nada lo restauró.

Copiar entre ellas es un paso que escribes tú

Las dos sentencias que importan van en direcciones opuestas: una guarda la marca del paquete en la conexión, la otra carga la marca de la conexión en el paquete. Cuál necesitas depende de cuándo ocurre la clasificación respecto al flujo. Un diseño puede necesitar solo la marca del paquete, y añadir marcado por conntrack porque algún apaño usaba las dos es la forma en que una política sencilla adquiere un segundo modo de fallo.

ct mark set meta mark
meta mark set ct mark

Escribe la dirección junto a la regla, porque no es obvia a primera vista a partir de la sintaxis. La primera línea guarda, la segunda restaura, y ninguna implica la otra.

Clasifica antes de la consulta que lo consume

El tráfico generado localmente y el tráfico reenviado desde una LAN atraviesan hooks distintos y llegan a decisiones de enrutamiento en momentos distintos. Una regla de salida que funciona para las conexiones del propio router no demuestra que el paquete de un cliente reenviado se marcara antes de su consulta. Coloca la clasificación donde la consulta que la consume aún no ha ocurrido, y comprueba si las reglas posteriores de la misma cadena sobrescriben el valor. El orden dentro de una cadena es parte de la configuración, no un detalle de implementación.

La persistencia del estado de conexión también necesita un plan explícito. Si solo se clasifica el primer paquete de un flujo, los paquetes posteriores necesitan que se restaure la marca guardada, o tomarán el camino sin marca. Esa es la diferencia entre una marca que describe una conexión y una que describe un paquete.

Hazle a la ruta una pregunta con marca

ip route get 10.77.0.10 mark 0x2

Inspecciona las reglas y la tabla, luego consulta la ruta con la marca incluida, además del origen o la interfaz de entrada cuando afecten a la política. Una consulta normal sin marca responde otra pregunta y te informará encantada del camino que no querías. Comprueba la máscara y la prioridad de la regla además de su valor, y confirma que la tabla seleccionada contiene una ruta utilizable.

Un contador que se incrementa es prueba de que alguna regla coincidió con algún paquete. No es prueba de que el paquete final llevara la marca prevista en el punto de decisión correcto.

Lee la marca, la dirección, el momento y la máscara. Cuatro comprobaciones, y la ruta deja de ser un misterio.