Un singur VPN site-la-site pentru mai multe VPC pe AWS Transit Gateway

Două VPC au nevoie de rețeaua biroului în acest trimestru, iar la al doilea tunel se rupe estimarea. AWS Transit Gateway poate acționa ca un hub de rutare partajat: VPN-ul se atașează o dată, iar fiecare VPC se atașează la același hub. Rețeaua locală ajunge apoi la fiecare VPC atașat printr-o singură conexiune. Asta schimbă cine deține decizia de rutare, iar aceasta este partea pe care majoritatea proiectelor o greșesc.

Atașamentul VPN și atașamentele VPC sunt obiecte separate pe aceeași poartă, de aceea relațiile de rutare trebuie construite după aceea.

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

De ce peering nu este scurtătura la care oamenii speră

Alternativa tentantă este să terminați VPN-ul pe VPC A și să împerecheați VPC B cu el. Peering-ul obișnuit de VPC nu oferă tranzit de la margine la margine prin conexiunea VPN a lui A. Un peer ajunge doar la adresele pe care le oferă peering-ul însuși, iar o margine VPN nu este una dintre ele. Tranzitul este ce oferă un hub; peering-ul oferă o pereche.

Această restricție este o proprietate a peering-ului, nu o cotă care poate fi ridicată.

Asocierea și propagarea fac lucrări diferite

În interiorul porții de tranzit, asocierea alege tabelul de rutare folosit pentru căutarea traficului care sosește de la un atașament. Propagarea decide care tabele primesc prefixele învățate sau conectate ale unui atașament. Un singur atașament poate fi asociat cu un tabel în timp ce propagă în mai multe. Confundarea celor două este felul în care un proiect ajunge cu o accesibilitate pe care nimeni nu a planificat-o.

Un hub mic complet conectat este cazul ușor.

Puneți fiecare atașament într-un singur tabel și VPN-ul împreună cu ambele prefixe VPC se rezolvă curat. Asta permite și accesibilitate între VPC pe care organizația poate nu a dorit-o niciodată, pentru că un tabel partajat nu cunoaște noțiunea de spoke.

Rutele sarcinilor de lucru locuiesc în altă parte

Fiecare subrețea de sarcină de lucru are în continuare nevoie de propria rută către poarta de tranzit pentru prefixele locale dorite. Acele tabele de rutare ale VPC sunt obiecte separate de tabelele proprii ale porții de tranzit. Adăugați prefixele de care aveți nevoie și păstrați rutele existente în loc să înlocuiți fiecare destinație cu un nou default. O rută de subrețea nu anunță nimic dispozitivului clientului.

Alegeți rutarea dinamică sau statică în mod deliberat; peering-ul nu oferă niciuna.

Izolați spoke-urile fără a pierde accesul local

Când A și B pot ajunge ambele la birou, dar nu trebuie să ruteze unul către celălalt, împărțiți tabelele. Tabelul asociat al atașamentului VPN deține prefixele VPC. Tabelul asociat al atașamentelor VPC deține prefixele locale, fără nicio rută care să lege A de B. Propagarea produce acea relație, așa că nu trebuie să acceptați niciodată fiecare asociere implicită.

Aceasta este izolare de rutare și nu este autorizare a aplicației.

Grupurile de securitate, ACL-urile de rețea, firewall-urile gazdă și permisiunile proprii ale fiecărui serviciu decid în continuare ce trafic este admis. Dacă este necesară inspecția, proiectați explicit calea ei suportată în loc să presupuneți că hub-ul o efectuează.

Ce nu repară hub-ul

Planurile de adrese trebuie să rămână fără suprapunere, pentru că hub-ul nu permite unui prefix să identifice două sarcini de lucru. Fiecare atașament VPC are nevoie de acoperirea Availability Zone pe care o așteaptă sarcinile sale de lucru. Cu BGP, rutele dispozitivului client înapoi la fiecare prefix necesar trebuie să corespundă proiectului și politicii sale de import. Un anunț lipsă arată exact ca un tunel rupt.

Conexiunea VPN și poarta de tranzit sunt acum infrastructură partajată.

Planificați redundanța tunelurilor, capacitatea dispozitivelor, monitorizarea și întreținerea în jurul tuturor VPC dependente în loc să tratați fiecare ca fiind conectat independent.

Migrarea de la un aranjament existent cu virtual private gateway merită același plan explicit. Construiți atașamentele și politicile, mutați o cale de sarcină de lucru controlată și confirmați relațiile permise și refuzate înainte de a retrage calea veche. Centralizarea ajută când oferă echipei de rețea un singur loc pentru a administra conectivitatea partajată și dăunează când ascunde cine poate ajunge la cine în spatele unui singur tabel mare.