Tempesta di riconnessione nella filiale: limiti di ammissione di strongSwan

Osservate una filiale tornare dopo un guasto del collegamento e il gateway vede qualcosa che non appare mai in una giornata normale: decine di portatili arrivano insieme da un unico indirizzo pubblico. Ognuno è un dispositivo legittimo e ognuno avvia uno scambio IKE non ancora concluso. Il successo di quella raffica dipende da limiti che non hanno nulla a che vedere con quanti dipendenti il server può reggere. La raffica è breve, ed è proprio il carico di lavoro per cui è stato costruito il percorso di ammissione.

Seguite un portatile che rientra nella rete

Il client invia una richiesta iniziale e attende, e finché lo scambio non è completo il gateway conserva lo stato di ammissione per quel tentativo. Altri dispositivi dietro lo stesso indirizzo arrivano mentre il primo attende ancora, e si mettono in coda dietro un limite che conta gli indirizzi invece degli utenti. Dall'esterno il sintomo è una manciata di utenti che si connettono e un gruppo più ampio che va in timeout.

Niente in quella sequenza è un guasto. È il percorso di ammissione che fa ciò per cui è stato configurato.

Contate il lavoro semiaperto come risorsa a sé

strongSwan separa due popolazioni: associazioni pienamente stabilite e tentativi che ancora si connettono o attendono di essere elaborati. La soglia di blocco si applica alle associazioni semiaperte attribuite a un indirizzo peer, e le soglie dei cookie si applicano globalmente e per indirizzo. Quei contatori proteggono il demone dall'essere consumato da lavoro non autenticato, che è esattamente la forma di una tempesta di riconnessione. Niente di quello stato appare in un elenco di tunnel stabiliti.

Leggerli come un tetto alle sessioni dei dipendenti è l'errore che porta ad alzare tutto insieme. Un server che porta quattrocento tunnel stabiliti non è automaticamente in grado di assorbire quattrocento primi pacchetti simultanei, perché i due costi cadono in punti diversi.

La latenza di autenticazione decide quanto a lungo ogni tentativo resta nel conteggio dei semiaperti. Un backend che risponde lentamente trasforma una raffica breve in una coda lunga anche quando il tasso di arrivo è modesto.

swanctl --stats
swanctl --list-sas | grep -c ESTABLISHED

Leggete le impostazioni di ammissione prima di cambiarle

Trovate i valori che il demone in esecuzione ha effettivamente caricato prima di formarvi un'opinione. La configurazione è spesso divisa tra un file principale e una directory di frammenti per plugin, quindi un valore impostato in un punto può essere sovrascritto altrove. La ricerca qui sotto mostra ogni file che menziona queste impostazioni.

Poi decidete quale numero è troppo piccolo. Se un indirizzo rappresenta legittimamente un intero ufficio, la soglia di blocco per indirizzo è il valore che deve accogliere quella concentrazione. Una soglia cookie globale protegge il demone da un'inondazione più ampia e non va allentata perché un sito si riconnette. Confrontate quel valore per indirizzo con il sito più grande che avete davvero.

Lasciate attivo il meccanismo dei cookie. I cookie obbligano un client a dimostrare di poter ricevere all'indirizzo che dichiara prima che il demone spenda lavoro reale nello scambio, e disattivarli non è un aggiornamento di capacità neutro. Alzate una soglia solo con un tasso di arrivo misurato e un budget di autenticazione dichiarato dietro.

grep -rn -E 'block_threshold|cookie_threshold' /etc/strongswan.conf /etc/strongswan.d/
swanctl --stats | grep -i half

Pianificate il ritorno, non solo lo stato stazionario

Un obiettivo di disponibilità che conta solo le sessioni stabilite descrive un pomeriggio tranquillo, non un ripristino. Chiedetevi invece come torna la popolazione prevista dopo un evento di rete condiviso, e se il percorso di ammissione può assorbire quella forma.

Distribuire la riconnessione su una flotta gestita è spesso più economico che ampliare i limiti, perché elimina la raffica artificiale invece di pagarla in permanenza. Monitorate lo stato semiaperto e gli eventi di ammissione accanto alle stabilizzazioni riuscite, e trattate un conteggio semiaperto crescente con successi piatti come un avvertimento precoce e non come una curiosità.

Il riferimento del fornitore per queste impostazioni è la documentazione di strongswan.conf, che nomina i contatori e la versione che ha introdotto la soglia cookie per indirizzo. Leggete la sezione della vostra versione installata invece della pagina più recente, perché i valori predefiniti si spostano tra le versioni.