Mode trap d'strongSwan: per què el túnel IPsec espera el trànsit

No apareix cap CHILD SA a la sortida d'estat, el túnel sembla mort i, de sobte, un ping a la subxarxa remota el fa pujar. En una configuració IPsec sota demanda aquesta seqüència és el disseny, no una avaria. Una política trap instal·la un selector i espera, i el primer paquet que hi coincideix és el que inicia IKE i la negociació del CHILD SA.

Part de la confusió és de vocabulari: “up” s'utilitza per a dos estats diferents. La configuració està carregada i la política del nucli existeix, però l'associació de dades no. Un monitor que només compta SA actives informarà d'un lloc sa com a caigut mentre ningú no hi enviï trànsit.

Un túnel inactiu sota demanda no té cap CHILD SA per mostrar

Una entrada trap no autentica res per si mateixa. Demana al nucli que mantingui una política per al trànsit seleccionat i que aixequi una acquisition quan un paquet necessiti aquesta política. El dimoni rep l'acquisition, l'aparella amb la definició de child i negocia des d'allà. Fins a aquest punt tampoc no hi ha cap IKE SA per mostrar, i per això les dues llistes poden ser buides alhora.

Aquest ordre és el que fa llegibles els registres. Primer arriba l'acquisition, després IKE_SA_INIT i IKE_AUTH, i després el CHILD SA. Si el registre acaba just després de l'acquisition, el disparador ha funcionat. La negociació ha fallat, i la pregunta següent és sobre credencials, propostes o abastabilitat, no sobre el trap.

Amb el backend del nucli Linux pots veure la política abans que existeixi cap SA. Executa ip xfrm policy i busca el selector amb direcció out i una plantilla que apunti a la connexió. Aquesta entrada és l'estat sota demanda, i la seva presència és el primer que cal confirmar.

start_action decideix si algú espera, almenys

Cada child a swanctl.conf porta un start_action. start s'inicia quan es carrega la configuració, trap instal·la la política i espera, i none deixa la iniciació a una altra cosa. Només trap produeix el comportament de “ping i puja” descrit més amunt.

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

Els dos selectors de trànsit defineixen què compta com a interessant, i un paquet d'un equip fora d'aquests prefixos no dispara el trap; s'encamina com de costum. Ampliar els selectors per fer el disparador més àvid també amplia l'abast que el túnel diu protegir, així que deriva'ls del trànsit que realment vols xifrar.

La referència de swanctl.conf llista els valors acceptats, juntament amb les accions separades close i DPD que governen què passa un cop existeix l'SA.

Esbrina si el disparador s'ha activat

Comença amb swanctl --list-conns i confirma que el child està carregat amb l'acció que volies. Després envia un paquet des d'un equip dins de local_ts a una adreça dins de remote_ts i observa swanctl --list-sas. Si la sortida no canvia, cap acquisition no ha arribat al dimoni.

Dos motius habituals d'un trap silenciós: el paquet ha passat per source-NAT abans d'arribar a la política i ja no coincideix amb local_ts, o la connexió no s'ha carregat mai per un error de sintaxi o de credencials. Torna a executar swanctl --load-all i llegeix la seva sortida abans de tocar els selectors. Una connexió que no s'ha carregat no instal·la cap política, així que no hi ha res perquè el trànsit dispari.

La direcció també importa: un trap instal·lat per al trànsit sortint no s'inicia amb un paquet entrant. Si el costat remot ha de pujar el túnel, necessita el seu propi trap, o aquest costat necessita start.

Esperar el primer paquet no sempre és el bon intercanvi

Les sessions interactives noten el cost de la configuració. La primera petició paga l'intercanvi IKE i la negociació CHILD, i un client amb poc marge pot rendir-se abans que existeixi l'SA. Un start proactiu elimina aquest retard del primer paquet. Però manté un túnel obert per a trànsit que potser no arribarà mai.

Tres fets decideixen l'elecció: amb quina freqüència s'usa el camí, si la primera petició té un termini ajustat i si el peer és abastable a l'arrencada. El trànsit per lots ocasional i un peer que pot estar fora de línia a l'arrencada afavoreixen tots dos trap. Un client sensible a la latència i un peer sempre abastable afavoreixen start. Si tots dos costats poden iniciar, acordeu qui posseeix el disparador per no tenir negociacions duplicades.

Una política instal·lada tampoc no és una garantia a prova de fuites. Si el requisit és fail-closed, el tallafoc ha de descartar el trànsit sense SA, i aquesta regla viu fora de la definició de child.

Anota les tres línies que tanquen la propera discussió

Escriu els selectors, l'acció d'arrencada i la sortida de la comanda que mostra la política present sense SA. Aquestes tres línies separen “sota demanda i inactiu” de “no es carrega” la propera vegada que algú informi que el túnel està caigut. Costen un minut de capturar. Sense elles, la mateixa investigació torna a començar de zero.

Prova des d'un equip que sigui realment dins del selector. Un ping des del mateix encaminador sovint segueix un camí diferent i no demostra res sobre la política que protegeix la subxarxa que hi ha darrere.