Due gateway IPsec senza IP condiviso: cosa fa davvero il failover

Uccidi il gateway A durante una riunione e guarda il tunnel tornare attraverso B un minuto dopo; la connessione funziona, la videochiamata forse no. È la forma onesta del failover a freddo tra due gateway IPsec con indirizzi indipendenti. Il client riseleziona un endpoint e costruisce una nuova relazione, il che ripristina la raggiungibilità senza trasferire lo stato crittografico della vecchia sessione. Ripercorrere la sequenza rende evidente quali promesse il progetto può mantenere.

Prepariamo la scena: due indirizzi, nessun IP flottante

Il gateway A risponde su un indirizzo raggiungibile e il gateway B su un altro. Il client ha un modo approvato di scegliere B quando A è sparito, e non esiste un indirizzo esterno condiviso rivendicato da entrambi i gateway. In questo progetto, un IP virtuale indica quel punto di ingresso condiviso, non l’indirizzo interno assegnato a un client di accesso remoto.

Questa definizione conta perché le due idee si confondono nei ticket, e la correzione dell’una non è la correzione dell’altra. Un rapporto secondo cui l’ingresso condiviso non ha seguito il gateway descrive un progetto. Un rapporto secondo cui il portatile ha perso il suo indirizzo interno descrive il lease del client. Proprietari diversi, log diversi, riparazioni diverse.

Percorriamo il guasto: rilevare, poi riselezionare

Prima qualcosa nota che A ha smesso di rispondere. Può essere il rilevamento di peer morto a livello di tunnel, un protocollo di routing che ritira un percorso, o un timeout applicativo che alla fine forza una riconnessione. Ognuno ha una scala temporale diversa, e il più lento di solito determina quanto attendono gli utenti.

Poi il client seleziona B tramite il meccanismo supportato dalla distribuzione: un secondo remoto configurato, un nome DNS risolto a un indirizzo sano, o un routing che ora preferisce un percorso diverso. La selezione è un passo di politica, e deve esistere prima del guasto o accadrà per caso.

Cosa B può e non può ereditare

B può condividere con A un modello di configurazione, un’autorità di certificazione e una politica di autenticazione. Non può ereditare le associazioni di sicurezza attive. Le chiavi di sessione, gli indici dei parametri di sicurezza e lo stato di sequenza appartengono alla relazione stabilita da A e dal client, e B non ne ha nessuno.

Spostare quello stato tra gateway è un vero problema ingegneristico, per questo la documentazione sull’alta disponibilità di strongSwan lo tratta come un progetto di cluster e non come un flag di configurazione. Una ricetta di cluster particolare non è una risposta generica per una rete cloud, e copiarla senza l’infrastruttura di supporto compra complessità invece di continuità.

Stabilire una nuova relazione

Scelto B, il client esegue un nuovo scambio IKE: nuovi nonce, nuovi valori Diffie-Hellman, nuovi identificatori per le associazioni risultanti. L’autenticazione avviene di nuovo su B. Se il progetto si basa su credenziali macchina, la riconnessione può essere senza supervisione; se richiede un fattore umano, qualcuno deve essere presente perché il failover si completi.

Definisci quell’esperienza utente prima dell’interruzione, non durante. Di’ chiaramente cosa farà il client, quanto a lungo proverà e cosa mostrerà quando si arrenderà, perché la differenza tra un minuto di riconnessione e una chiamata al supporto è di solito documentazione e un profilo collaudato.

Conservare lo stesso indirizzo interno aiuta le applicazioni che si aspettano un’identità locale stabile, e non conserva le loro sessioni. I binding NAT scadono, le connessioni TCP vengono reimpostate e qualsiasi cosa con un proprio timeout decide autonomamente se riprovare.

Due tunnel in parallelo sono un progetto diverso

Eseguire entrambi i tunnel insieme è uno schema valido quando entrambi i gateway e il progetto di routing lo supportano. La selezione del percorso sceglie allora il cammino attivo, e il cammino di ritorno deve essere d’accordo, altrimenti il traffico esce da un gateway e torna dall’altro senza stato che lo abbini.

Politiche tunnel sovrapposte non creano da sole un failover ordinato. Creano due candidati, e qualcosa deve decidere tra loro in modo deterministico, che sia una metrica di routing, una priorità di politica o una preferenza esplicita nel client.

Qualunque forma scegliate, scrivete il contratto: come viene rilevato il guasto, come viene selezionata l’alternativa, quale autenticazione richiede e quanto tempo dovrebbe richiedere la riconnessione. Un IP condiviso può semplificare la scoperta, ma non è sinonimo di stato continuo, e la disponibilità è comunque un progetto.