Una VPN da sede a sede per più VPC su AWS Transit Gateway

Due VPC hanno bisogno della rete dell'ufficio questo trimestre, ed è al secondo tunnel che la stima si rompe. AWS Transit Gateway può fare da concentratore di routing condiviso: la VPN viene associata una volta e ogni VPC viene associato allo stesso concentratore. La rete locale raggiunge così ogni VPC associato con un solo collegamento. Questo cambia chi possiede la decisione di routing, ed è la parte che la maggior parte dei progetti sbaglia.

L'associazione della VPN e le associazioni dei VPC sono oggetti distinti sulla stessa gateway, perciò le relazioni di routing vanno costruite dopo.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

Perché il peering non è la scorciatoia che si spera

L'alternativa tentante è terminare la VPN sul VPC A e fare peering del VPC B con esso. Il normale peering di VPC non offre transito da bordo a bordo attraverso la connessione VPN di A. Un peer raggiunge gli indirizzi che il peering stesso fornisce, e un bordo VPN non è uno di questi. Il transito è ciò che dà un concentratore; il peering dà una coppia.

Questa restrizione è una proprietà del peering, non una quota che si può alzare.

Associazione e propagazione fanno lavori diversi

Dentro la gateway di transito, l'associazione sceglie la tabella di routing usata per cercare il traffico che arriva da un'associazione. La propagazione decide quali tabelle ricevono i prefissi appresi o connessi di un'associazione. Una singola associazione può essere collegata a una tabella mentre propaga verso diverse. Confondere le due è il modo in cui un progetto finisce con una raggiungibilità che nessuno aveva pianificato.

Un piccolo concentratore completamente connesso è il caso facile.

Mettete ogni associazione in una sola tabella e la VPN, con entrambi i prefissi dei VPC, si risolve in modo pulito. Questo permette anche una raggiungibilità tra VPC che l'organizzazione forse non ha mai voluto, perché una tabella condivisa non conosce il concetto di spoke.

Le rotte dei carichi di lavoro vivono altrove

Ogni sottorete di carico di lavoro ha ancora bisogno della propria rotta verso la gateway di transito per i prefissi locali previsti. Quelle tabelle di routing dei VPC sono oggetti distinti dalle tabelle proprie della gateway di transito. Aggiungete i prefissi necessari e conservate le rotte esistenti invece di sostituire ogni destinazione con un nuovo default. Una rotta di sottorete non annuncia nulla al dispositivo del cliente.

Scegliete il routing dinamico o statico deliberatamente; il peering non fornisce nessuno dei due.

Isolare gli spoke senza perdere l'accesso locale

Quando A e B possono entrambi raggiungere l'ufficio ma non devono instradare l'uno verso l'altro, separate le tabelle. La tabella associata dell'associazione VPN contiene i prefissi dei VPC. La tabella associata delle associazioni dei VPC contiene i prefissi locali, senza alcuna rotta che unisca A a B. È la propagazione a produrre quella relazione, quindi non dovrete mai accettare tutte le associazioni predefinite.

Questo è isolamento del routing, e non è autorizzazione dell'applicazione.

I gruppi di sicurezza, le ACL di rete, i firewall degli host e i permessi propri di ogni servizio decidono ancora quale traffico è ammesso. Se serve l'ispezione, progettate esplicitamente il suo percorso supportato invece di presumere che il concentratore la esegua.

Cosa il concentratore non risolve

I piani di indirizzamento devono restare senza sovrapposizioni, perché il concentratore non consente a un prefisso di identificare due carichi di lavoro. Ogni associazione di VPC ha bisogno della copertura Availability Zone che i suoi carichi di lavoro si aspettano. Con BGP, le rotte del dispositivo del cliente verso ogni prefisso richiesto devono corrispondere al progetto e alla sua politica di importazione. Un annuncio mancante sembra esattamente un tunnel rotto.

La connessione VPN e la gateway di transito ora sono infrastruttura condivisa.

Pianificate la ridondanza dei tunnel, la capacità dei dispositivi, il monitoraggio e la manutenzione attorno a tutti i VPC dipendenti invece di trattare ciascuno come collegato in modo indipendente.

La migrazione da una disposizione con virtual private gateway esistente merita lo stesso piano esplicito. Costruite associazioni e politiche, spostate un percorso di carico di lavoro controllato e confermate le relazioni consentite e negate prima di ritirare il vecchio percorso. La centralizzazione aiuta quando dà al team di rete un solo punto per gestire la connettività condivisa, e nuoce quando nasconde chi può raggiungere chi dietro un'unica grande tabella.