Una tabla VPN vacía no bloquea nada por sí sola

Una regla de política envía los paquetes marcados a una tabla dedicada, y la expectativa habitual es que la pérdida de la ruta VPN los bloquee. El mecanismo hace otra cosa. Cuando una tabla no contiene ninguna ruta coincidente, la búsqueda continúa hacia la regla siguiente en lugar de detenerse, y la tabla main todavía conserva una ruta predeterminada ordinaria para el enlace ascendente. El resultado es una configuración que parece fail-closed y se comporta como fail-open.

Nada está roto; así es como se especifica el enrutamiento por políticas.

La búsqueda continúa cuando una tabla no tiene nada

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 lookup default
32766: from all lookup main

Tome ese conjunto de reglas: una búsqueda marcada va a la tabla 42, y una regla posterior envía la misma marca a una tabla llamada default. Mientras la tabla 42 mantiene una ruta predeterminada utilizable, la primera búsqueda proporciona el camino. Cuando esa ruta desaparece y nada más en la tabla 42 coincide, la búsqueda no se convierte en un descarte; el procesamiento pasa a la regla siguiente, y cuando esa tampoco encuentra nada, llega a la tabla main. Nada en esa secuencia informa de qué regla produjo la respuesta final, así que una conexión que funciona parece una política que funciona.

La tabla 253, llamada convencionalmente default, es una tabla de enrutamiento ordinaria y normalmente está vacía. Su nombre no es una instrucción para descartar paquetes, y no es lo mismo que una ruta de destino predeterminada dentro de una tabla.

Las acciones terminales terminan la búsqueda

100:   from all fwmark 0x36 lookup 42
110:   from all fwmark 0x36 prohibit
32766: from all lookup main

Una regla terminal puede seguir a la búsqueda VPN en lugar de una búsqueda en una tabla vacía. Con la misma marca, una acción prohibit colocada después de la regla de la tabla 42 termina la búsqueda cuando esa tabla no devuelve nada, devolviendo un rechazo administrativo en lugar de ofrecer a la tabla main otra oportunidad. Unreachable y blackhole también son terminales, con un comportamiento de error distinto para el remitente.

Una ruta de tipo throw es distinta: dentro de esa tabla se comporta como si nada hubiera coincidido, así que las reglas posteriores siguen teniendo su turno. Eso hace que throw sea útil para un retroceso deliberado e incorrecto como bloque final.

Verifique con la marca y la interfaz reales

ip -4 rule show
ip -4 route show table 42
ip -4 route get 198.51.100.20 from 10.44.0.2 iif lan0 mark 0x36

Inspeccione las reglas y la tabla reales en lugar de un diagrama, y luego consulte el flujo con el contexto de origen, marca y entrada que realmente tiene. Una búsqueda de solo lectura dirigida a un destino, a la que se indica la dirección de origen, la interfaz y la marca, informa de la ruta que el núcleo elegiría sin que salga ningún paquete. Proporcionar una marca en la consulta no demuestra que el cortafuegos marque tráfico real; eso es una comprobación aparte de las reglas de marcado. Confirme el valor con un contador o un registro antes de sacar conclusiones de la consulta.

Las solicitudes generadas localmente necesitan su propio contexto, porque su ruta de marcado suele diferir de la del tráfico reenviado. Compruébelas con la interfaz de salida que la aplicación usaría realmente.

Dos estados de fallo, no uno

Un estado de fallo es que la ruta VPN desaparezca y el tráfico caiga al enlace ascendente. Un túnel muerto cuya ruta permanece instalada es otro: los paquetes siguen dirigidos a una ruta inutilizable en lugar de caer, y el síntoma es una pérdida silenciosa en lugar de una conexión directa visible. Pruebe ambos, y también el comportamiento en arranque, reconexión y parada del servicio.

Una regla así solo ayuda mientras existe y mientras los paquetes aún llevan la marca que la selecciona. Un script de apagado que elimine la regla, o una ruta que quite la marca, restaura el comportamiento abierto. Merece la pena ensayar esas transiciones.

Aplique la política a IPv6 por separado y mantenga explícitas, en lugar de implícitas, las excepciones de punto final aprobadas.