Un profilo strongSwan caricato non è un tunnel attivo

Elencare una connessione nella configurazione di strongSwan dimostra solo che una definizione è stata caricata. Non significa che il peer sia stato contattato, che esista una SA IKE o che del traffico sia protetto. Il demone tratta definizioni e associazioni attive come oggetti separati, e la distanza tra loro è una scelta di progetto deliberata. Sapere quale oggetto stai ispezionando trasforma un guasto vago in un comando successivo preciso.

Caricare non è connettere

Una connessione caricata è un’affermazione su ciò che potrà essere negoziato in seguito: indirizzi dei peer, credenziali, proposte e selettori di traffico. Nulla in quell’affermazione obbliga il demone ad aver chiamato qualcuno. Un gateway può attendere l’altro lato, avviare all’accensione o attendere che un traffico corrispondente lo svegli. Tutte e tre sono valide, e tutte e tre appaiono identiche nel file di configurazione finché non leggi la politica di avvio.

Gli operatori finiscono nei guai leggendo l’elenco delle definizioni come un elenco di stato. Il profilo c’è, quindi il tunnel è dato per attivo, e l’ora successiva se ne va a fare debug delle route per un’associazione che non è mai stata costruita.

L’errore opposto è altrettanto comune. Un profilo mancante manda le persone a cercare un guasto di rete quando la configurazione non è mai stata caricata. Nomina l’oggetto, poi esegui il comando che lo osserva.

Tre oggetti, tre osservazioni

strongSwan mantiene una definizione caricata, una SA IKE e una SA CHILD. La prima è configurazione, la seconda una relazione di controllo autenticata e la terza protezione negoziata per il traffico selezionato. Hanno persino nomi separati, così un profilo chiamato hq può possedere un child chiamato hq-lan.

La tabella associa ogni livello al comando che lo mostra. Leggi la riga prima di leggere il log.

Richiedere il child costruisce prima la sua SA IKE padre quando non ne esiste nessuna. Richiedere solo la SA IKE è una chiamata diversa. Un canale di controllo che si autentica bene non garantisce il child che hai chiesto.

Questa differenza conta durante un guasto parziale. Una SA IKE può essere sana mentre il child fallisce per una discrepanza di selettore o una proposta che il peer non accetta. I due oggetti falliscono per motivi diversi, quindi meritano osservazioni separate.

Scegli l’azione di avvio con intenzione

In swanctl.conf, lo start_action di un child decide il comportamento dopo il caricamento. Il valore predefinito none lascia la definizione all’avvio manuale o all’uso come responder. start la compone, mentre trap lascia una politica che negozia non appena compare traffico corrispondente.

Quindi sia «il caricamento non avvia mai un tunnel» sia «il caricamento ne avvia sempre uno» sono sbagliati. L’azione fa parte del profilo e deve corrispondere al ruolo del peer. Due gateway che attendono entrambi l’altro lato producono silenzio, non un tunnel.

Con trap il traffico deve corrispondere ai selettori, quindi un ping estraneo non sveglierà nulla. Con start l’indirizzo del peer deve essere utilizzabile ed entrambi i lati devono concordare autenticazione e proposte. Nessuna delle due azioni sostituisce la verifica di questi presupposti.

Il ripristino è una politica separata

L’avvio non è un keepalive. Rilevamento del peer morto, chiusura esplicita da parte del peer, rinnovo delle chiavi e riavvio del processo sono eventi del ciclo di vita diversi, con impostazioni proprie. Configura ognuno in modo deliberato invece di aspettarti che un avvio iniziale li copra tutti.

Un tunnel che sale all’avvio e muore un’ora dopo è una questione di ripristino. La politica di avvio ha fatto il suo lavoro e poi ha smesso di contare. Guarda le impostazioni DPD e di rinnovo delle chiavi prima di dare la colpa alla negoziazione iniziale.

Sostituire definizioni caricate è un’operazione a sé. Le politiche di avvio non predefinite hanno azioni inverse documentate, e un ricaricamento è un cambiamento operativo anziché il presupposto che ogni associazione sia stata aggiornata sul posto. Esegui i ricaricamenti a fasi, dove una riconnessione è accettabile. Mantieni la vecchia configurazione finché la nuova non è dimostrata.

Controlla cosa esiste prima di fare debug del routing

Esegui le tre osservazioni in ordine: definizioni caricate, SA IKE attive e voci child. Ogni risposta restringe la domanda successiva. Salta un passaggio e finirai per fare debug di un livello che non è mai stato costruito.

Parti da ciò che è caricato e da ciò che è realmente stabilito:

swanctl --list-conns
swanctl --list-sas

Se il child manca mentre il profilo è corretto, avvialo per nome e osserva cosa succede. L’output di solito dice se il padre è salito prima.

swanctl --initiate --child hq-lan

Una SA CHILD attiva non è il traguardo. Regole di inoltro, route e l’autorizzazione propria dell’applicazione devono ancora combaciare. Il ciclo di vita risponde a cosa è stato negoziato; non può decidere chi può usare il servizio.