Modalità trap di strongSwan: perché il tunnel IPsec attende traffico

Nessun CHILD SA compare nell'output di stato, il tunnel sembra morto, poi un ping verso la subnet remota lo solleva. In una configurazione IPsec su richiesta questa sequenza è il progetto, non un guasto. Una policy trap installa un selettore e attende, e il primo pacchetto che vi corrisponde è ciò che avvia IKE e la negoziazione del CHILD SA.

Parte della confusione è di vocabolario: «up» viene usato per due stati diversi. La configurazione è caricata e la policy del kernel esiste, ma l'associazione dati no. Un monitor che conta solo le SA attive segnalerà un sito sano come inattivo finché nessuno gli invia traffico.

Un tunnel inattivo su richiesta non ha alcun CHILD SA da mostrare

Una voce trap non autentica nulla da sola. Chiede al kernel di mantenere una policy per il traffico selezionato e di sollevare un'acquisition quando un pacchetto ha bisogno di quella policy. Il demone riceve l'acquisition, la abbina alla definizione child e negozia da lì. Fino a quel momento non c'è nemmeno un'IKE SA da mostrare, ed è per questo che entrambi gli elenchi possono essere vuoti contemporaneamente.

È questo ordine a rendere leggibili i log. Prima arriva l'acquisition, poi IKE_SA_INIT e IKE_AUTH, poi il CHILD SA. Se il log termina subito dopo l'acquisition, il trigger ha funzionato. La negoziazione è fallita, e la domanda successiva riguarda credenziali, proposte o raggiungibilità, non il trap.

Con il backend del kernel Linux puoi vedere la policy prima che esista qualsiasi SA. Esegui ip xfrm policy e cerca il selettore con direzione out e un modello che punta alla connessione. Quella voce è lo stato su richiesta, e la sua presenza è la prima cosa da confermare.

start_action decide se qualcosa attende

Ogni child in swanctl.conf porta un start_action. start si avvia quando si carica la configurazione, trap installa la policy e attende, e none lascia l'avvio a qualcos'altro. Solo trap produce il comportamento «ping e sale» descritto sopra.

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

I due selettori di traffico definiscono cosa conta come interessante, e un pacchetto da un host fuori da quei prefissi non attiva il trap; viene instradato come al solito. Allargare i selettori per rendere il trigger più impaziente allarga anche l'ambito che il tunnel dichiara di proteggere, quindi derivarli dal traffico che vuoi davvero cifrare.

La documentazione di swanctl.conf elenca i valori accettati, insieme alle azioni separate close e DPD che regolano cosa succede una volta esistente la SA.

Scopri se il trigger si è attivato

Inizia con swanctl --list-conns e conferma che il child sia caricato con l'azione prevista. Poi invia un pacchetto da un host dentro local_ts a un indirizzo dentro remote_ts e osserva swanctl --list-sas. Se l'output non cambia, nessuna acquisition ha raggiunto il demone.

Due motivi comuni di un trap silenzioso: il pacchetto ha subito un source-NAT prima di colpire la policy e non corrisponde più a local_ts, oppure la connessione non si è mai caricata per un errore di sintassi o di credenziali. Esegui di nuovo swanctl --load-all e leggi il suo output prima di toccare i selettori. Una connessione che non si è caricata non installa alcuna policy, quindi non c'è nulla che il traffico possa attivare.

Anche la direzione conta: un trap installato per il traffico in uscita non si avvia su un pacchetto in entrata. Se il lato remoto deve sollevare il tunnel, gli serve il proprio trap, oppure questo lato ha bisogno di start.

Attendere il primo pacchetto non è sempre lo scambio giusto

Le sessioni interattive sentono il costo della configurazione. La prima richiesta paga lo scambio IKE e la negoziazione CHILD, e un client con scadenza breve può arrendersi prima che la SA esista. Un start proattivo elimina quel ritardo del primo pacchetto. Ma mantiene un tunnel attivo per traffico che forse non arriverà mai.

Tre fatti decidono la scelta: quanto spesso si usa il percorso, se la prima richiesta ha una scadenza stretta e se il peer è raggiungibile all'avvio. Traffico a lotti occasionale e un peer che può essere offline all'avvio favoriscono entrambi trap. Un client sensibile alla latenza e un peer sempre raggiungibile favoriscono start. Se entrambi i lati possono iniziare, concordate chi possiede il trigger per non avere negoziazioni doppie.

Una policy installata non è nemmeno una garanzia a prova di fuga. Se il requisito è fail-closed, il firewall deve scartare il traffico senza SA, e quella regola vive fuori dalla definizione child.

Annota le tre righe che chiudono la prossima discussione

Scrivi i selettori, l'azione di avvio e l'output del comando che mostra la policy presente senza SA. Quelle tre righe separano «su richiesta e inattivo» da «non si carica» la prossima volta che qualcuno segnala il tunnel come inattivo. Costano un minuto da catturare. Senza di esse la stessa indagine riparte da zero.

Prova da un host che sia davvero dentro il selettore. Un ping dal router stesso segue spesso un percorso diverso e non dimostra nulla sulla policy che protegge la subnet dietro di esso.