Failover VPN: quando il percorso di ritorno resta nel vecchio tunnel

Il tunnel di riserva sale, il primario cade e l’applicazione va ancora in timeout. Su entrambi i siti lo stato del tunnel sembra sano, ed è proprio questo a confondere. Un failover che sposta le richieste sulla riserva ma lascia le risposte sul vecchio percorso non è un failover. La guida qui sotto prova il percorso di ritorno, non solo l’handshake.

Registrate prima le rotte su entrambi i lati; una vista da un solo sito non può mostrare un percorso asimmetrico. È anche il passo che più spesso viene saltato sotto pressione di tempo.

Registrate le rotte di entrambi i siti prima del test

Per ogni prefisso protetto, scrivete la rotta primaria, la rotta di riserva e la preferenza che sceglie tra loro. Includete il gateway LAN dietro ogni endpoint VPN, perché l’endpoint è raramente l’ultimo salto.

Le metriche statiche, le rotte monitorate e il routing dinamico esprimono l’idoneità in modi diversi. Sappiate quale usa il vostro progetto, e cosa serve perché l’alternativa diventi attiva. Scrivete la condizione accanto alla rotta, per esempio una metrica più bassa finché la sonda non fallisce.

Fatelo su entrambi i siti. Una riserva preferita da un lato e ignorata dall’altro produce esattamente l’asimmetria che cercate di evitare.

Osservate richieste e risposte in ogni fase

Usate un’applicazione permessa e innocua e osservate tre fasi: normale, guasto del primario e ripristino. In ogni fase, registrate quale tunnel porta la richiesta e quale la risposta. Un indirizzo peer raggiungibile non dimostra che il percorso protetto dell’applicazione funzioni. Registrate su entrambi i siti perché un flusso unidirezionale sia visibile.

Se le richieste si spostano e le risposte no, controllate la rotta del sito remoto verso il prefisso del client e la sua preferenza per la riserva. È una decisione di routing, non un guasto del tunnel.

Ripristinate la condizione originale dopo il test e confermate che il primario sia di nuovo preferito. Un primario ripristinato che non è preferito è un progetto di failover non finito.

Gestite lo stato della sessione quando cambia il gateway

I firewall e il NAT possono mantenere lo stato della connessione su un gateway, e un cambio di percorso verso un altro gateway non lo trasporta. Alcune applicazioni si riconnettono da sole; altre falliscono finché la sessione non viene ristabilita. Se la riserva cambia la sorgente pubblica o l’indirizzo privato tradotto, anche le regole di accesso remoto possono reagire. Documentate ogni riavvio di sessione atteso invece di promettere un failover senza interruzioni.

Mantenete un indirizzamento stabile dove l’applicazione lo richiede. Un progetto di failover che cambia l’indirizzo sorgente a ogni sessione è una scelta di progetto, e va scritta. Quella scelta determina quanta parte dell’interruzione gli utenti notano davvero.

Provate un’applicazione che mantiene una sessione lunga, non solo una richiesta nuova.

Ripristinate il primario e controllate l’oscillazione

Confermate che gli annunci di rotta o le preferenze si stabilizzino senza oscillare. Un primario che oscilla può essere più dirompente di un’interruzione chiara, perché ogni transizione azzera lo stato.

Mantenete raggiungibile l’amministrazione del gateway tramite un percorso di ripristino, così il test stesso non vi chiuda fuori. Registrate le fasi, i percorsi osservati e il tempo di ripristino; quel registro è ciò che rende prevedibile il prossimo failover. Le note di strongSwan sull’inoltro sono utili quando gli endpoint sono host Linux.