Una ruta predeterminada de VPN en la tabla 200 oculta tu ruta LAN

Cuatro comprobaciones separan un fallo de la tabla de políticas de un fallo de enrutamiento: qué regla coincidió, qué tabla nombró esa regla, qué contiene esa tabla y qué ruta dentro de ella ganó. La tabla principal no se consulta en cuanto una tabla anterior produce una ruta, así que una entrada LAN visible allí puede ser irrelevante para el paquete que estás probando. Haz las comprobaciones en orden, y la ruta que falta aparecerá en el tercer paso y no en el cuarto.

La coincidencia del prefijo más largo ocurre dentro de una sola tabla; no compara las rutas de todas las tablas como una única lista.

La consulta termina en la primera tabla que responde

Toma una política en la que el tráfico de una subred consulta primero la tabla 200, la tabla 200 contiene una ruta predeterminada por el túnel y la tabla principal contiene el prefijo LAN. Un paquete dirigido a una dirección LAN puede coincidir con esa ruta predeterminada de la tabla 200 y detenerse allí. Como la consulta produjo una ruta, la regla posterior de la tabla principal nunca llega a ofrecer su entrada más específica. El resultado es un paquete que entra en el túnel mientras una ruta LAN perfectamente buena queda sin usar.

Las reglas anteriores y la propia consulta de direcciones locales de la máquina siguen aplicándose, así que la prueba debe usar la fuente, la marca y la interfaz que lleva el flujo real. Consulta con cualquier otra cosa y puede que la LAN se seleccione correctamente, lo que oculta justo el fallo que estás buscando.

Pon la excepción LAN donde corresponde

La tabla seleccionada puede llevar las rutas LAN, conectadas y de extremo que necesita, lo que mantiene la política autosuficiente. Otro diseño usa una regla anterior explícita para el prefijo LAN, o una ruta de descarte deliberada que entrega un prefijo a una consulta posterior. Cada uno es un patrón legítimo con un propietario distinto. Elige por la política prevista y por quién mantiene las rutas, no por cuál es más corta de escribir.

Sea cual sea el patrón, la excepción debe ser visible donde se define la política. Una ruta añadida a mano y no registrada desaparecerá en el siguiente reinicio y se llevará el diagnóstico consigo.

No copies la tabla principal entera

Copiar cada ruta de la principal a la tabla de políticas parece una solución y crea una instantánea. Un administrador puede añadir o quitar direcciones e interfaces de forma dinámica, y la copia queda obsoleta sin que nadie lo note. Mantén el ciclo de vida de las rutas con su propietario de configuración y regenera la tabla a partir de la configuración, no de un momento concreto.

Una tabla copiada también anula el propósito, porque reproduce el comportamiento de reserva que la política debía limitar.

Comprueba las respuestas por separado de las rutas

Una vez que la consulta selecciona el camino deseado, las respuestas aún pueden fallar por motivos que nada tienen que ver con la tabla. La traducción puede aplicarse en la interfaz equivocada, la validación de ruta inversa puede rechazar un paquete que llegó por un camino inesperado, o el extremo puede simplemente no responder. Son fallos distintos con pruebas distintas, y ninguno se repara editando entradas de ruta.

Guarda la consulta para ese flujo exacto a ambos lados del cambio, para que la corrección siga siendo visible. Desactivar las comprobaciones de ruta inversa de forma global o vaciar reglas no aporta ninguna ruta que falte y debilita controles no relacionados.

Anota la regla, la tabla, la ruta ganadora y el camino de respuesta. Ese registro separa un error de política de un servicio roto.