Unha ruta predeterminada de VPN na táboa 200 oculta a túa ruta LAN
Pode que unha ruta visible na táboa principal nunca se consulte. Comproba que regra coincidiu, que contén a súa táboa e se o camiño de resposta sobrevive.
Catro comprobacións separan un fallo da táboa de políticas dun fallo de enrutamento: que regra coincidiu, que táboa nomeou esa regra, que contén esa táboa e que ruta dentro dela gañou. A táboa principal non se consulta en canto unha táboa anterior produce unha ruta, así que unha entrada LAN visible alí pode ser irrelevante para o paquete que estás probando. Fai as comprobacións en orde, e a ruta que falta aparecerá no terceiro paso e non no cuarto.
A coincidencia do prefixo máis longo ocorre dentro dunha soa táboa; non compara as rutas de todas as táboas como unha única lista.
A consulta remata na primeira táboa que responde
Toma unha política na que o tráfico dunha subrede consulta primeiro a táboa 200, a táboa 200 contén unha ruta predeterminada polo túnel e a táboa principal contén o prefixo LAN. Un paquete dirixido a un enderezo LAN pode coincidir con esa ruta predeterminada da táboa 200 e deterse alí. Como a consulta produciu unha ruta, a regra posterior da táboa principal nunca chega a ofrecer a súa entrada máis específica. O resultado é un paquete que entra no túnel mentres unha ruta LAN perfectamente boa queda sen usar.
As regras anteriores e a propia consulta de enderezos locais da máquina seguen aplicándose, así que a proba debe usar a fonte, a marca e a interface que leva o fluxo real. Consulta con calquera outra cousa e pode que a LAN se seleccione correctamente, o que oculta xusto o fallo que estás buscando.
Pon a excepción LAN onde corresponde
A táboa seleccionada pode levar as rutas LAN, conectadas e de extremo que necesita, o que mantén a política autosuficiente. Outro deseño usa unha regra anterior explícita para o prefixo LAN, ou unha ruta de descarte deliberada que entrega un prefixo a unha consulta posterior. Cada un é un patrón lexítimo cun propietario distinto. Escolle pola política prevista e por quen mantén as rutas, non por cal é máis curta de escribir.
Sexa cal sexa o patrón, a excepción debe ser visible onde se define a política. Unha ruta engadida a man e non rexistrada desaparecerá no seguinte reinicio e levará o diagnóstico consigo.
Non copies a táboa principal enteira
Copiar cada ruta da principal á táboa de políticas parece unha solución e crea unha instantánea. Un administrador pode engadir ou quitar enderezos e interfaces de xeito dinámico, e a copia queda obsoleta sen que ninguén o note. Mantén o ciclo de vida das rutas co seu propietario de configuración e rexenera a táboa a partir da configuración, non dun momento concreto.
Unha táboa copiada tamén anula o propósito, porque reproduce o comportamento de reserva que a política debía limitar.
Comproba as respostas por separado das rutas
Unha vez que a consulta selecciona o camiño desexado, as respostas aínda poden fallar por motivos que nada teñen que ver coa táboa. A tradución pode aplicarse na interface equivocada, a validación de ruta inversa pode rexeitar un paquete que chegou por un camiño inesperado, ou o extremo pode simplemente non responder. Son fallos distintos con probas distintas, e ningún se repara editando entradas de ruta.
Garda a consulta para ese fluxo exacto a ambos os dous lados do cambio, para que a corrección siga sendo visible. Desactivar as comprobacións de ruta inversa de forma global ou baleirar regras non achega ningunha ruta que falte e debilita controis non relacionados.
Anota a regra, a táboa, a ruta gañadora e o camiño de resposta. Ese rexistro separa un erro de política dun servizo roto.