Tre tipi di failover OpenVPN su pfSense, tre meccanismi

«Il failover OpenVPN» su pfSense copre almeno tre progetti non correlati, e ognuno richiede un meccanismo diverso. Mantenere vivo un tunnel attraverso un collegamento internet di riserva, riconnettersi a un altro server e indirizzare il traffico LAN verso un altro tunnel già stabilito non sono varianti di una sola funzione. Scegliete il guasto da cui vi state difendendo prima di costruire un gruppo di gateway. Il gruppo che ne risolve uno non fa nulla per gli altri due.

Nominate il guasto prima di costruire un gruppo

Scrivete la frase che volete vera durante un’interruzione. «Il tunnel si riconnette sul WAN di riserva» e «la filiale continua a raggiungere l’applicazione attraverso l’altro tunnel» sono frasi diverse. Solo la prima riguarda il trasporto.

Poi abbinatela a un meccanismo. La perdita del WAN locale è un problema di scelta dell’interfaccia, un endpoint remoto morto è un problema di elenco delle connessioni, e un percorso inutilizzabile dentro un tunnel stabilito è un problema di instradamento e di politica.

WAN locale: spostare il trasporto

Per un client OpenVPN su pfSense, la disposizione multi-WAN supportata seleziona un gruppo di gateway adatto come interfaccia a cui il client si lega. È questo che permette alla connessione esterna di uscire sul collegamento di riserva quando il primario cade. Da sola non cambia come viene instradato il traffico interno.

Il lato server dello stesso progetto è separato. Un server OpenVPN che deve essere raggiungibile su più indirizzi pubblici ha bisogno di un listener e di una politica di ingresso per ciascuna di quelle voci, non solo di un client che sappia comporre su due collegamenti. Una voce pubblica funzionante non è prova che la seconda sia configurata.

Una regola di instradamento basata su politica per i pacchetti LAN inoltrati non è l’impostazione che sposta una connessione di trasporto VPN generata localmente. Sono due ricerche diverse, e cambiare l’una non cambia l’altra.

Endpoint remoto: un altro server

Un remote alternativo è una funzione dell’elenco delle connessioni. Il client prova la voce successiva quando quella corrente non risponde, il che è utile quando è giù un host specifico e non quando è giù il vostro uplink. I due guasti sembrano simili dalla scrivania di un utente e richiedono correzioni diverse.

Ogni candidato deve essere un vero sostituto: autenticazione compatibile, politica client compatibile e accesso alle stesse risorse private. Un secondo hostname che risolve sulla stessa infrastruttura guasta non è una riserva. Un server senza la rotta richiesta non lo è nemmeno, per quanto sano sembri il suo handshake.

Questo meccanismo non fa nemmeno inoltrare due tunnel insieme. Sostituisce una connessione con un’altra, in sequenza, e il vuoto tra le due è visibile a tutto ciò che stava girando.

Percorso del tunnel: scegliere un’altra uscita

Quando due tunnel sono già attivi e volete che il traffico usi quello più sano, il meccanismo è un’interfaccia VPN assegnata con il proprio gateway, più una regola di politica esplicita che manda lì il traffico giusto. Un gruppo di gateway su quelle interfacce assegnate può esprimere priorità e monitoraggio.

Quel progetto riguarda la selezione, non il ripristino. Spostare nuove connessioni sul secondo tunnel non dice nulla sulle sessioni già stabilite sul primo, né se il lato remoto accetterà il nuovo indirizzo sorgente. Trattarlo come meccanismo di ripristino è il modo per fissare aspettative troppo alte.

Se il requisito è che le sessioni esistenti sopravvivano, ditelo esplicitamente. La maggior parte delle implementazioni non migra un flusso vivo tra tunnel, e progettare come se lo facessero produce un failover che sembra corretto in un diagramma e in pratica lascia cadere ogni connessione aperta.

Monitor, NAT e la regola fail-closed

Un monitor dovrebbe testare qualcosa che il tunnel è destinato a fornire. Un target che risponde dal peer del tunnel ma non dalla rete applicativa oltre riferirà sano mentre gli utenti non vedono nulla. Un target diagnostico irraggiungibile riferirà morto mentre il percorso è a posto. Scegliete l’indirizzo deliberatamente e confermate che è raggiungibile solo attraverso il tunnel previsto.

Controllate il NAT in uscita per entrambe le uscite. Una traduzione funzionante sul primario non descrive l’indirizzo sorgente della riserva, e la rete privata remota ha bisogno di una rotta di ritorno che corrisponda alla sorgente che presentate. Una traduzione corretta su un percorso può essere silenziosamente sbagliata sull’altro.

Poi decidete cosa succede al traffico che non deve mai usare il WAN. pfSense ha un comportamento definito per le regole il cui gateway selezionato è giù, e una regola di passaggio ampia successiva o una rotta predefinita possono annullare la vostra intenzione. Scrivete l’esito bloccato come requisito, poi verificatelo abbattendo il percorso.

Provate perdita e ripristino separatamente, con traffico che siete autorizzati a generare, e osservate tre cose insieme: il WAN che porta la connessione esterna, il tunnel che porta la richiesta dell’applicazione e il percorso che prende la risposta. Una coppia di indicatori di gateway verdi non è una di quelle tre. La guida multi-WAN di Netgate descrive il binding del trasporto e le alternative client esportate da cui questo dipende.