Gunez guneko VPN bat hainbat VPCrentzat AWS Transit Gatewayn

Konektatu VPNa behin eta VPC bakoitza transituko atebide bakar batera, eta gero bereizi asoziazioa hedapenetik, adarrek bulegoa har dezaten baina elkar ez.

Bi VPCk bulegoko sarea behar dute hiruhileko honetan, eta bigarren tunelarekin hausten da estimazioa. AWS Transit Gateway bideratze-hub partekatu gisa joka dezake: VPNa behin konektatzen da, eta VPC bakoitza hub berera konektatzen da. Gero sare lokalak VPC konektatu bakoitzera konexio bakarraren bidez iristen da. Horrek aldatzen du nork duen bideratze-erabakia, eta hori da diseinu gehienek gaizki egiten duten zatia.

VPNaren eransketa eta VPCen eransketak atebide bereko objektu bereiziak dira, eta horregatik bideratze-harremanak geroago eraiki behar dira.

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

Zergatik peering ez den jendeak espero duen lasterbidea

Besterik gabe tentagarria den alternatiba VPNa VPC An amaitzea eta VPC B harekin peering egitea da. Ohiko VPC peering-ek ez du ertz batetik besterako transiturik ematen Aren VPN konexioaren bidez. Peer bat peering-ek berak ematen dituen helbideetara iristen da, eta VPN ertza ez da horietako bat. Transitua hub batek ematen du; peering-ek bikote bat ematen dizu.

Muga hori peering-aren propietatea da, ez igo dezakezun kuota bat.

Asoziazioak eta hedapenak lan desberdina egiten dute

Transituko atebidearen barruan, asoziazioak eransketa batetik datorren trafikoa bilatzeko erabiltzen den bideratze-taula hautatzen du. Hedapenak erabakitzen du zein taulak jasoko dituzten eransketa baten ikasitako edo konektatutako prefijoak. Eransketak taula batekin asozia daiteke eta aldi berean hainbatetara hedatu. Biak nahastea da diseinu bat inork planifikatu ez zuen irisgarritasunarekin amaitzeko modua.

Guztiz konektatutako hub txiki bat kasu erraza da.

Jarri eransketa bakoitza taula bakarrean eta VPNa bi VPC prefijoekin batera garbi ebazten da. Horrek VPCen arteko irisgarritasuna ere ahalbidetzen du, erakundeak inoiz nahi ez zuena agian, taula partekatuak ez baitu adarraren kontzepturik.

Karga-lanen bideak beste leku batean bizi dira

Karga-laneko azpisare bakoitzak oraindik bere bidea behar du transituko atebiderantz, aurreikusitako tokiko prefijoetarako. VPC bideratze-taula horiek transituko atebidearen taula propioetatik bereizitako objektuak dira. Gehitu behar dituzun prefijoak eta gorde lehendik dauden bideak, helmuga bakoitza default berri batekin ordezkatu beharrean. Azpisareko bide batek ere ez dio ezer iragartzen bezeroaren gailuari.

Aukeratu bideratze dinamikoa edo estatikoa nahita; peering-ek ez du bat ere ematen.

Bakartu adarrak tokiko sarbidea galdu gabe

A eta B biak bulegora iristen badira baina elkarren artean bideratu behar ez badute, zatitu taulak. VPNaren eransketaren taula asoziatuak VPC prefijoak ditu. VPCen eransketen taula asoziatuak tokiko prefijoak ditu, A B-rekin batzen duen biderik gabe. Hedapenak sortzen du harreman hori, beraz ez duzu inoiz asoziazio lehenetsi guztiak onartu behar.

Hau bideratze-isolamendua da, eta ez da aplikazioaren baimena.

Segurtasun-taldeek, sareko ACLek, ostalariaren suebakiek eta zerbitzu bakoitzaren baimenek oraindik erabakitzen dute zein trafiko onartzen den. Ikuskapena beharrezkoa bada, diseinatu haren bide onartua modu esplizituan, hub-ak egiten duela suposatu beharrean.

Hubak konpontzen ez duena

Helbide-planek gainjarri gabe jarraitu behar dute, hubak ez baitu uzten prefijo batek bi karga-lan identifikatzen. VPC eransketa bakoitzak bere karga-lanek espero duten Availability Zone estaldura behar du. BGP-rekin, bezeroaren gailuaren bideek prefijo beharrezko bakoitzera itzultzean diseinuarekin eta haren inportazio-politikarekin bat etorri behar dute. Falta den iragarki batek tunel hautsi bat bezalako itxura du.

VPN konexioa eta transituko atebidea azpiegitura partekatua dira orain.

Planifikatu tuneletako erredundantzia, gailuen ahalmena, monitorea eta mantentzea mendeko VPC guztien inguruan, bakoitza independenteki konektatuta balego bezala tratatu beharrean.

Lehendik dagoen virtual private gateway ezarpen batetik migratzeak berdin merezi du plan esplizitua. Eraiki eransketak eta politikak, mugitu karga-laneko bide kontrolatu bat, eta berretsi baimendutako eta ukatuako harremanak bide zaharra erretiratu aurretik. Zentralizazioak laguntzen du sare-taldeari konektibitate partekatua kudeatzeko leku bakarra ematen dionean, eta kalte egiten du taula handi baten atzean nor norengana irits daitekeen ezkutatzen duenean.

Erlazionatutako artikuluak