AWS Site-to-Site VPN ja NAT Gateway: VGW versus Transit Gateway

Virtuaalne privaatne lüüs ei saa Site-to-Site VPN-i liiklust NAT gateway'le üle anda. Võrrelge VGW ja transit gateway marsruute ning nende jaoks vajalikke teekondi.

Kõik joonistavad esimesel korral sama diagrammi: VPN VPC-sse, NAT gateway internetti, valmis. AWS ei toeta seda teed, kui VPN lõpeb virtual private gateway peal, ja tõrge on nii vaikne, et meeskonnad ehitavad selle rohkem kui korra uuesti. Toimiv lahendus vajab transit gateway'd, mis muudab lüüsi ja marsruutimistabeleid mõlemal pool. Enne joonistamist võrrelge mõlemat kuju.

Topoloogia, mis tundub ilmne ja mida ei toetata

AWS-i NAT gateway dokumentatsioon tõmbab joone, mis üllatab kõiki, kes on ehitanud ainult ühe VPC lahendusi: Site-to-Site VPN-ühendusest tulevat liiklust ei saa virtual private gateway kaudu NAT gateway'le suunata. Lüüsi tüüp, mille peal VPN lõpeb, otsustab, kas tõlketeed üldse on. Viga püsib, sest tunnel on UP ja samas subnetis olev EC2 instants jõuab internetti probleemideta. Kumbki vaatlus ei kontrolli katkist suunda.

Praktikas saabub pakett kohaliku võrgu lähteaadressiga ega leia toetatud järgmist hüpet, mis selle tõlgiks. Sõltuvalt tabelitest visatakse see väljundpiiril ära, ja kuna tunnel jääb UP-i, samal ajal kui instants samas subnetis internetti jõuab, teatatakse tõrkest kohaliku tulemüüri probleemina.

Virtual private gateway versus transit gateway

Virtuaalne privaatne lüüs kuulub ühele VPC-le. See lõpetab VPN-i, paigaldab marsruudid selle VPC marsruutimistabelitesse ja peatub seal. Puudub attachment-mudel, seega ei saa see liiklust teisele VPC-le ega ühisele väljundsegmendile anda. Kogu piirang on see ühe VPC ulatus ja ükski VPC sees lisatud marsruut seda ei muuda.

Transit gateway on piirkondlik keskus, kus VPN, iga spoke-VPC ja ühisteenuste VPC ilmuvad attachment'idena. Sellel on oma marsruutimistabelid, mis valivad, milline attachment saab antud prefiksi.

Just see keskus teeb tsentraliseeritud väljundi võimalikuks. VPN maandub ühe attachment'ina, väljund-VPC teisena ja transit gateway marsruutimistabel saadab internetile suunatud prefiksid esimesest teise. Virtual private gateway puhul pole teist attachment'i, kuhu midagi saata, seepärast ei saa lahendust hiljem lappida.

Toetatud väljundtee, hüpe hüppe haaval

Võrdluslahendusel on viis hüpet ja iga nool on marsruutimisotsus, mille peate seadistama. Liiklus väljub kohalikust võrgust Site-to-Site VPN attachment'i, transit gateway tabel edastab selle väljund-VPC attachment'ile, kus subneti tabel saadab selle avalikku NAT gateway'sse. NAT gateway tõlgib lähte ja internet gateway viib paketi välja.

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

Kaks detaili otsustavad, kas viimased hüpped töötavad. NAT gateway peab olema avalik, elastse IP ja internet gateway marsruudiga, sest privaatne NAT gateway tõlgib võrkude vahel ega muutu kunagi interneti väljundiks.

Planeerige üks NAT gateway iga Availability Zone'i kohta, mida kavatsete teenindada, ja iga subneti tabel osaku kohalikule. Hoidke transit gateway tabel ja VPC tabelid märkmetes eraldi objektidena, sest üks valib attachment'i ja teine VPC-sisese ressursi. Vaikimisi marsruut ainult ühes neist jätab poole teest määratlemata ja tekitab osalisi tõrkeid, mida on kõige raskem omistada.

Tagasitee on koht, kus need lahendused nurjuvad

NAT gateway säilitab oleku voogude jaoks, mida on juba näinud, seega väljuva ühenduse vastused tulevad tagasi ilma uue sissetuleva reeglita. See omadus ei avalda kohalikku teenust internetis, ja selle kohtlemine nii, nagu avaldaks, on viis, kuidas meeskond kulutab päeva ühenduse silumisele, mida kunagi ei tekikski. Kliendi algatatud liikluse puhul peavad neli marsruuti kokku langema: kohalik poliitika, transit gateway tabel, väljund-subneti tabel ja NAT-subneti tabel. Kui viimane puudub, lahkub päring hoonest, samal ajal kui vastus sureb AWS-i sees.

Kontrollige tõelise kliendiga VPN-i taga ja vaadake, millist avalikku lähteaadressi see esitab. Kui see on NAT gateway elastne IP, toimub tõlge; kui midagi muud, mõõdate teist väljundit.

Selle tõrke asümmeetrilist versiooni tasub vara ära tunda. Kui ühe Availability Zone'i NAT-subneti tabelis on tagasimarsruut kliendi prefiksile ja teises mitte, õnnestuvad või nurjuvad uued ühendused sõltuvalt tsoonist, kuhu voog maandub, ja mustrit loetakse ekslikult ebakindlaks internetiks. Võrrelge subneti tabeleid iga teenindatava tsooni jaoks, selle asemel et parandada see, kus pilet avati, sest puuduv marsruut on kogu viga ja teisel pool ei pea midagi muutma.

Millal on selgesõnaline puhverserver parem lahendus

HTTP-puhverserver väljund-VPC instantsil on seaduslik alternatiiv ja sageli odavam. Kliendid seadistatakse seda kasutama, puhverserver avab oma ühenduse välja ja tagasitee on tema probleem, mitte sümmeetrilise marsruutimise pusle. Väheste rakenduste puhul eemaldab see suurema osa transit gateway tööst. See annab ka kasutajapõhise logimise, mida NAT gateway ei suuda pakkuda.

Kuid see ei ole läbipaistev. Kõik, mis eirab puhverserveri seadeid, ja iga protokoll, mis ei ole HTTP, ei järgi seda teed.

Valik sõltub sellest, mida teie rakendused tegelikult räägivad ja kui palju identiteeti logides vajate. Kus nad räägivad HTTP-d, teenib puhverserver oma koha välja; kus vajate üldist väljundit suvalistele protokollidele, on transit gateway lahendus see, mida AWS toetab. Selle eelnev otsustamine on odavam kui avastamine pärast marsruutimistabelite ehitamist.

Seotud artiklid