Šaltinio/tikslo patikra yra vieni vartai, o ne visas VPN kelias

VPN baigiasi EC2 egzemplioriuje, galite pasiekti to egzemplioriaus tunelio adresą, o srautas, kuris turėjo juo eiti į kitą privatų hostą, dingsta. Tai du skirtingi bandymai, o jų painiojimas kainuoja valandas. Pirmasis klausia, ar galite pasiekti egzempliorių; antrasis reikalauja, kad jis persiųstų srautą į paskirties vietą, kuri nėra jo paties, o tam reikia Linux persiuntimo, užkardos politikos, maršruto kitoje pusėje ir AWS lygmens leidimo, neturinčio nieko bendra su svečio operacine sistema. Niekas konsolėje neatkreipia dėmesio į šį skirtumą. Simptomas atrodo kaip maršrutizavimo gedimas, ir dažniausiai tai nėra jis.

Atskirkite du bandymus prieš ką nors keisdami

Pasiekimas tinklų sietuvo įrodo tunelį, maršrutą iki jo adreso ir saugos grupę, leidžiančią mainus. Persiuntimas kitam hostui neįrodo nieko iš to: jis naudoja kitą šaltinio adresą, kitą paskirties vietą ir egzempliorių vaidmenyje, kuriam jis ne būtinai buvo sukurtas. Užrašykite abu bandymus atskirai ir pažymėkite, kuris nepavyksta, nes kiekvieno pataisymas yra kitoje konsolėje. Tinklų sietuvo egzempliorius, sukurtas tik tuneliams užbaigti, neturi priežasties persiųsti ką nors kita, ir jo numatytosios reikšmės tai atspindi. Todėl antrajam bandymui reikia savo nustatymo, o ne mažo pirmojo pataisymo.

Ping, kuris veikia iki tinklų sietuvo, ir ping, kuris nepavyksta iki už jo esančio hosto, nėra protarpinis sutrikimas. Tai laukiamas egzemplioriaus, kuriam nebuvo pasakyta, kad jis gali persiųsti, elgesys.

Užrašykite kelią prieš liesdami nustatymą

Užrašykite kliento priešdėlį, persiunčiantį egzempliorių ar tinklo sąsają, tikslinį potinklį ir atsakymo maršrutą. VPC maršrutų lentelės įrašas, rodantis į egzempliorių, nesukonfigūruoja egzemplioriaus operacinės sistemos persiuntimui, o svečio branduolys su įjungtu persiuntimu nesukuria VPC maršruto. Turi egzistuoti abu to ryšio galai, ir jie redaguojami skirtingose vietose skirtingą prieigą turinčių žmonių.

Tada patikrinkite šaltinio/tikslo patikros nustatymą tikrame persiuntimo komponente, o ne kiekviename VPC egzemplioriuje. AWS dokumentuoja, kodėl egzemplioriui, persiunčiančiam srautą už kitus, ši patikra turi būti išjungta, ir kodėl nustatymas yra sprendimas kiekvienam egzemplioriui, o ne viso VPC numatytoji reikšmė.

Keturi ribos, ir patikra tėra viena iš jų

Traktuokite kelią kaip keturis klausimus ir atsakykite į juos eilės tvarka. Pirmasis nepavykęs atsakymas yra vieta, kur yra darbas, ir nė vienas kitas jo nepakompensuos.

Tvarka svarbi, nes patikrinti pigu: maršrutai matomi viename puslapyje, patikra yra vienas atributas, o paskirties nuomonė paprastai yra paskutinis dalykas, kurio kas nors klausia.

Vertimas pakeičia, kokį šaltinį mato paskirties vieta

Maršrutizuotas dizainas išsaugo kliento šaltinio adresą, todėl paskirties vietai reikia grįžtamojo maršruto į kliento priešdėlį. Išverstas dizainas vietoj to pateikia tinklų sietuvo adresą, o tai pašalina tą reikalavimą ir pakeičia jį būsenos lentele tinklų sietuve. Nuspręskite pagal numatomą architektūrą, o ne pridėkite vertimą todėl, kad nesusijęs pavyzdys jį naudojo ir atrodė, kad veikia.

Jei verčiate, apribokite taisyklę kliento priešdėliu ir numatoma paskirties vieta. Jei išsaugote, patvirtinkite, kad kita pusė tikrai žino maršrutą, o ne manykite, kad jis išmoks vieną.

Bandykite iš originalaus kliento, tada palikite pakeitimą

Užklausa, sukurta tinklų sietuvo, gali pavykti, o persiųsta užklausa nepavyksta, nes tai kitas šaltinis ir kitas persiuntimo atvejis. Po tikslingos pataisos pakartokite tikslų kliento-į-išteklių bandymą, kuris nepavyko, iš to paties kliento, ir patvirtinkite, kad atsakymas grįžta, o ne tik tai, kad užklausa atvyko.

Galiausiai įdėkite nustatymą į valdomą tinklų sietuvo konfigūraciją, kad jį gautų pakaitinis egzempliorius. Sėkmingas bandymas, priklausantis nuo rankinės išimties, yra bandymas, kuris pasibaigia kitame perkūrime, o jį atradęs žmogus nebus ten, kad prisimintų kodėl.