AWS Site-to-Site VPN prema NAT gatewayu: VGW nasuprot Transit Gatewayu

Svi prvi put crtaju istu shemu: VPN u VPC, NAT gateway prema internetu, gotovo. AWS ne podržava taj put kada VPN završava na virtual private gatewayu, a kvar je dovoljno tih da ga timovi grade više puta. Ispravan dizajn traži transit gateway, što mijenja gateway i tablice ruta na obje strane. Usporedite dva oblika prije crtanja.

Topologija koja izgleda očito i nije podržana

AWS dokumentacija za NAT gateway povlači crtu koja iznenadi svakoga tko je gradio samo dizajne s jednim VPC-om: promet iz Site-to-Site VPN veze ne može se usmjeriti na NAT gateway kroz virtual private gateway. Tip gatewaya na kojem VPN završava određuje postoji li uopće put za prijevod adresa. Greška opstaje jer je tunel UP i EC2 instanca u istoj podmreži bez problema doseže internet. Nijedno od tih opažanja ne provjerava pokvareni smjer.

U praksi paket dolazi s izvornom adresom iz lokalne mreže i ne nalazi podržani sljedeći hop koji bi ga preveo. Ovisno o tablicama, odbacuje se na izlaznoj granici, a kako tunel ostaje UP dok instanca u istoj podmreži doseže internet, kvar se prijavljuje kao problem lokalnog firewalla.

Virtual private gateway nasuprot transit gatewayu

Virtual private gateway pripada jednom VPC-u. Završava VPN, upisuje rute u tablice tog VPC-a i tu staje. Nema model privitka, pa ne može predati promet drugom VPC-u ni zajedničkom izlaznom segmentu. Taj opseg jednog VPC-a je cijelo ograničenje i nijedna ruta dodana unutar VPC-a to ne mijenja.

Transit gateway je regionalno središte u kojem se VPN, svaki spoke VPC i VPC zajedničkih servisa pojavljuju kao privitci. Ima vlastite tablice ruta koje biraju privitak koji prima zadani prefiks.

To središte omogućuje centralizirani izlaz. VPN sleti kao jedan privitak, izlazni VPC kao drugi, a tablica ruta transit gatewaya šalje prefikse prema internetu s prvoga na drugi. Uz virtual private gateway nema drugog privitka kojemu se išta može poslati, zato se dizajn ne može naknadno zakrpati.

Podržani izlazni put, hop po hop

Referentni dizajn ima pet hopova i svaka strelica je odluka o usmjeravanju koju morate postaviti. Promet izlazi iz lokalne mreže u Site-to-Site VPN privitak, tablica ruta transit gatewaya prosljeđuje ga izlaznom VPC privitku, gdje ga tablica podmreže šalje na javni NAT gateway. NAT gateway prevodi izvor, a internet gateway iznosi paket van.

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

Dva detalja odlučuju rade li posljednji hopovi. NAT gateway mora biti javni, s elastic IP-om i rutom na internet gateway, jer privatni NAT gateway prevodi između mreža i nikada ne postaje izlaz u internet.

Planirajte jedan NAT gateway po Availability Zone koju namjeravate opsluživati, a svaka tablica podmreže neka pokazuje na lokalni. Držite tablicu transit gatewaya i VPC tablice odvojenim objektima u bilješkama, jer jedna bira privitak, a druga izvor unutar VPC-a. Zadana ruta samo u jednoj od njih ostavlja polovicu puta nedefiniranom i stvara djelomične kvarove koje je najteže pripisati.

Povratni put je mjesto gdje ti dizajni padaju

NAT gateway pamti stanje za tokove koje je već vidio, pa se odgovori na odlaznu vezu vraćaju bez novog ulaznog pravila. To svojstvo ne objavljuje lokalnu uslugu na internetu i ponašati se kao da objavljuje znači da tim provede dan otklanjajući greške na vezi koja se nikada ne bi uspostavila. Za promet koji započinje klijent moraju se složiti četiri rute: lokalna politika, tablica transit gatewaya, izlazna tablica podmreže i NAT tablica podmreže. Promašite li posljednju, zahtjev napušta zgradu dok odgovor umire unutar AWS-a.

Provjerite stvarnim klijentom iza VPN-a i pogledajte javnu izvornu adresu koju pokazuje. Ako je to elastic IP NAT gatewaya, prijevod se događa; ako je išta drugo, mjerite drugi izlaz.

Asimetričnu inačicu tog kvara vrijedi prepoznati rano. Kada NAT tablica podmreže jedne Availability Zone ima povratnu rutu na prefiks klijenta, a druga ne, nove veze uspijevaju ili padaju ovisno o zoni u koju tok sleti, a obrazac se pogrešno čita kao nestabilan internet. Usporedite tablice podmreža za svaku zonu koju opslužujete umjesto da popravljate onu u kojoj je otvoren tiket, jer ruta koja nedostaje je cijeli kvar i na drugoj strani ništa ne treba mijenjati.

Kada je eksplicitni proxy bolji dizajn

HTTP proxy na instanci u izlaznom VPC-u legitimna je alternativa i često jeftinija. Klijenti se postavljaju da ga koriste, proxy otvara vlastitu vezu prema van, a povratni put postaje njegov problem, a ne zagonetka simetričnog usmjeravanja. Za mali broj aplikacija to uklanja većinu posla oko transit gatewaya. Daje i zapise po korisniku kakve NAT gateway ne može proizvesti.

No nije proziran. Sve što ignorira proxy postavke i svaki protokol koji nije HTTP neće ići tim putem.

Izbor se svodi na to čime vaše aplikacije stvarno govore i koliko identiteta trebate u zapisima. Gdje govore HTTP, proxy zaslužuje mjesto; gdje trebate opći izlaz za proizvoljne protokole, dizajn s transit gatewayem je onaj koji AWS podržava. Odlučiti to unaprijed jeftinije je nego otkriti nakon što su tablice ruta izgrađene.