Kjelde-/målsjekk er éi port, ikkje heile VPN-stien

VPN-et endar på ein EC2-instans, du kan nå tunneladressa til den instansen, og trafikk som skulle passere gjennom han mot ein annan privat vert, forsvinn. Det er to ulike testar, og å blande dei sløser bort timar. Den første spør om du kan nå instansen; den andre krev at han videresender trafikk for ein destinasjon som ikkje er hans eigen, noko som krev Linux-videresending, ein brannmurpolitikk, ei rute på den andre sida og eit løyve på AWS-nivå som ikkje har noko med gjesteoperativsystemet å gjere. Ingenting i konsollen leier merksemda mot den skilnaden. Symptomet ser ut som ein rutefeil, og det er det vanlegvis ikkje.

Skil dei to testane før du endrar noko

Å nå gatewayen provar tunnelen, ruta til adressa og sikkerheitsgruppa som tillèt utvekslinga. Videresending for ein annan vert provar ingenting av dette: ho brukar ei anna kjeldeadresse, ein annan destinasjon og ein instans i ei rolle han ikkje naudsynt er bygd for. Skriv dei to testane kvar for seg og noter kva for ein som feilar, fordi rettinga for kvar av dei ligg i ein annan konsoll. Ein gateway-instans bygd berre for å avslutte tunnelar har ingen grunn til å videresende for noko anna, og standardverdiane speglar det. Difor treng den andre testen sitt eige oppsett i staden for ei lita justering av den første.

Ein ping som virkar til gatewayen, og ein ping som feilar til verten bak han, er ikkje eit periodisk problem. Det er forventa åtferd frå ein instans som ikkje har fått beskjed om at han kan videresende.

Skriv ned stien før du rører ei innstilling

Noter klientprefikset, den videresendande instansen eller nettverksgrensesnittet, målsubnettet og svarreturruta. Ei oppføring i VPC-rutetabellen som peikar på ein instans, konfigurerer ikkje operativsystemet til instansen for videresending, og ein gjestekjerne med videresending slått på lagar ikkje ei VPC-rute. Begge endane av det tilhøvet må finnast, og dei blir redigerte på ulike stader av folk med ulik tilgang.

Undersøk deretter innstillinga for kjelde-/målsjekk på den faktiske videresendingskomponenten, ikkje på kvar instans i VPC-en. AWS dokumenterer kvifor ein instans som videresender trafikk for andre, må ha den sjekken deaktivert, og òg kvifor innstillinga er ei avgjerd per instans og ikkje ein standard for heile VPC-en.

Fire grenser, og sjekken er berre éi av dei

Handter stien som fire spørsmål og svar på dei i rekkjefølgje. Det første svaret som feilar, er der arbeidet ligg, og ingen av dei andre vil kompensere for det.

Rekkjefølgja har noko å seie fordi det er billeg å kontrollere: ruter er synlege på éi side, sjekken er eitt attributt, og meininga til destinasjonen er vanlegvis det siste nokon spør om.

Omsetjing endrar kva kjelde destinasjonen ser

Eit ruta design bevarer kjeldeadressa til klienten, så destinasjonen treng ei returrute til klientprefikset. Eit omsett design presenterer i staden adressa til gatewayen, noko som fjernar det kravet og erstattar det med ein tilstandstabell på gatewayen. Avgjer ut frå arkitekturen du siktar mot, i staden for å leggje til omsetjing fordi eit urelatert døme brukte det og såg ut til å verke.

Viss du omset, avgrens regelen til klientprefikset og den tiltenkte destinasjonen. Viss du bevarer, stadfest at den andre sida faktisk kjenner ruta i staden for å gå ut frå at ho lærer éi.

Test frå den opphavlege klienten, og hald deretter endringa

Ein førespurnad som blir generert på gatewayen, kan lukkast medan ein videresend førespurnad feilar, fordi det er ei anna kjelde og eit anna videresendingstilfelle. Etter ei målretta retting, repetér den nøyaktige klient-til-ressurs-testen som feila, frå same klient, og stadfest at svaret kjem tilbake og ikkje berre at førespurnaden kom fram.

Til slutt, legg innstillinga i den styrte konfigurasjonen til gatewayen slik at ein erstatningsinstans får ho. Ein vellykka test som er avhengig av eit manuelt unntak, er ein test som går ut ved neste gjenoppbygging, og personen som oppdaga han, vil ikkje vere der for å hugse kvifor.