Vienas VPN tarp lokacijų keliems VPC AWS Transit Gateway paslaugoje

Prijunkite VPN vieną kartą ir kiekvieną VPC prie vieno tranzito šliuzo, tada atskirkite susiejimą nuo skleidimo, kad atšakos pasiektų biurą, bet ne viena kitos.

Dviem VPC šį ketvirtį reikia biuro tinklo, ir būtent antrame tunelyje sąmata lūžta. AWS Transit Gateway gali veikti kaip bendras maršrutizavimo centras: VPN prijungiamas vieną kartą, o kiekvienas VPC prijungiamas prie to paties centro. Tada vietinis tinklas pasiekia kiekvieną prijungtą VPC per vieną ryšį. Tai keičia, kam priklauso maršrutizavimo sprendimas, ir būtent šią dalį dauguma projektų padaro neteisingai.

VPN priskyrimas ir VPC priskyrimai yra atskiri objektai tame pačiame šliuze, todėl maršrutizavimo ryšius reikia sukurti vėliau.

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

Kodėl peering nėra tas trumpasis kelias, kurio tikimasi

Vilianti alternatyva – užbaigti VPN VPC A ir peering būdu prijungti VPC B prie jo. Įprastas VPC peering nesuteikia tranzito iš krašto į kraštą per A VPN ryšį. Peering partneris pasiekia tik tuos adresus, kuriuos suteikia pats peering, o VPN kraštas nėra vienas iš jų. Tranzitą suteikia centras; peering suteikia porą.

Šis apribojimas yra peering savybė, o ne kvota, kurią galima padidinti.

Susiejimas ir skleidimas atlieka skirtingą darbą

Tranzito šliuzo viduje susiejimas parenka maršrutų lentelę, pagal kurią ieškoma iš priskyrimo ateinančio srauto. Skleidimas nusprendžia, kurios lentelės gaus priskyrimo išmoktus ar prijungtus prefiksus. Vienas priskyrimas gali būti susietas su viena lentele ir tuo pačiu metu skleisti į kelias. Šių dviejų supainiojimas yra būdas, kuriuo projektas baigiasi pasiekiamumu, kurio niekas neplanavo.

Visiškai sujungtas mažas centras yra lengvas atvejis.

Įdėkite kiekvieną priskyrimą į vieną lentelę ir VPN kartu su abiem VPC prefiksais išsisprendžia švariai. Tai taip pat leidžia pasiekiamumą tarp VPC, kurio organizacija galbūt niekada nenorėjo, nes bendra lentelė neturi atšakos sąvokos.

Darbo krūvių maršrutai gyvena kitur

Kiekvienam darbo krūvio tinklui vis dar reikia savo maršruto link tranzito šliuzo numatytiems vietiniams prefiksams. Tos VPC maršrutų lentelės yra atskiri objektai nuo paties šliuzo lentelių. Pridėkite reikiamus prefiksus ir išsaugokite esamus maršrutus, o ne pakeiskite kiekvieną paskirties tašką nauju default. Tinklo maršrutas taip pat nieko neskelbia kliento įrenginiui.

Dinaminį arba statinį maršrutizavimą rinkitės sąmoningai; peering nesuteikia nė vieno.

Išskirkite atšakas neprarasdami vietinės prieigos

Kai A ir B abu gali pasiekti biurą, bet neturi maršrutizuoti vienas į kitą, atskirkite lenteles. VPN priskyrimo susieta lentelė laiko VPC prefiksus. VPC priskyrimų susieta lentelė laiko vietinius prefiksus, be maršruto, jungiančio A su B. Skleidimas sukuria tą ryšį, todėl jums niekada nereikia priimti kiekvieno numatytojo susiejimo.

Tai maršrutizavimo izoliacija, o ne programos autorizacija.

Saugos grupės, tinklo ACL, pagrindinio kompiuterio užkardos ir kiekvienos paslaugos savi leidimai vis dar nusprendžia, koks srautas priimamas. Jei reikia patikros, suprojektuokite ją palaikantį kelią aiškiai, o ne manykite, kad centras ją atlieka.

Ko centras nesutvarko

Adresų planai vis tiek neturi persidengti, nes centras neleidžia vienam prefiksui žymėti dviejų darbo krūvių. Kiekvienam VPC priskyrimui reikia Availability Zone aprėpties, kurios tikisi jo darbo krūviai. Su BGP kliento įrenginio maršrutai atgal į kiekvieną reikalingą prefiksą turi atitikti projektą ir jo importo politiką. Trūkstamas skelbimas atrodo lygiai kaip sugedęs tunelis.

VPN ryšys ir tranzito šliuzas dabar yra bendra infrastruktūra.

Planuokite tunelių perteklių, įrenginių talpą, stebėjimą ir priežiūrą aplink visus priklausomus VPC, o ne traktuokite kiekvieną kaip atskirai prijungtą.

Migracija iš esamos virtual private gateway schemos nusipelno to paties aiškaus plano. Sukurkite priskyrimus ir politikas, perkelkite vieną kontroliuojamą darbo krūvio kelią ir patvirtinkite leidžiamus bei draudžiamus ryšius prieš atsisakydami seno kelio. Centralizacija padeda, kai tinklo komandai duoda vieną vietą bendram ryšiui valdyti, ir kenkia, kai paslepia, kas ką gali pasiekti, už vienos didelės lentelės.

Susiję straipsniai