AWS Site-to-Site VPN į NAT Gateway: VGW ar Transit Gateway

Virtualus privatusis tinklas negali perduoti Site-to-Site VPN srauto NAT gateway. Palyginkite VGW ir transit gateway kelius bei maršrutus, kurių kiekvienas reikalauja.

Pirmą kartą visi piešia tą pačią schemą: VPN į VPC, NAT gateway į internetą, baigta. Tačiau AWS nepalaiko šio kelio, kai VPN baigiasi virtual private gateway, o gedimas toks tylus, kad komandos jį perstato daugiau nei kartą. Veikiantis sprendimas reikalauja transit gateway, o tai keičia gateway ir maršrutų lenteles abiejose pusėse. Prieš piešdami palyginkite abi formas.

Topologija, kuri atrodo akivaizdi ir nepalaikoma

AWS NAT gateway dokumentacija brėžia liniją, nustebinančią kiekvieną, kas kūrė tik vieno VPC sprendimus: srautas iš Site-to-Site VPN ryšio negali būti nukreiptas į NAT gateway per virtual private gateway. Gateway tipas, kuriame baigiasi VPN, nusprendžia, ar vertimo kelias apskritai egzistuoja. Klaida išlieka todėl, kad tunelio būsena yra UP, o EC2 instancija tame pačiame subnet pasiekia internetą be problemų. Nė vienas stebėjimas netikrina sugedusios krypties.

Praktiškai paketas atvyksta su vietinio tinklo šaltinio adresu ir neranda palaikomo kito hop, kuris jį išverstų. Priklausomai nuo lentelių, jis išmetamas prie išėjimo ribos, o kadangi tunelis lieka UP, kol instancija tame pačiame subnet pasiekia internetą, gedimas pranešamas kaip vietinio firewall problema.

Virtual private gateway prieš transit gateway

Virtual private gateway priklauso vienam VPC. Jis užbaigia VPN, įrašo maršrutus į to VPC maršrutų lenteles ir ten sustoja. Jis neturi attachment modelio, todėl negali perduoti srauto kitam VPC ar bendram išėjimo segmentui. Ši vieno VPC apimtis yra visas apribojimas, ir joks VPC viduje pridėtas maršrutas to nekeičia.

Transit gateway yra regioninis centras, kuriame VPN, kiekvienas spoke VPC ir bendrų paslaugų VPC pasirodo kaip attachment. Jis turi savo maršrutų lenteles, kurios parenka, kuris attachment gaus duotą prefix.

Šis centras leidžia centralizuotą išėjimą: VPN nusileidžia kaip vienas attachment, išėjimo VPC kaip kitas, o transit gateway maršrutų lentelė siunčia interneto krypties prefix iš pirmojo į antrąjį. Su virtual private gateway nėra antro attachment, kuriam ką nors siųsti, todėl sprendimo negalima užlopyti vėliau.

Palaikomas išėjimo kelias, hop po hop

Etaloninis sprendimas turi penkis hop, ir kiekviena rodyklė yra maršrutizavimo sprendimas, kurį turite sukonfigūruoti. Srautas išeina iš vietinio tinklo į Site-to-Site VPN attachment, transit gateway lentelė perduoda jį į išėjimo VPC attachment, kur subnet lentelė siunčia jį į viešą NAT gateway. NAT gateway išverčia šaltinį, o internet gateway išneša paketą.

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

Du dalykai nusprendžia, ar veiks paskutiniai hop. NAT gateway turi būti viešas, su elastic IP ir maršrutu į internet gateway, nes privatus NAT gateway verčia tarp tinklų ir niekada netampa interneto išėjimu.

Planuokite vieną NAT gateway kiekvienam Availability Zone, kurį ketinate aptarnauti, ir kiekviena subnet lentelė turi rodyti į vietinį. Laikykite transit gateway lentelę ir VPC lenteles kaip atskirus objektus savo užrašuose, nes viena parenka attachment, o kita – išteklių VPC viduje. Numatytais maršrutas tik vienoje iš jų palieka pusę kelio neapibrėžtą ir sukuria dalinius gedimus, kuriuos sunkiausia priskirti.

Būtent grįžimo kelyje šie sprendimai žlunga

NAT gateway išsaugo būseną jau matytiems srautams, todėl atsakymai į išeinantį ryšį grįžta be naujos įeinančios taisyklės. Ši savybė neskelbia vietinės paslaugos internete, o elgiantis taip, tarsi skelbtų, komanda praranda dieną derindama ryšį, kuris niekada nebūtų užmegztas. Kliento inicijuotam srautui turi sutarti keturi maršrutai: vietinė politika, transit gateway lentelė, išėjimo subnet lentelė ir NAT subnet lentelė. Praleiskite paskutinį – užklausa palieka pastatą, o atsakymas miršta AWS viduje.

Patikrinkite su tikru klientu už VPN ir pažiūrėkite, kokį viešą šaltinio adresą jis pateikia. Jei tai NAT gateway elastic IP, vertimas vyksta; jei kažkas kita, matuojate kitą išėjimą.

Asimetrinę šio gedimo versiją verta atpažinti anksti. Kai vieno Availability Zone NAT subnet lentelėje yra grįžimo maršrutas į kliento prefix, o kitame nėra, nauji ryšiai pavyksta arba nepavyksta pagal zoną, į kurią patenka srautas, ir modelis klaidingai skaitomas kaip nestabilus internetas. Palyginkite kiekvienos aptarnaujamos zonos subnet lenteles, o ne taisykite tą, kurioje buvo atidarytas bilietas, nes trūkstamas maršrutas yra visas gedimas ir kitoje pusėje nieko keisti nereikia.

Kada aiškus proxy yra geresnis sprendimas

HTTP proxy instancijoje išėjimo VPC yra teisėta alternatyva ir dažnai pigesnė. Klientai sukonfigūruojami jį naudoti, proxy atidaro savo ryšį į išorę, o grįžimo kelias tampa jo problema, o ne simetrinio maršrutizavimo galvosūkiu. Nedaugeliui programų tai pašalina didžiąją dalį transit gateway darbo. Jis taip pat suteikia vartotojo lygio žurnalus, kurių NAT gateway negali sukurti.

Tačiau jis nėra skaidrus. Viskas, kas nepaiso proxy nustatymų, ir kiekvienas protokolas, kuris nėra HTTP, šiuo keliu neis.

Pasirinkimas priklauso nuo to, ką jūsų programos iš tikrųjų kalba, ir kiek tapatybės reikia žurnaluose. Kur jos kalba HTTP, proxy užima savo vietą; kur reikia bendro išėjimo savavališkiems protokolams, transit gateway sprendimas yra tas, kurį palaiko AWS. Nuspręsti tai iš anksto pigiau nei atrasti po to, kai maršrutų lentelės jau pastatytos.

Susiję straipsniai