AWS Site-to-Site VPN v NAT Gateway: VGW proti Transit Gateway

Virtualna zasebna prehodna postaja ne more predati prometa Site-to-Site VPN prehodu NAT gateway. Primerjajte poti VGW in transit gateway ter poti, ki jih vsaka potrebuje.

Vsi prvič narišejo isto shemo: VPN v VPC, NAT gateway ven v internet, končano. Toda AWS te poti ne podpira, ko se VPN konča na virtual private gateway, in napaka je tako tiha, da jo ekipe zgradijo znova več kot enkrat. Delujoča zasnova potrebuje transit gateway, kar spremeni prehod in usmerjevalne tabele na obeh straneh. Primerjajte obe obliki, preden karkoli narišete.

Topologija, ki se zdi očitna in ni podprta

Dokumentacija za NAT gateway pri AWS nariše črto, ki preseneti vsakogar, ki je gradil le zasnove z enim VPC: prometa iz povezave Site-to-Site VPN ni mogoče usmeriti v NAT gateway skozi virtual private gateway. Vrsta prehoda, na katerem se VPN konča, odloča, ali prevajalska pot sploh obstaja. Napaka preživi, ker je tunel UP in instanca EC2 v isti podmreži brez težav doseže internet. Nobeno od obeh opažanj ne preverja pokvarjene smeri.

V praksi paket prispe z izvornim naslovom iz lokalnega omrežja in ne najde podprtega naslednjega skoka, ki bi ga prevedel. Glede na tabele se zavrže na izhodni meji, in ker tunel ostane UP, medtem ko instanca v isti podmreži doseže internet, se napaka sporoči kot težava požarnega zidu na lokalni strani.

Virtual private gateway proti transit gateway

Virtual private gateway pripada enemu VPC. Zaključi VPN, namesti poti v usmerjevalne tabele tega VPC in se tam ustavi. Nima modela priključitve, zato ne more predati prometa drugemu VPC ali skupnemu izhodnemu segmentu. Ta obseg enega VPC je celotna omejitev in nobena pot, dodana znotraj VPC, tega ne spremeni.

Transit gateway je regionalno središče, kjer se VPN, vsak spoke VPC in VPC skupnih storitev pojavijo kot priključitve. Ima lastne usmerjevalne tabele, ki izberejo, katera priključitev prejme določen prefix.

To središče omogoča centraliziran izhod: VPN pristane kot ena priključitev, izhodni VPC kot druga, usmerjevalna tabela transit gateway pa pošlje prefixe proti internetu s prve na drugo. Pri virtual private gateway ni druge priključitve, kamor bi kar koli poslali, zato zasnove ni mogoče pozneje zakrpati.

Podprta izhodna pot, skok za skokom

Referenčna zasnova ima pet skokov in vsaka puščica je usmerjevalna odločitev, ki jo morate nastaviti. Promet zapusti lokalno omrežje v priključitev Site-to-Site VPN, tabela transit gateway ga posreduje v priključitev izhodnega VPC, kjer ga tabela podmreže pošlje v javni NAT gateway. NAT gateway prevede izvor in internet gateway paket odnese ven.

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

Dve podrobnosti odločata, ali zadnji skoki delujejo. NAT gateway mora biti javen, z elastic IP in potjo do internet gateway, ker zasebni NAT gateway prevaja med omrežji in nikoli ne postane izhod v internet.

Načrtujte en NAT gateway za vsako Availability Zone, ki jo želite oskrbovati, in vsaka tabela podmreže naj kaže na lokalno. Tabelo transit gateway in tabele VPC hranite v zapiskih kot ločene objekte, ker ena izbere priključitev, druga pa vir znotraj VPC. Privzeta pot samo v eni od njiju pusti polovico poti nedefinirano in ustvari delne odpovedi, ki jih je najtežje pripisati.

Prav na povratni poti te zasnove odpovejo

NAT gateway hrani stanje za tokove, ki jih je že videl, zato se odgovori na odhodno povezavo vrnejo brez novega vhodnega pravila. Ta lastnost ne objavi lokalne storitve v internetu, in obravnavanje, kot da jo, ekipo stane dneva razhroščevanja povezave, ki se nikoli ne bi vzpostavila. Za promet, ki ga začne odjemalec, se morajo ujemati štiri poti: lokalna politika, tabela transit gateway, tabela izhodne podmreže in tabela podmreže NAT. Če zgrešite zadnjo, zahteva zapusti zgradbo, medtem ko odgovor umre znotraj AWS.

Preverite z resničnim odjemalcem za VPN in poglejte, kateri javni izvorni naslov predstavi. Če je to elastic IP prehoda NAT gateway, prevajanje poteka; če je kaj drugega, merite drug izhod.

Asimetrično različico te napake je vredno prepoznati zgodaj. Ko ima tabela podmreže NAT ene Availability Zone povratno pot na prefix odjemalca, druga pa ne, nove povezave uspejo ali spodletijo glede na območje, v katero pade tok, in vzorec se napačno bere kot nestabilen internet. Primerjajte tabele podmrež za vsako območje, ki ga oskrbujete, namesto da popravljate tisto, kjer je bila odprta zahteva, ker manjkajoča pot je celotna napaka in na drugi strani ni treba ničesar spremeniti.

Kdaj je izrecni proxy boljša zasnova

HTTP proxy na instanci v izhodnem VPC je legitimna alternativa in pogosto cenejša. Odjemalci so nastavljeni, da ga uporabljajo, proxy odpre svojo povezavo navzven, povratna pot pa postane njegov problem namesto uganke simetričnega usmerjanja. Za nekaj aplikacij to odstrani večino dela s transit gateway. Daje tudi dnevnik po uporabnikih, ki ga NAT gateway ne more ustvariti.

Ni pa pregleden. Vse, kar ignorira nastavitve proxyja, in vsak protokol, ki ni HTTP, ne bosta šla po tej poti.

Izbira je odvisna od tega, kaj vaše aplikacije v resnici govorijo, in koliko identitete potrebujete v dnevnikih. Kjer govorijo HTTP, si proxy zasluži svoje mesto; kjer potrebujete splošen izhod za poljubne protokole, je zasnova s transit gateway tista, ki jo AWS podpira. Odločiti se o tem vnaprej je ceneje kot odkriti po izgradnji usmerjevalnih tabel.

Sorodni članki