Bæta staðbundnu undirneti við AWS VPN: VGW á móti Transit Gateway

Núverandi Site-to-Site VPN ber 10.60.0.0/16, nýtt þjónustunet birtist bak við sama staðbundna gátt og 10.70.0.0/16, og einhver spyr hvort proxy sé nauðsynlegur. Venjulega ekki: beitt leið getur borið forskeytið, en aðeins ef þrír hlutir passa saman, og hverjir þrír fer eftir AWS-arkitektúrnum sem þú rekur þegar. Sýndar einkagátt hefur eitt rútmutöflumark; transit gateway bætir við öðru. Rétt tilkynning og röng tafla gefa lotu sem lítur heilbrigð út og skilar engu.

Birtu forskeyti sem gáttin getur raunverulega skilað

Staðbundna gáttin þarf leið áfram inn í nýja netið áður en nokkur tilkynning hefur merkingu. Að tilkynna 10.70.0.0/16 í gegnum BGP segir AWS hvert senda skuli pakka fyrir það bil; það býr ekki til staðbundnu framsendingarleiðina sem gerir bilið aðgengilegt hinum megin. Staðfestu að gáttin hafi leið fyrir forskeytið sem bendir á tækið sem heldur því, og að tækið sé stillt til að svara fyrir þessi vistföng. Útflutningsstefna og samþykkt forskeytamörk eru næsta takmörkun, því forskeyti sem lotan síar út nær aldrei til AWS.

Hafðu samantektir og nákvæmari leiðir viljandi. Leiðir sem skarast og koma úr tveimur áttum eru hönnunarákvörðun, ekki smáatriði sem uppgötvast seinna.

Leið fyrsta: mörk sýndar einkagáttar

Með sýndar einkagátt lýsir AWS VPN-beiningarskjalið tveimur dreifingarháttum, föstum leiðum og BGP-tilkynningum, og báðir ráðast af undirnetsrútmutöflunni sem forritið notar í raun. Dreifing er þægileg þegar þú stjórnar öllu bilinu, og skýr leið er auðveldari í röksemdafærslu þegar þú vilt áfangastaðinn skráðan við hlið marksins. Sama hvað, prófið er það sama: inniheldur tafla viðkomandi forritsundirnets virka leið að VPN-markinu fyrir nýja forskeytið, og vinnur hún gegn einhverju nákvæmara?

Heilbrigð BGP-lota sannar að rásin er til. Hún segir ekkert um hvort tiltekin undirnetstafla hafi tekið leiðina.

Leið önnur: transit gateway bætir við töflu

Transit gateway skiptir þeirri einu spurningu í tvennt. VPC-undirnetið verður að senda áfangastaðinn til transit gateway-tengingarinnar, og síðan verður rútmutöfluna transit gateway að velja VPN-tenginguna fyrir sama forskeyti. Tengingar- og dreifingarval ákveður hvaða tengdu net fá leiðina, svo hægt er að tilkynna forskeyti rétt frá VPN og það nær samt aldrei til VPC sem taflan hans var aldrei tengd réttu rútmutöflunni.

Algenga bilunin er leið sem er í annarri töflunni en ekki hinni, þar sem hvert teymi er sannfært um að þess hlið sé rétt. Þegar þú berð saman arkitektúranna tvo er þetta auka mark allur munurinn: fleiri staðir til að skoða, og nákvæmari stjórn á því hver fær leiðina.

Dreifing leiða veitir heldur ekki hverri tengingu forskeytið. Hún dreifir því til taflanna sem eru stilltar til að taka við því.

Endurleiðin er eigin stefnuákvörðun

Umferðin sem berst er aðeins helmingur skiptanna. Nýja staðbundna netið þarf leið til baka að upprunaforskeytum AWS í gegnum réttu gáttina, og öryggisstefnan á báðum endum verður að leyfa það par uppruna og áfangastaðar. Ef göngin semja um verndarsvið með umferðarvali verður nýja forskeytið að vera innan þess, annars er pakkanum hent áður en nokkur rútmutalla er skoðuð.

Vistfangaskörun er hin gildran. Aðskilin, skýrt eiguð bil halda þessu einföldu; bil sem skarast þýða þýðingu eða endurhönnun, og hvorugt er skiptanlegt afbrigði af sömu uppskrift.

Prófaðu með uppruna í nýja netinu og áfangastað í forritsundirnetinu, endurtaktu svo í hina áttina. Einátta próf sannar eina átt.

Hvenær proxy er raunverulega betri mörkin

Proxy á skilið sinn stað þegar krafan er þröng þjónustuviðmót, þegar forritið býst þegar við þessum arkitektúr, eða þegar ekki er hægt að láta netleiðina bera forskeytið án þýðingar sem þú vilt ekki. Það er ekki varaleiðin fyrir rútmutöflufærslu sem enginn athugaði.

Ákveddu í þessari röð: staðbundin framsending, tilkynning, taflamörk, endurkvarði. Lagaðu það fyrsta sem bregst, og spurðu aðeins þá hvort beina leiðin sé yfirhöfuð rétta svarið.