Modo trap de strongSwan: por que o túnel IPsec espera tráfico

Un túnel IPsec inactivo baixo demanda non mostra ningún CHILD SA ata que un paquete coincide coa súa política trap. Le o estado, comproba o disparador e sabe cando encaixa start.

Non aparece ningún CHILD SA na saída de estado, o túnel parece morto e, de súpeto, un ping á subrede remota lévao arriba. Nunha configuración IPsec baixo demanda esa secuencia é o deseño, non unha avaría. Unha política trap instala un selector e espera, e o primeiro paquete que coincide con ela é o que inicia IKE e a negociación do CHILD SA.

Parte da confusión é de vocabulario: “up” úsase para dous estados distintos. A configuración está cargada e a política do kernel existe, pero a asociación de datos non. Un monitor que só conta SA activas informará dun sitio san como caído mentres ninguén lle envíe tráfico.

Un túnel inactivo baixo demanda non ten ningún CHILD SA que mostrar

Unha entrada trap non autentica nada por si mesma. Pide ao kernel que manteña unha política para o tráfico seleccionado e que levante unha acquisition cando un paquete necesita esa política. O daemon recibe a acquisition, emparella con ela definición de child e negocia desde aí. Ata ese momento tampouco hai ningún IKE SA que mostrar, por iso ambas listas poden estar baleiras á vez.

Esa orde é o que fai lexibles os rexistros. Primeiro chega a acquisition, despois IKE_SA_INIT e IKE_AUTH, e despois o CHILD SA. Se o rexistro remata xusto despois da acquisition, o disparador funcionou. A negociación fallou, e a seguinte pregunta é sobre credenciais, propostas ou alcanzabilidade, non sobre o trap.

Co backend do kernel Linux podes ver a política antes de que exista ningún SA. Executa ip xfrm policy e busca o selector con dirección out e un modelo que apunte á conexión. Esa entrada é o estado baixo demanda, e a súa presenza é o primeiro que hai que confirmar.

start_action decide se algo espera sequera

Cada child en swanctl.conf leva un start_action. start iníciase cando se carga a configuración, trap instala a política e espera, e none deixa a iniciación a outra cousa. Só trap produce o comportamento de “ping e sobe” descrito arriba.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Os dous selectores de tráfico definen que conta como interesante, e un paquete dun host fóra deses prefixos non dispara o trap; encamíñase coma sempre. Ampliar os selectores para que o disparador sexa máis ávido tamén amplía o alcance que o túnel di protexer, así que derívaos do tráfico que realmente pensas cifrar.

A referencia de swanctl.conf enumera os valores aceptados, xunto coas accións separadas close e DPD que gobernan que ocorre unha vez existe a SA.

Averigua se o disparador se activou

Comeza con swanctl --list-conns e confirma que o child está cargado coa acción que pretendías. Logo envía un paquete desde un host dentro de local_ts a un enderezo dentro de remote_ts e observa swanctl --list-sas. Se a saída non cambia, ningunha acquisition chegou ao daemon.

Dous motivos habituais dun trap silencioso: o paquete pasou por source-NAT antes de chegar á política e xa non coincide con local_ts, ou a conexión nunca se cargou por un erro de sintaxe ou de credenciais. Volve executar swanctl --load-all e le a súa saída antes de tocar os selectores. Unha conexión que non se cargou non instala política, así que non hai nada que o tráfico poida disparar.

A dirección tamén importa: un trap instalado para tráfico saínte non se inicia cun paquete entrante. Se o lado remoto debe levantar o túnel, necesita o seu propio trap, ou este lado necesita start.

Esperar o primeiro paquete non sempre é o intercambio correcto

As sesións interactivas notan o custo da configuración. A primeira petición paga o intercambio IKE e a negociación CHILD, e un cliente con pouco marxe pode renderse antes de que exista a SA. Un start proactivo elimina ese atraso do primeiro paquete. Pero mantén un túnel aberto para tráfico que quizais nunca chegue.

Tres feitos deciden a elección: con que frecuencia se usa o camiño, se a primeira petición ten un prazo axustado e se o peer é alcanzable ao arrincar. O tráfico por lotes ocasional e un peer que pode estar fóra de liña ao arrincar favorecen ambos trap. Un cliente sensible á latencia e un peer sempre alcanzable favorecen start. Se ambos os dous lados poden iniciar, acordade quen posúe o disparador para non ter negociacións duplicadas.

Unha política instalada tampouco é unha garantía a proba de fugas. Se o requisito é fail-closed, o cortafuegos debe descartar o tráfico sen SA, e esa regra vive fóra da definición de child.

Anota as tres liñas que pechan a seguinte discusión

Escribe os selectores, a acción de arrinque e a saída do comando que mostra a política presente sen SA. Esas tres liñas separan “baixo demanda e inactivo” de “non se carga” a próxima vez que alguén informe de que o túnel está caído. Custan un minuto de capturar. Sen elas, a mesma investigación volve comezar de cero.

Proba desde un host que estea realmente dentro do selector. Un ping desde o propio router adoita seguir un camiño distinto e non demostra nada sobre a política que protexe a subrede que hai detrás.

Artigos relacionados