strongSwan resta giù dopo il riavvio del peer: recuperare un tunnel

Il gateway remoto si riavvia, torna entro un minuto, e il demone strongSwan locale continua a girare con il tunnel ancora giù. Un lavoro cron che fa grep di ESTABLISHED e riavvia il demone finirà per mascherare tutto questo, e interromperà anche ogni tunnel non correlato sulla macchina, rischiando di mancare proprio quello che ha fallito. Il recupero appartiene alla connessione che deve tornare, espresso in impostazioni che sopravvivono a un reload. Questo runbook lo prepara per una sola connessione e dimostra il risultato per nome.

Ritirate il riavvio globale, conservate le sue prove

Un riavvio del demone ha due difetti precisi: distrugge lo stato di ogni connessione e non vi dice nulla su quale evento sia realmente fallito. Il testo di stato che avete cercato può essere arrivato da un’altra connessione, mentre il child richiesto restava inattivo perché nulla lo aveva attivato.

Leggete le connessioni caricate e le associazioni attive prima di cambiare qualcosa, così avete un’immagine di prima con cui confrontare al ritorno del peer.

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

Mettete l’avvio e i tentativi sulla connessione che torna

In un deployment con swanctl.conf queste impostazioni vivono a livello di connessione e di child, non in una policy globale. Il frammento qui sotto è un esempio lato iniziatore che presuppone che proposte, autenticazione e selettori siano già corretti.

connections {
    branch {
        keyingtries = 0
        dpd_delay = 30s
        children {
            private-lan {
                start_action = trap|start
                dpd_action = restart
            }
        }
    }
}

start_action decide cosa accade quando il child viene caricato: start avvia subito, mentre trap installa una policy che fa scattare l’avvio quando compare traffico corrispondente. Scrivere trap|start richiede strongSwan 5.9.6 o successivo, quindi controllate la versione prima di copiare la riga. dpd_action=restart chiede una nuova negoziazione appena il peer viene dichiarato morto, e keyingtries=0 a livello di connessione consente altri tentativi fino al successo o a un errore permanente. Con IKEv2, dpd_timeout non ha alcun effetto, perché è la ritrasmissione ordinaria a decidere quando il peer non risponde.

Il ritardo di quell’esempio è un punto di partenza, non una scadenza universale. Sceglietelo in base a quanto dura il riavvio del peer e a quanta ritrasmissione siete disposti a sopportare.

Sappiate da quale evento state recuperando

Tre guasti sembrano identici su una dashboard e richiedono impostazioni diverse. Una connessione iniziale che non è mai salita è un problema di configurazione o di raggiungibilità. Un peer che ha smesso di rispondere è il caso DPD. Un child che il peer ha chiuso esplicitamente è un evento di policy con il proprio close_action, che il DPD non osserva mai. Leggere il log intorno all’interruzione vi dice quale dei tre avete, e la risposta cambia la correzione.

Non aggiungete ri-avvio aggressivo a una connessione che gli operatori chiudono di proposito per manutenzione, altrimenti il tunnel riappare a metà della finestra. Per i progetti su richiesta basta un trap conservato, perché il traffico corrispondente ristabilisce il child senza alcun timer.

Verificate per nome, non per stato del demone

Leggete la connessione e il suo child per nome mentre il peer è ancora giù, poi di nuovo quando torna; la differenza tra questi due output è la prova.

swanctl --initiate --child private-lan
swanctl --terminate --ike branch

Poi confermate il servizio anziché l’associazione. Un’associazione di sicurezza child nuova più una richiesta riuscita alla destinazione privata dietro di essa sono la coppia di fatti che conta, e un demone in esecuzione con un tunnel non correlato sano non dimostra nessuna delle due.

Se il child non si avvia mai, verificate che il traffico di test corrisponda esattamente ai selettori configurati, protocollo e porta inclusi. Se si avvia e fallisce, leggete l’errore di autenticazione o di proposta invece di nasconderlo dietro un ciclo infinito, perché keyingtries=0 ripeterà volentieri un rifiuto permanente per sempre.

Caricate la modifica in una finestra e riprovate

Ricaricare è più sicuro che riavviare il demone, e comunque non è gratis: sostituire o scaricare un child può chiudere un’associazione avviata o far cadere il suo trap.

Caricate durante una finestra di manutenzione, conservate il file precedente e confermate che la connessione compaia con le impostazioni volute e non con i valori predefiniti.

swanctl --load-conns
swanctl --list-conns

Tornate indietro ripristinando il file precedente e ricaricandolo, poi ripetete gli stessi due comandi. Un tunnel che torna solo dopo un riavvio del demone non è riparato, è reimpostato.