Uno su, zero in connessione: cosa conta in realtà quella riga di strongSwan

Leggete una riga di stato che dice Security Associations (1 up, 0 connecting) e sembra il resoconto di un tunnel funzionante. Due sottoreti vi fanno passare traffico nello stesso momento, quindi il numero sembra mentire. Non mente; conta le associazioni IKE, e una di esse può ospitare più figlie. Leggete gli inventari prima di toccare una proposta o una rotta.

Perché il titolo e il traffico non concordano

La vecchia uscita stroke chiama il suo totale associazioni di sicurezza e lo deriva dal gestore delle associazioni IKE. Ogni associazione IKE stabilita ne aggiunge una, indipendentemente da quante CHILD SA stanno sotto. Un solo padre IKEv2 porta di solito più figlie, una per coppia di selettori di traffico, e i selettori negoziati di una figlia possono coprire più di un indirizzo o prefisso. Il numero di indirizzi nella vostra configurazione non ha quindi un rapporto fisso con il numero del titolo.

L’uscita moderna a volte mostra un totale invece della vecchia formulazione “up”, e un demone gestito da swanctl non è affatto guidato dalle vecchie impostazioni stroke. Non date per scontati né la formulazione né la regola di conteggio tra versioni.

Confrontate tre inventari prima di cambiare qualsiasi cosa

Cominciate da ciò che è caricato, poi da ciò che è negoziato, poi da ciò che sposta davvero pacchetti. Sono tre domande diverse e ciascuna ha il proprio comando.

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

La prima elenca le definizioni di connessione che il demone ha accettato. La seconda elenca le associazioni IKE stabilite con le loro figlie, ed è lì che appare la gerarchia reale. Una definizione presente in un file ma assente dal primo elenco non è mai stata caricata, e nessun numero di nuovi tentativi dell’iniziatore lo risolverà. Se invece usate l’interfaccia vecchia, la coppia equivalente è ipsec statusall e lo stesso elenco swanctl, a seconda di quale plugin possiede la configurazione. Non mescolate strumenti tra due demoni su un solo host e non aspettatevi un’unica risposta coerente.

swanctl --list-sas --raw | head -40
ip -s xfrm state

La forma grezza tiene visibili identificatori e selettori per il confronto, e l’elenco dello stato del kernel mostra cosa la pila ritiene di aver installato. Quando il demone e il kernel non concordano, o il demone è stato riavviato attorno a una figlia esistente, o l’oggetto del kernel è stato rimosso sotto di essa.

Leggete la gerarchia, non il totale

Un padre stabilito illustrativo con due figlie sembra un solo nodo con due figlie sotto, ciascuna etichettata con il proprio stato e modo. Scaricate l’uscita reale e contate le figlie voi stessi invece di leggere un riepilogo che qualcuno ha incollato da una dashboard.

swanctl --list-sas
swanctl --list-conns --raw | grep -A4 'accounting'

Un padre con due figlie installate è un tunnel sano per due sottoreti. Un padre con una figlia installata e una assente è un’altra situazione, e i selettori della figlia mancante sono ciò che va confrontato con la proposta del lato remoto. Durante il rinnovo delle chiavi, una figlia vecchia e il suo sostituto possono comparire insieme per una breve finestra. Tenete la marca temporale con l’istantanea, perché un conteggio preso a metà rinnovo sembra duplicazione e uno preso dopo sembra perdita.

Caricato, installato e traffico che passa

Una figlia in stato installato ha parametri negoziati e una voce nel kernel. Ma non necessariamente ha trasportato un pacchetto: i selettori possono essere più stretti del traffico che vi aspettate, e una rotta può mandare quel traffico altrove prima che il tunnel lo veda. Inviate un flusso che corrisponde ai selettori negoziati da un host autorizzato, poi leggete i contatori della figlia invece del titolo. Un contatore che resta a zero mentre generate traffico corrispondente indica l’instradamento o la politica, non IKE.

swanctl --initiate --child accounting
swanctl --list-sas --raw | grep -E 'bytes|packets'

Avviare una figlia con nome è un’azione deliberata con un risultato visibile, e separa “la connessione è inattiva perché nessuno l’ha chiesta” da “la connessione non può salire”. Una politica trap su richiesta si comporta esattamente come il primo caso, quindi leggete l’impostazione di avvio della connessione prima di chiamarlo guasto.

Quando il conteggio è davvero sbagliato

Se manca una definizione nell’inventario caricato, guardate il caricamento della configurazione e quale istanza del demone è in esecuzione. Se è caricata ma non negozia mai, confrontate proposte, contesto di autenticazione e selettori con il pari, una figlia alla volta. Cambiate un elemento per tentativo e annotate l’identificatore che avete cambiato. Riportare indietro una proposta è banale quando sapete quale; è un’ipotesi dopo tre modifiche che non sono mai state separate.

Correggete prima la lettura sbagliata. La maggior parte delle segnalazioni di un secondo tunnel “mancante” finisce con due figlie installate sotto un solo padre, e l’unica cosa che sia mai stata rotta era la riga di riepilogo di cui le persone si fidavano invece della gerarchia.