Por que unha política de seguridade IPsec non é unha entrada da táboa de rutas
Unha ruta que funciona non demostra nada sobre IPsec. Le a consulta de ruta e os selectores da política para o mesmo fluxo e despois confirma que unha asociación o cobre.
Fai ping a 10.20.0.5 polo túnel e non volve nada, mentres a táboa de rutas insiste en que esa subrede é alcanzable. O enrutamento e IPsec responden a preguntas distintas, e só unha delas trata da alcanzabilidade. A consulta directa escolle unha ruta e despois a base de datos de política de seguridade decide se esa ruta debe protexerse, deixarse como está ou rexeitarse. Cando as dúas discrepan, o paquete morre en silencio, así que leas nesa orde.
Comeza pola consulta, non pola táboa
Pregunta ao núcleo que faría realmente: ip route get 10.20.0.5 mostra a ruta escollida, a interface de saída e o enderezo de orixe que usaría. Un prefixo, unha regra de política, unha marca ou unha orixe preferida poden cambiar esa resposta, e por iso a consulta en vivo supera ler a táboa a ollo.
Proba un destino dentro do rango protexido, non o enderezo da pasarela. Alcanzar a pasarela do outro lado só demostra que existe algunha ruta; non di nada sobre a subrede que realmente necesitas. Despois confirma que a interface que escolleu a consulta é a que esperas que use o túnel.
Fai coincidir os selectores nos dous lados
A base de datos de política ten as súas propias entradas, e cada unha indica unha dirección, unha orixe, un destino e un protocolo, e despois di que debe ocorrer cos paquetes que coinciden. Usa ip xfrm policy para listalas; os indicadores mostran se a acción é protexer, omitir ou bloquear. Unha política cuxos selectores son máis amplos ou máis estreitos que o teu fluxo de proba non coincidirá con el, e o paquete sae sen protección. Ese é o fallo que buscas, non unha ruta que falta.
Compara os valores reais: orixe, destino, protocolo e portos. Se a consulta resolveu un par de enderezos mentres a entrada de política cobre outro, as dúas vistas describen tráfico distinto. Volve executar ambas coa mesma tupla antes de sacar unha conclusión, ou editarás unha política que nunca estivo na ruta.
Unha coincidencia de política non é estado instalado
Unha política coincidente só di que o paquete debe protexerse; o núcleo aínda necesita unha asociación de seguridade para facer a protección. Lístalas con ip xfrm state, ou con swanctl --list-sas cando strongSwan fai a negociación, e le os selectores e os contadores de cada entrada.
Cando unha política coincide e ningunha asociación cobre os mesmos selectores, o paquete descártase en lugar de enviarse en texto claro. Ese é o descarte que hai que buscar cando o túnel está levantado pero falla unha soa subrede. Os contadores din o resto: unha asociación que nunca aumenta nunca foi seleccionada, mentres que unha que aumenta e aínda así acaba nun descarte apunta ao lado remoto. Corrixir selectores e renovar claves son reparacións distintas, así que decide cal necesitas antes de tocar a configuración.
Que segue a esixir un túnel baseado en ruta
Unha interface XFRM fai que o túnel pareza un dispositivo ao que podes enrutar, o cal é realmente útil. Non elimina a política e o estado que deciden que ocorre cando o paquete chega alí. A ruta achega un seguinte salto e nada máis.
Se o dispositivo existe e a ruta apunta cara a el mentres ningunha asociación coincide cos selectores internos, o paquete descártase, e ningunha cantidade de edición de rutas produce claves nin selectores. Comproba a interface coa mesma orixe e destino que enrutaches e despois compara iso coa lista de estados.
Aclara a propiedade antes de editar nada
Un cortalumes do host engade unha terceira decisión que ningunha das dúas bases de datos coñece. Unha ruta correcta máis unha política coincidente máis unha asociación instalada aínda poden rematar nun paquete descartado, e a aplicación só informa do tempo de espera. Confirma que o cortalumes permite o tráfico protexido antes de culpar IPsec. Capturar no dispositivo do túnel e na interface física mostra de que lado do cifrado desapareceu o paquete.
A propiedade da configuración decide se a túa corrección sobrevive a un reinicio. Un compoñente pode instalar estado mentres outro xestiona rutas, e unha edición manual no segundo sobrescríbese a próxima vez que o túnel sobe. Cambia a configuración propietaria e despois volve ler as dúas vistas; RFC 4301 mantén as dúas bases de datos separadas cando tes que explicar a división a outra persoa.