La seconda voce VPN WAN fallisce mentre la principale continua a funzionare

Il tunnel principale resta attivo, gli utenti continuano a lavorare e il secondo circuito ISP resta inattivo qualunque cosa cambiate. Avete pubblicato un indirizzo per il circuito di riserva, ci avete puntato un nome, magari avete aggiunto una voce di riserva al client, e il client o non la prova mai o si autentica e poi muore. Nei casi che ho seguito, la funzione di failover era di solito a posto; mancava una delle cinque cose che rendono utilizzabile una voce. Un nome può risolversi all'indirizzo di riserva mentre su quell'interfaccia non ascolta nulla, e un listener può accettare una connessione mentre la risposta esce dalla principale. Trattate ogni WAN come una voce separata con il proprio contratto e il guasto smette di sembrare un bug del client.

Ogni WAN ha bisogno del proprio contratto di voce

Annotate cinque campi per WAN: il nome e l'indirizzo pubblici, il trasporto e la porta, l'interfaccia o il contesto che la termina, l'identità del peer che deve presentare e da dove esce la risposta. Due circuiti significano due insiemi completi. Se il secondo insieme non ha interfaccia di terminazione né percorso di ritorno, non avete una voce di riserva; avete un record DNS che descrive un'intenzione.

Anche l'apparato e la sua versione devono supportare questa disposizione. Un record DNS non può aprire un servizio su un'altra interfaccia, e su molte piattaforme il listener si configura per indirizzo e non per dispositivo. L'IPsec basato sull'interfaccia su un ASA lega le mappe crittografiche e i gruppi tunnel all'interfaccia esterna, quindi un secondo uplink ha bisogno di una policy dove quei pacchetti arrivano davvero. I progetti basati su rotte si comportano diversamente: il listener può legarsi a ogni indirizzo o a un indirizzo con nome, e quella scelta decide se l'ISP B può rispondere del tutto.

Verificate che il secondo WAN risponda davvero

Provate dall'esterno di entrambi i circuiti, non da una macchina dietro il gateway, e provate esattamente il nome che usa il profilo del client. Per un listener TLS, il controllo rapido è openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts eseguito da un host fuori dalla vostra rete. Volete una stretta di mano completata la cui catena corrisponda al nome nel profilo, non solo una porta TCP che accetta una connessione.

RFC 9525 spiega cosa verifica il client: l'identità che intendeva raggiungere, confrontata con il certificato che il servizio presenta. Una seconda voce che restituisce il certificato della voce principale, o un certificato predefinito che non elenca nessuno dei due nomi, fallisce questo test anche se la porta è aperta e il firewall lo consente.

Due schemi spiegano la maggior parte dei guasti qui. Una connessione che resta appesa di solito significa nessun listener su quell'interfaccia, una regola di accesso che consente solo le sottoreti principali, o un apparato dell'operatore davanti al secondo circuito che scarta la porta. Una stretta di mano che termina con l'identità sbagliata di solito significa un altro trustpoint, un host virtuale predefinito o una configurazione copiata dalla principale senza adattare l'identità.

Seguite la risposta, non solo la richiesta

Il secondo WAN si rompe di solito al ritorno. Una richiesta arriva dall'ISP B, l'apparato risponde e la risposta esce dalla rotta predefinita sull'ISP A con un indirizzo di origine che il client non ha mai chiesto. La traduzione con stato peggiora le cose: se la mappatura è stata costruita per l'interfaccia principale, il pacchetto di ritorno manca la traduzione o porta un'origine che il firewall del client scarta. I provider scartano anche gli indirizzi di origine che non appartengono al circuito che vi hanno dato, ed è per questo che sembra un buco nero unidirezionale invece di un errore di protocollo pulito.

Controllate la decisione di routing per il traffico originato dalla seconda voce. La risposta deve uscire dall'interfaccia su cui è arrivata la richiesta, o almeno portare un indirizzo che il lato remoto accetta come appartenente a quel percorso. Sulle piattaforme di routing per policy questo significa una regola legata all'interfaccia in ingresso o all'origine tradotta, più un'istruzione di traduzione legata a ogni interfaccia esterna. Catturate contemporaneamente su entrambe le interfacce mentre il client si connette; un SYN che arriva sull'ISP B con il SYN-ACK che esce sull'ISP A risolve la questione in una sola passata.

Date al client un modo per conoscere la seconda voce

Il failover è una decisione lato client, e ogni famiglia di client scopre le alternative in modo diverso. Su un ASA l'elenco dei server di riserva viene consegnato tramite gli attributi webvpn della policy di gruppo, mentre altri client si aspettano un elenco nel profilo o un secondo profilo manuale scelto dall'utente. La guida alle policy di connessione di Cisco descrive sia le informazioni di riserva configurate nel client sia quelle fornite dal gateway, e questi dettagli specifici del protocollo non vanno generalizzati a ogni client o modalità tunnel. Confermate quale meccanismo implementa il client distribuito prima di costruire la seconda voce attorno a quello sbagliato.

Qualunque sia il meccanismo, il client deve poter risolvere il nome alternativo prima di perdere il percorso principale. È questa dipendenza che la gente trascura: se il nome di riserva è risolto da un resolver raggiungibile solo attraverso il tunnel appena fallito, il fallback non può nemmeno iniziare. Pubblicate il secondo nome in un resolver che risponda localmente o via internet. Aspettatevi una nuova autenticazione e una nuova sessione applicativa dopo il passaggio, perché il failover del client non è failover con stato e le sessioni lunghe non gli sopravvivono.

Un indirizzo su due provider è un altro prodotto

Mantenere un solo indirizzo pubblico raggiungibile attraverso entrambi i circuiti è un servizio di routing, non una casella nel VPN. Richiede spazio di indirizzamento che entrambi i provider siano disposti a trasportare, annunciato in modo che le loro reti lo accettino, ed è ciò che offre il multihoming con spazio indipendente dal provider e BGP. Assegnare l'indirizzo dell'ISP A all'interfaccia dell'ISP B non porta lì; il pacchetto arriva a una rete che non ha mai annunciato il prefisso e viene scartato a monte.

Non vi serve nulla di tutto ciò per pubblicare due voci. Se il client può tenere due nomi e passare dall'uno all'altro, due voci indipendenti bastano, e evitate un numero AS, un accordo di peering e un prefisso che deve essere accettato ovunque. Considerate l'opzione dell'indirizzo portabile solo quando avete davvero bisogno di un unico punto d'ingresso stabile che i client non possano essere riconfigurati a sostituire, o quando il failover basato su DNS con il suo ritardo TTL è troppo lento per l'interruzione contro cui progettate.

Cosa controllare dopo

Lavorate verso l'esterno dalla voce che fallisce in questo ordine: il secondo indirizzo risponde dall'esterno, presenta l'identità che il client si aspetta, la risposta esce per il percorso da cui è arrivata la richiesta, e il client può apprendere il nome prima di averne bisogno. Dove la risposta è no, correggete quello strato e riprovate con il profilo distribuito e non con un host di test, perché una stretta di mano di laboratorio dimostra meno di una connessione completata dal client reale.

Tenete una scheda breve per WAN, con indirizzo, porta, interfaccia di terminazione, nome del certificato, percorso di ritorno e regola di traduzione, e ricontrollatela ogni volta che cambiano un circuito, un dispositivo NAT o una versione del client. I percorsi di riserva inattivi marciscono in silenzio: nulla avverte della voce che nessuno usa fino al giorno in cui tutti ne dipendono.