AWS Site-to-Site VPN NAT Gateway-ra: VGW ala Transit Gateway

Denek diagrama bera marrazten dute lehen aldian: VPN VPC-ra, NAT gateway internetetara, kito. Baina AWSek ez du bide hori onartzen VPN-a virtual private gateway batean amaitzen denean, eta hutsegitea hain da isila non taldeek behin baino gehiagotan berreraikitzen duten. Funtzionatzen duen diseinuak transit gateway bat behar du, eta horrek gateway-a eta ibilbide-taulak aldatzen ditu bi aldeetan. Alderatu bi formak ezer marraztu aurretik.

Begien bistakoa dirudien eta onartzen ez den topologia

AWSen NAT gateway dokumentazioak lerro bat marrazten du VPC bakarreko diseinuak baino eraiki ez dituen edonor harritzen duena: Site-to-Site VPN konexio baten trafikoa ezin da NAT gateway batera bideratu virtual private gateway baten bidez. VPN-a amaitzen den gateway motak erabakitzen du itzultze-bide bat dagoen ala ez. Akatsa bizirik dirau tunelaren egoera UP delako eta subnet bereko EC2 instantzia batek arazorik gabe internet lortzen duelako. Bi behaketetako batek ere ez du probatzen hondatuta dagoen norabidea.

Praktikan paketea sare lokaleko iturburu-helbide batekin iristen da eta ez du aurkitzen itzuliko lukeen hurrengo jauzi onarturik. Taulekuen arabera irteera-mugan botatzen da, eta tunela UP mantentzen denez subnet bereko instantzia batek internet lortzen duen bitartean, hutsegitea sare lokaleko suebaki arazo gisa jakinarazten da.

Virtual private gateway versus transit gateway

Virtual private gateway bat VPC bakar bati dagokio. VPN-a amaitzen du, VPC horren ibilbide-tauletan ibilbideak instalatzen ditu eta han gelditzen da. Ez du attachment eredurik, beraz ezin du trafikoa beste VPC batera edo irteera-segmentu partekatu batera entregatu. VPC bakarreko esparru hori da muga osoa, eta VPC barruan gehitzen duzun ibilbide batek ere ez du aldatzen.

Transit gateway eskualdeko zentro bat da, non VPN-a, spoke VPC bakoitza eta zerbitzu partekatuen VPC bat attachment gisa agertzen diren. Bere ibilbide-taulak ditu, eta haiek aukeratzen dute zein attachmente-k jasotzen duen prefixu jakin bat.

Zentro horrek egiten du posible irteera zentralizatua. VPN-a attachment gisa lurreratzen da, irteera-VPC-a beste gisa, eta transit gateway ibilbide-taulak internetera doazen prefixuak lehenetik bigarrenera bidaltzen ditu. Virtual private gateway batekin ez dago ezer bidaltzeko bigarren attachmentik, eta horregatik diseinua ezin da geroago adabakiz konpondu.

Onartutako irteera-bidea, jauziz jauzi

Erreferentzia-diseinuak bost jauzi ditu eta gezi bakoitza konfiguratu behar duzun bideratze-erabakia da. Trafikoak sare lokala uzten du Site-to-Site VPN attachmentean sartzeko, transit gatewayren taulak irteera-VPCren attachmenera bidaltzen du, eta han subnet taulak NAT gateway publiko batera bidaltzen du. NAT gatewayk iturburua itzultzen du eta internet gateway-k paketea kanpora eroaten du.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Bi xehetasunek erabakitzen dute azken jauziek funtzionatzen duten. NAT gateway publikoa izan behar da, elastic IP batekin eta internet gateway baterako ibilbidearekin, NAT gateway pribatu batek sareen artean itzultzen baitu eta ez baita inoiz internet irteera bihurtzen.

Planifikatu NAT gateway bat zerbitzatu nahi duzun Availability Zone bakoitzeko, subnet taula bakoitza bertakoaren erakusle delarik. Eutsi transit gatewayren taula eta VPCren taulak objektu bereizi gisa zure oharretan, batek attachment bat aukeratzen baitu eta besteak VPC barruko baliabide bat. Horietako batean soilik dagoen default ibilbide batek bidearen erdia mugagabe uzten du eta egozten zailenak diren hutsegite partzialak sortzen ditu.

Itzulera-bidea da diseinu hauek huts egiten duten tokia

NAT gatewayk aurretik ikusi dituen fluxuentzako egoera gordetzen du, beraz irteerako konexio baten erantzunak sarrera-arau berririk gabe itzultzen dira. Propietate horrek ez du zerbitzu lokalik interneten argitaratzen, eta hala egiten duela tratatzeak talde bati egun osoa kostatzen dio inoiz ez zen ezarriko zen konexio bat arazten. Bezeroak hasitako trafikorako lau ibilbidek bat etorri behar dute: politika lokala, transit gatewayren taula, irteera-subneten taula eta NAT subneten taula. Azkena falta bada, eskaerak eraikina uzten du eta erantzuna AWS barruan hiltzen da.

Egiaztatu VPNaren atzean dagoen benetako bezero batekin eta begiratu zein iturburu-helbide publiko aurkezten duen. NAT gatewayren elastic IP bada, itzulpena gertatzen ari da; beste zerbait bada, beste irteera bat neurtzen ari zara.

Hutsegite honen bertsio asimetrikoa goiz ezagutzea merezi du. Availability Zone baten NAT subnet taulak bezeroaren prefixurako itzulera-ibilbidea duenean eta beste batek ez, konexio berriek arrakasta edo porrota dute fluxua zein zonatan erortzen den arabera, eta eredua oker irakurtzen da internet ezegonkor gisa. Alderatu zerbitzatzen duzun zona bakoitzeko subnet taulak txartela ireki zen zona konpondu beharrean, falta den ibilbidea da akats osoa eta beste aldean ez baita ezer aldatu behar.

Noiz den proxy esplizitua diseinu hobea

Irteera-VPCko instantzia batean HTTP proxy bat alternatiba zilegi eta sarritan merkeagoa da. Bezeroak hura erabiltzeko konfiguratzen dira, proxyak bere konexioa irekitzen du kanpora, eta itzulera-bidea haren arazoa da bideratze simetrikoaren buruhausterik gabe. Aplikazio gutxi batzuentzat transit gateway lanaren zatirik handiena kentzen du. Gainera, NAT gatewayk sortu ezin duen erabiltzaile bakoitzeko erregistroa ematen dizu.

Ez da gardena ordea. Proxy ezarpenak alde batera uzten dituen edozerek eta HTTP ez den protokolo orok ez dute bide hori jarraituko.

Aukera zure aplikazioek benetan zer hitz egiten duten eta erregistroetan zenbat identitate behar duzun araberakoa da. HTTP hitz egiten duten tokian proxyak irabazten du bere lekua; protokolo arbitrarioetarako irteera orokorra behar duzun tokian transit gateway diseinua da AWSek onartzen duena. Horren aldeko erabakia aurretik hartzea merkeagoa da ibilbide-taulak eraiki ondoren aurkitzea baino.