Eén site-naar-site-VPN voor meerdere VPC's op AWS Transit Gateway

Twee VPC's hebben dit kwartaal het kantoornetwerk nodig, en bij de tweede tunnel breekt de schatting. AWS Transit Gateway kan als gedeelde routinghub dienen: de VPN wordt één keer aangekoppeld, en elke VPC wordt aan dezelfde hub gekoppeld. Het on-premises netwerk bereikt dan elke aangekoppelde VPC via één verbinding. Dat verandert wie de routingbeslissing bezit, en dat is het deel dat de meeste ontwerpen verkeerd doen.

De VPN-koppeling en de VPC-koppelingen zijn afzonderlijke objecten op dezelfde gateway, daarom moeten de routingrelaties daarna worden opgebouwd.

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

Waarom peering niet de snelkoppeling is waarop men hoopt

Het verleidelijke alternatief is de VPN op VPC A te beëindigen en VPC B eraan te peeren. Gewone VPC-peering biedt geen transit van rand tot rand via de VPN-verbinding van A. Een peer bereikt alleen de adressen die de peering zelf levert, en een VPN-rand is daar niet een van. Transit is wat een hub geeft; peering geeft een paar.

Die beperking is een eigenschap van peering, geen quotum dat je kunt verhogen.

Associatie en propagatie doen verschillend werk

Binnen de transit gateway kiest associatie de routetabel waarmee verkeer van een koppeling wordt opgezocht. Propagatie bepaalt welke tabellen de geleerde of verbonden prefixen van een koppeling ontvangen. Eén koppeling kan aan één tabel zijn geassocieerd terwijl hij in meerdere propageert. De twee verwarren is hoe een ontwerp eindigt met bereikbaarheid die niemand had gepland.

Een volledig verbonden kleine hub is het makkelijke geval.

Zet elke koppeling in één tabel en de VPN plus beide VPC-prefixen lossen netjes op. Dat staat ook VPC-naar-VPC-bereikbaarheid toe die de organisatie misschien nooit bedoelde, omdat een gedeelde tabel geen begrip van een spoke kent.

Workloadroutes wonen elders

Elk workload-subnet heeft nog steeds zijn eigen route naar de transit gateway nodig voor de bedoelde on-premises prefixen. Die VPC-routetabellen zijn afzonderlijke objecten van de eigen tabellen van de transit gateway. Voeg de benodigde prefixen toe en behoud bestaande routes in plaats van elke bestemming door een nieuwe standaard te vervangen. Een subnetroute adverteert ook niets naar het klantapparaat.

Kies bewust dynamische of statische routing; peering levert geen van beide.

Isoleer spokes zonder lokale toegang te verliezen

Wanneer A en B beide het kantoor mogen bereiken maar niet naar elkaar mogen routeren, splits dan de tabellen. De geassocieerde tabel van de VPN-koppeling bevat de VPC-prefixen. De geassocieerde tabel van de VPC-koppelingen bevat de on-premises prefixen, zonder een route die A met B verbindt. Propagatie brengt die relatie tot stand, dus je hoeft nooit elke standaardassociatie te accepteren.

Dit is routingisolatie, en het is geen applicatieautorisatie.

Beveiligingsgroepen, netwerk-ACL's, host-firewalls en de eigen rechten van elke dienst bepalen nog steeds welk verkeer wordt toegelaten. Als inspectie nodig is, ontwerp dan het ondersteunde pad expliciet in plaats van aan te nemen dat de hub het uitvoert.

Wat de hub niet oplost

Adresplannen moeten nog steeds niet overlappen, omdat de hub niet toestaat dat één prefix twee workloads aanduidt. Elke VPC-koppeling heeft de Availability Zone-dekking nodig die zijn workloads verwachten. Met BGP moeten de routes van het klantapparaat terug naar elk vereist prefix overeenkomen met het ontwerp en het importbeleid ervan. Een ontbrekende aankondiging ziet er precies uit als een kapotte tunnel.

De VPN-verbinding en de transit gateway zijn nu gedeelde infrastructuur.

Plan tunnelredundantie, apparaatcapaciteit, monitoring en onderhoud rond alle afhankelijke VPC's in plaats van elk als onafhankelijk verbonden te behandelen.

Migratie van een bestaande virtual private gateway-opstelling verdient hetzelfde expliciete plan. Bouw de koppelingen en het beleid, verplaats één gecontroleerd workloadpad, en bevestig de toegestane en geweigerde relaties voordat je het oude pad buiten gebruik stelt. Centralisatie helpt wanneer ze het netwerkteam één plek geeft om gedeelde connectiviteit te beheren, en schaadt wanneer ze verbergt wie wie mag bereiken achter één grote tabel.