IPsec con varias subredes perde o tráfico de volta? Conta os reqid
O tráfico nun só sentido por un túnel con varias subredes adoita ser un desaxuste de política e reqid, non de cifrado nin de encamiñamento. Le os bancos xfrm na orde correcta.
O tráfico sae dun sitio e nunca volve, as dúas pasarelas informan dunha negociación completada, e a única pista é unha morea de paquetes de saída sen respostas. Nun extremo Linux, a causa habitual non é a forza do cifrado, a MTU ou unha táboa de rutas. É a granularidade das entradas de política e o número que liga cada política a unha asociación de seguridade. O procedemento de abaixo le eses dous bancos antes de tocar calquera outra cousa.
Separa o síntoma antes de cambiar nada
Un fallo nun só sentido cunha negociación IKE completada reduce o problema á ruta de datos. Ou a política de saída coincidía e a resposta descartouse, ou a resposta nunca chegou porque o outro lado non tiña por onde enviarlle. Desde unha aplicación os dous casos ven iguais, e os bancos xfrm distínguenos.
Non comeces pola MTU. Unha MTU incorrecta produce bloqueos e síntomas de fragmentación, non unha separación limpa de dirección con contadores de saída a subir.
Le o banco de políticas e o banco de estados
En Linux o cifrado decídeno as entradas de política, así que unha política coincidente, non unha ruta, é o que mete un paquete no túnel. Executa ip xfrm policy para ver os selectores, a dirección, a prioridade e o modelo de cada entrada, e ip xfrm state para ver as asociacións establecidas cos seus reqid. A política e a asociación únense por ese reqid.
Mira as tres direccións. Saída e entrada cobren o tráfico cara a e desde este host; a dirección de encamiñamento importa cando o host encamiña por outros. Unha entrada ausente ou discordante nunha dirección explica un resultado nun só sentido sen ningunha falla criptográfica.
A asimetría clásica: un reqid para varias subredes
Un fallo frecuente vén dun par que instala políticas para todas as subredes negociadas baixo un único reqid, o que acontece con generate_policy require de racoon. O tráfico sae entón pola asociación establecida en último lugar, mentres o outro lado mantén unha asociación separada por subrede. As respostas chegan por unha asociación cuxo reqid non identifica a política que debería aceptalas, e o núcleo descártaas tras o descifrado.
A solución é un cambio de configuración, non unha regra de devasa: generate_policy unique; dá a cada política o seu propio reqid, de modo que as asociacións por política do par teñan parellas correspondentes. Aplícao, renegocia e conta os reqid distintos para as subredes que esperas antes de declarar o éxito.
Se dúas subredes aínda comparten un reqid mentres o outro lado espera dúas, atopaches a asimetría. Anota a correspondencia, porque é a proba de que o seguinte cambio a corrixiu ou a conservou.
Os selectores veñen da negociación, non da túa configuración
Os rangos protexidos son o que ambos os extremos acordaron, non o que pediu unha das partes. Un cliente que ofrece un par de hosts contra un rango remoto amplo recibe a versión estreitada da pasarela, e o cliente non pode ampliala. Le os selectores instalados en lugar dos do teu ficheiro local.
Cando o obxectivo é o contrario, manter un destino fóra do túnel, engade unha política de omisión cun número de prioridade máis baixo para que gañe a entrada instalada automaticamente. Unha política sen modelo permite texto simple, o que a converte nunha excepción deliberada para un rexistro de cambios en vez dun paso de depuración.
Verifica nesta orde, e sabe como reverter
Lista as políticas de cada subrede nas dúas direccións, incluído o encamiñamento se o host encamiña. Conta os reqid distintos e confirma un por política no lado que o espera. Compara os selectores instalados cos negociados. Volve ler os contadores por asociación tras unha renovación de chave, porque a asociación inspeccionada pode ter desaparecido xa. Comproba as rutas ao final, xa que unha ruta ausente cara á subrede remota produce un síntoma similar nun só sentido con contadores de política limpos.
Antes de cambiar o par, garda a saída actual dos dous comandos xfrm. Se o novo axuste non restaura a dirección de volta, restaurar esa saída é unha reversión máis rápida que reconstruír o túnel de memoria, e mantén a comparación honesta.