AWS Site-to-Site VPN í NAT Gateway: VGW eða Transit Gateway

Allir teikna sömu skýringarmyndina í fyrsta skipti: VPN inn í VPC, NAT gateway út á internetið, búið. En AWS styður ekki þá leið þegar VPN endar á virtual private gateway, og bilunin er svo hljóðlát að teymi byggja hana upp aftur fleiri en einu sinni. Hönnunin sem virkar þarf transit gateway, sem breytir gatewaynum og rútutöflunum á báðum hliðum. Berið saman formin tvö áður en þið teiknið nokkuð.

Topologían sem virðist augljós og er ekki studd

Skjöl AWS um NAT gateway draga línu sem kemur öllum á óvart sem hafa aðeins byggt hönnun fyrir eitt VPC: ekki er hægt að beina umferð frá Site-to-Site VPN tengingu í NAT gateway í gegnum virtual private gateway. Tegund gatewaysins sem VPN endar á ræður því hvort þýðingarleið er yfirhöfuð til. Mistökið lifir af því tunnelstaðan er UP og EC2 tilvik í sama subneti nær internetinu án vandræða. Hvorug athugunin prófar brotnu áttina.

Í reynd kemur pakkinn með upprunafang frá staðarnetinu og finnur engan studdan næsta hopp sem myndi þýða hann. Eftir töflunum er honum hent á útgangsmörkum, og þar sem tunnelinn helst UP á meðan tilvik í sama subneti nær internetinu er bilunin tilkynnt sem eldveggsvandamál á staðnum.

Virtual private gateway á móti transit gateway

Virtual private gateway tilheyrir einu VPC. Hann endar VPN, setur rútur í rútutöflur þess VPC og stoppar þar. Hann hefur ekkert attachment-líkan, svo hann getur ekki afhent umferð til annars VPC eða sameiginlegs útgangshluta. Þetta eitt-VPC umfang er öll takmörkin, og engin rúta sem þið bætið við inni í VPC breytir því.

Transit gateway er svæðisstöð þar sem VPN, hvert spoke VPC og VPC fyrir sameiginlegar þjónustur birtast sem attachment. Hann hefur eigin rútutöflur sem velja hvaða attachment fær tiltekið forskeyti.

Þessi stöð gerir miðlægan útgang mögulegan: VPN lendir sem eitt attachment, útgangs-VPC sem annað, og rútutafla transit gatewaysins sendir forskeyti í átt að internetinu frá því fyrra til hins síðara. Með virtual private gateway er ekkert annað attachment til að senda eitthvað á, þess vegna er ekki hægt að bæta hönnuninni við eftir á.

Studda útgangsleiðin, hopp fyrir hopp

Viðmiðunarhönnunin hefur fimm hopp og hver ör er leiðarákvörðun sem þið verðið að stilla. Umferðin fer úr staðarnetinu í Site-to-Site VPN attachment, rútutafla transit gatewaysins sendir hana áfram í útgangs-VPC attachment, þar sem subnettöfluna sendir hana á opinbert NAT gateway. NAT gateway þýðir upprunann og internet gateway ber pakkann út.

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

Tveir þættir ráða því hvort síðustu hoppin virka. NAT gateway verður að vera opinbert, með elastic IP og rútu á internet gateway, því einkarekið NAT gateway þýðir milli neta og verður aldrei internetútgangur.

Skipuleggið eitt NAT gateway fyrir hvert Availability Zone sem þið ætlið að þjóna, og hver subnett-tafla vísi á það staðbundna. Haldið töflu transit gatewaysins og VPC-töflunum sem aðskildum hlutum í minnisbókum ykkar, því önnur velur attachment og hin auðlind inni í VPC. Sjálfgefin rúta í aðeins annarri hvorri skilur helming leiðarinnar óskilgreindan og framleiðir þau hluta bilun sem erfiðast er að rekja.

Afturleiðin er þar sem þessar hönnur bregðast

NAT gateway geymir stöðu fyrir strauma sem það hefur þegar séð, svo svör við útleið tengingu koma til baka án nýrrar innleiðarreglu. Þessi eiginleiki birtir ekki staðbundna þjónustu á internetinu, og að meðhöndla hann eins og svo sé kostar teymi heilan dag í villuleit á tengingu sem aldrei hefði orðið til. Fyrir umferð sem hefst hjá viðskiptavininum verða fjórar rútur að stemma: staðbundin stefna, tafla transit gatewaysins, útgangs-subnett-taflan og NAT-subnett-taflan. Sleppið þeirri síðustu og beiðnin yfirgefur bygginguna á meðan svarið deyr inni í AWS.

Sannreynið með raunverulegum viðskiptavini bak við VPN og skoðið hvaða opinbera upprunafang hann sýnir. Ef það er elastic IP NAT gatewaysins fer þýðing fram; ef eitthvað annað er það, eruð þið að mæla annan útgang.

Ósamhverfa útgáfan af þessari bilun er þess virði að þekkja snemma. Þegar NAT-subnett-tafla eins Availability Zone hefur afturrútu á forskeyti viðskiptavinarins og önnur ekki, takast nýjar tengingar eða mistakast eftir því í hvaða svæði straumurinn lendir, og mynstrið er mislesið sem óstöðugt internet. Berið saman subnett-töflur fyrir hvert svæði sem þið þjónið í stað þess að laga það þar sem miðinn var opnaður, því rútan sem vantar er öll bilunin og ekkert þarf að breytast hinum megin.

Hvenær skýr proxy er betri hönnun

HTTP proxy á tilviki í útgangs-VPC er lögmætur valkostur og oft ódýrari. Viðskiptavinir eru stilltir til að nota hann, proxyið opnar sína eigin tengingu út, og afturleiðin verður vandamál þess frekar en samhverf leiðarþraut. Fyrir fá forrit fjarlægir það mestan hluta transit gateway vinnunnar. Það gefur líka skráningu á hvern notanda sem NAT gateway getur ekki framleitt.

Það er þó ekki gegnsætt. Allt sem hunsar proxy-stillingar, og sérhvert samskiptareglur sem er ekki HTTP, munu ekki fylgja þeirri leið.

Valið veltur á því hvað forritin ykkar tala í raun og hversu mikillar auðkenningar þið þurfið í skráningunni. Þar sem þau tala HTTP á proxyið sér stað; þar sem þið þurfið almennan útgang fyrir handahófskenndar samskiptareglur er transit gateway hönnunin sú sem AWS styður. Að ákveða það fyrirfram er ódýrara en að uppgötva það eftir að rútutöflurnar eru byggðar.