Kontrolo de fonto/celo estas unu pordo, ne la tuta VPN-vojo

La VPN finiĝas sur EC2-instanco, vi povas atingi la tunelan adreson de tiu instanco, kaj trafiko, kiu devus pasi tra ĝi al alia privata gastiganto, malaperas. Tio estas du malsamaj testoj, kaj miksi ilin malŝparas horojn. La unua demandas, ĉu vi povas atingi la instancon; la dua postulas, ke ĝi enkursigu trafikon al celo, kiu ne estas ĝia propra, kio bezonas Linux-enkursigon, fajroŝirmilan politikon, itineron ĉe la malproksima flanko kaj permeson je la nivelo de AWS, kiu havas nenion komunan kun la gastiga operaciumo. Nenio en la konzolo atentigas pri tiu diferenco. La simptomo aspektas kiel itinerara fuŝo, kaj kutime ĝi ne estas.

Apartigu la du testojn antaŭ ol ŝanĝi ion ajn

Atingi la pordegon pruvas la tunelon, la itineron al ĝia adreso kaj la sekurecan grupon, kiu permesas la interŝanĝon. Enkursigado por alia gastiganto pruvas neniom el tio: ĝi uzas alian fontadreson, alian celon kaj instancon en rolo, por kiu ĝi ne nepre estis konstruita. Skribu la du testojn aparte kaj notu, kiu malsukcesas, ĉar la korekto por ĉiu loĝas en alia konzolo. Pordega instanco konstruita nur por fini tunelojn havas nenian kaŭzon enkursigi por io alia, kaj ĝiaj defaŭltoj spegulas tion. Tial la dua testo bezonas sian propran agordon anstataŭ malgrandan alĝustigon de la unua.

Ping, kiu funkcias al la pordego, kaj ping, kiu malsukcesas al la gastiganto preter ĝi, ne estas intermita problemo. Ĝi estas la atendata konduto de instanco, al kiu oni ne diris, ke ĝi rajtas enkursigi.

Skribu la vojon antaŭ ol tuŝi agordon

Notu la klientan prefikson, la enkursigan instancon aŭ retinterfacon, la celan subreton kaj la respondon itineron. Vicaĵo en la VPC-itinerara tabelo montranta al instanco ne agordas la operaciumon de la instanco por enkursigi, kaj gastiga kerno kun enkursigado ŝaltita ne kreas VPC-itineron. Ambaŭ finoj de tiu rilato devas ekzisti, kaj ili estas redaktataj en malsamaj lokoj de homoj kun malsama aliro.

Poste inspektu la agordon de kontrolo de fonto/celo sur la efektiva enkursiga komponanto, ne sur ĉiu instanco en la VPC. AWS dokumentas, kial instanco, kiu enkursigas trafikon por aliaj, bezonas tiun kontrolon malŝaltita, kaj ankaŭ kial la agordo estas decido por ĉiu instanco anstataŭ defaŭlto por la tuta VPC.

Kvar limoj, kaj la kontrolo estas nur unu el ili

Traktu la vojon kiel kvar demandojn kaj respondu ilin laŭorde. La unua malsukcesa respondo estas kie la laboro estas, kaj neniu el la aliaj kompensos ĝin.

La ordo gravas, ĉar kontroli estas malmultekoste: itineroj videblas sur unu paĝo, la kontrolo estas unu atributo, kaj la opinio de la celo kutime estas la lasta afero, kiun iu demandas.

Traduko ŝanĝas, kiun fonton la celo vidas

Itinera dezajno konservas la fontadreson de la kliento, do la celo bezonas revenan itineron al la klienta prefikso. Tradukita dezajno anstataŭe prezentas la adreson de la pordego, kio forigas tiun postulon kaj anstataŭigas ĝin per stata tabelo sur la pordego. Decidu laŭ la arkitekturo, kiun vi intencas, anstataŭ aldoni tradukon ĉar nerilata ekzemplo uzis ĝin kaj ŝajnis funkcii.

Se vi tradukas, limigu la regulon al la klienta prefikso kaj la intencata celo. Se vi konservas, konfirmu, ke la malproksima flanko vere konas la itineron anstataŭ supozi, ke ĝi lernos unu.

Testu de la originala kliento, poste konservu la ŝanĝon

Peto generita sur la pordego povas sukcesi, dum enkursigita peto malsukcesas, ĉar ĝi estas alia fonto kaj alia enkursiga kazo. Post celita korekto, ripetu la ĝustan klient-al-risurca teston, kiu malsukcesis, de la sama kliento, kaj konfirmu, ke la respondo revenas, ne nur ke la peto alvenis.

Fine, metu la agordon en la administritan agordon de la pordego, por ke anstataŭa instanco ricevu ĝin. Sukcesa testo, kiu dependas de mana escepto, estas testo, kiu eksvalidiĝas ĉe la sekva rekonstruo, kaj la persono, kiu malkovris ĝin, ne estos tie por memori kial.