Una VPN cloud ha bisogno di BGP: perché gli altri protocolli di routing falliscono

L'associazione di sicurezza IPsec è attiva, i contatori del tunnel si muovono e il traffico verso il prefisso cloud scompare. L'operatore prova allora ad abilitare OSPF sul router del cliente, aspettandosi che il vicino si formi, e non succede nulla. Il tunnel non è mai stato il pezzo mancante: una VPN cloud gestita espone un contratto di routing definito, e sulle grandi piattaforme quel contratto è BGP. Finché non esiste una sessione e non viene accettato un prefisso, il tunnel è solo un percorso cifrato senza destinazioni dietro di sé.

Il tunnel è attivo e la rotta manca

Il completamento della fase 1 e della fase 2 dimostra che i peer concordano sulla protezione, non che una delle parti sappia dove inviare il traffico. Sono macchine a stati separate con modalità di guasto separate.

Ponete tre domande in ordine: il prefisso è stato annunciato, è stato accettato dal peer ed è stato installato per l'inoltro? Un prefisso annunciato e filtrato è un problema di policy. Un prefisso mai annunciato è un problema di sessione o di configurazione. Un prefisso accettato ma non installato è un problema di selezione della rotta, e ogni risposta indica una parte diversa della configurazione.

Che cosa vi fornisce davvero il provider

Un gateway VPN gestito non è un router senza restrizioni. Il provider vi dà un gateway con indirizzi dei peer supportati, un'impostazione del sistema autonomo, limiti di prefissi e un comportamento di guasto definito. Quella superficie è il prodotto.

Google Cloud documenta il routing dinamico BGP per HA VPN, con Cloud Router che apprende le rotte dei peer e fornisce rotte dinamiche personalizzate idonee alla VPC. AWS Site-to-Site VPN documenta una scelta tra routing statico e dinamico e descrive i controlli di vitalità BGP come utili al failover del tunnel, supportando anche i controlli di integrità per i dispositivi senza BGP. Il comportamento di una piattaforma non va dedotto dal nome del prodotto dell'altra.

La conseguenza pratica è che si sceglie prima la modalità gestita e poi si leggono i parametri supportati. Un progetto che presuppone un tipo di adiacenza che il servizio non offre non è un problema di configurazione da risolvere sul router del cliente.

Protezione del tunnel e raggiungibilità sono compiti separati

IPsec protegge il traffico selezionato per il tunnel. BGP fornisce le informazioni di raggiungibilità che rendono idoneo un prefisso. Un tunnel funzionante non dimostra che il prefisso atteso sia stato annunciato, accettato o installato.

Immaginate una filiale che annuncia 10.42.0.0/16 attraverso due percorsi di tunnel idonei. Togliete un percorso utilizzabile e la scelta della rotta può cambiare senza che nessuno modifichi la rotta di ogni carico di lavoro. Rilevamento, selezione della rotta e recupero dell'applicazione non sono istantanei e non sono identici tra distribuzioni, quindi il test di failover deve osservare l'intera sequenza e non il primo pacchetto che passa.

Quando un prefisso cloud non è raggiungibile, controllate lo stato della sessione e le rotte apprese prima di toccare la crittografia. Una SA attiva senza rotta dietro è la forma più comune di questo sintomo.

Dove si rompono le ipotesi su OSPF

OSPF, IS-IS o un altro protocollo dentro un tunnel IPsec è del tutto possibile su un'appliance autogestita, dove possedete entrambe le estremità e il progetto di inoltro. Questo fatto non dice nulla su un servizio gestito che offre solo BGP come modalità di routing dinamico.

Se un progetto proposto richiede un'adiacenza che il servizio non supporta, cambiate l'architettura deliberatamente. Le opzioni includono un'appliance autogestita nella VPC, il routing statico dove il servizio lo supporta, o un prodotto di connettività diverso. Configurare il protocollo solo sul router del cliente non può aggiungere un peer lato cloud che non esiste, e non farà comparire il prefisso.

Non trasferite la risposta di un fornitore sul gateway di un altro. Le stesse parole, come routing dinamico o failover del tunnel, possono descrivere meccanismi e limiti diversi.

Leggete il requisito del servizio, poi progettate

Prima della prima riga di configurazione, annotate gli indirizzi dei vicini, i numeri di sistema autonomo, i prefissi che annuncerete e accetterete, i limiti delle rotte e il comportamento atteso quando un tunnel fallisce. Quei cinque elementi sono il contratto sul quale progettate.

Poi verificate nello stesso ordine: sessione stabilita, prefisso ricevuto, rotta presente nella tabella di routing della VPC e un flusso reale verso un indirizzo di servizio. Ripetete dopo un failover forzato, perché una sessione che si ristabilisce può tornare con un insieme di rotte diverso. Se il progetto dipende da una convergenza inferiore al secondo, misuratela invece di presumerla.

Conservate il contratto del servizio insieme al registro delle modifiche. Quando qualcuno chiederà più avanti perché il tunnel non può eseguire OSPF, la risposta è un confine di prodotto, non un limite del protocollo, e il registro dovrebbe dirlo.