Secondo endpoint VPN: cosa copre e cosa no

Due endpoint sulla carta sembrano ridondanza. In pratica un secondo indirizzo aiuta solo se i client possono raggiungerlo e se evita il guasto a cui vi state preparando. Due server dietro la stessa connessione di accesso, lo stesso account o la stessa rete di destinazione cadono insieme. La domanda utile è quale singolo guasto elimina il secondo endpoint.

Confrontate ciò che i due endpoint condividono

Elencate ciò che i due endpoint hanno in comune prima di contare ciò che duplicano. La posizione di hosting, l’account del fornitore, il transito a monte, l’hosting DNS, la fonte di identità e la risorsa privata dietro il tunnel rappresentano ciascuno una dipendenza condivisa o indipendente. Due macchine virtuali in una regione condividono un guasto del fornitore. Due regioni sotto un solo account condividono ancora il rapporto di fatturazione e il piano di controllo che le crea.

La rete di destinazione merita lo stesso trattamento. Un gateway di riserva sano non può ripristinare un NAS offline, né raggiungere una rete di ufficio il cui collegamento a monte è caduto. Se entrambi gli endpoint terminano nella stessa sottorete privata, il secondo aggiunge solo un percorso verso una destinazione che è già l’unico punto di guasto.

L’identità è la dipendenza che si dimentica. Clonare il certificato e la configurazione su un secondo host crea due luoghi in cui la stessa credenziale può essere copiata, e non dice nulla su come le revoche raggiungono entrambi.

Decidete come cambia un client

Un secondo endpoint è utile solo se il client lo conosce e può selezionarlo senza chiamare l’assistenza. I profili di connessione OpenVPN possono contenere più righe remote con una politica di selezione, e la maggior parte dei client offre un profilo alternativo in un menu. Qualunque sia il meccanismo, annotate quale hanno i vostri utenti, perché un profilo che non trovano non è un failover.

Leggete la documentazione del client sui cambi di indirizzo durante una sessione. Alcune implementazioni mantengono il peer originale per tutta la vita del tunnel e consultano le alternative solo alla riconnessione. Questa distinzione decide se un endpoint morto produce una breve interruzione o una sessione che non si riprende mai. Provate il percorso di riconnessione invece di dare per scontato che avvenga.

Un indirizzo di uscita cambiato rompe anche lo stato dell’applicazione. Il failover è ripristino, e descriverlo come continuità ininterrotta crea un’aspettativa che il trasporto non può soddisfare.

Provate un guasto reale

Scegliete un’interruzione controllata ed eseguitela dall’inizio alla fine, invece di fidarvi del documento di progettazione. Fermate l’endpoint primario, poi confermate che un client autorizzato raggiunge l’applicazione prevista tramite l’alternativa mentre i client non autorizzati ancora non possono. Annotate quanto è durato il cambio e cosa ha visto l’applicazione.

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

Il primo comando conferma che il nome di riserva si risolve in qualcosa di instradabile prima che vi serva, ed è il test più economico qui. Il secondo mostra quale interfaccia userebbe il kernel per una destinazione privata una volta attiva l’alternativa. Il terzo fornisce il log del client con il nome del peer a cui si è realmente connesso, ed è l’unica prova che il cambio è avvenuto. Osservate anche il comportamento di blocco durante il vuoto, perché una politica che perde traffico durante il cambio è peggiore di una breve interruzione.

Poi riportate l’originale e confermate se il client torna. Un rientro che avviene per caso è un comportamento che nessuno ha pianificato.

Annotate cosa compra il secondo indirizzo

Riassumete la copertura in un paragrafo: quale guasto elimina il secondo endpoint, quali guasti condivide con il primo e su quali ipotesi si basa il cambio. Nominate il meccanismo lato client insieme alle rotte private e al comportamento DNS che devono esistere in entrambi i siti. Un’uscita internet pubblica non sostituisce un gateway privato, e un documento che li tratta come intercambiabili sarà creduto. Aggiungete il test di ripristino che avete eseguito, con la data e il risultato.

L’indipendenza da un server non è indipendenza dall’account condiviso o dalla rete di destinazione. È il paragrafo che lo dice ad alta voce a impedire che un secondo indirizzo venga venduto internamente come alta disponibilità. Indica anche al prossimo operatore cosa controllare per primo quando la coppia cade insieme.