EC2 Elastic IP ne estas la privata VPN-adreso de la instanco

La instanco havas privatan adreson, la Elastic IP estas ligita al ĝi, kaj vojo por tiu publika /32 aldoniĝas al la VPN esperante, ke la du fariĝos la sama afero. Ili ne fariĝas. Elastic IP estas traduko farata ekster la gasto, de la interreta enirejo, sur trafiko, kiu sekvas la interretan vojon. La operaciumo de la gasto neniam vidas tiun adreson agordita sur retkarto. Aldoni ĝin al tunela interfaco ne reproduktas la supran tradukon kaj kreas duan, kontraŭdiran identecon por la sama maŝino.

Du adresoj, unu instanco

La retinterfaco de la instanco tenas privatan adreson ene de la VPC, kaj tio estas la adreso, kiun la gasto konas. La Elastic IP estas ligita al la sama interfaco sed vivas sur la publika flanko de la mapado.

Ĉio, kio atingas la instancon tra la interreto, alvenas tradukita al la privata adreso. Ĉio, kion la instanco sendas al la interreto, eliras kun la Elastic IP kiel fonto, denove pro tiu traduko.

Ene de la gasto ekzistas unu adreso. Ekstere ekzistas du. Tiu asimetrio klarigas plejparton de la konfuzo en ĉi tiu kampo. La gasto ne povas agordi, kion la enirejo tradukas. Ĝi povas respondi nur sur la adreso, kiun ĝi efektive tenas.

Kion la interreta enirejo efektive faras

La dokumentaro de AWS pri la interreta enirejo priskribas la aranĝon: la instanco konscias pri sia privata IPv4-adreso, kaj la enirejo provizas la respondan tradukon al publika IPv4 aŭ Elastic IP por trafiko sur la interreta vojo.

Tio estas traduko de retadresoj, ne kaŝnomo. La mapadon prizorgas la enirejo, ĝi estas ligita al la asocio kaj validas nur por pakaĵoj, kiuj trapasas ĝin. Forigu la asocion kaj la publika identeco malaperas, sen ke la gasto rimarku ion.

Tial privata VPN-pakaĵo adresita al la publika /32 ne estas reinterpretata kiel privata pakaĵo al la loka adreso de la gasto. La pakaĵo sekvas la vojon, kiun ĝi kongruas, kiu sendas ĝin al la interreta enirejo, kaj la konduto de la enirejo dependas de tio, ĉu la vojo estas permesata en ambaŭ direktoj.

Kial la lertaĵo de la tunela interfaco malsukcesas

Asigni la Elastic IP al tunela interfaco petas de la gasto trakti publikan adreson kiel lokan. Nun du aferoj postulas la saman adreson: la traduko de la enirejo sur la interreta vojo kaj la loka interfaco ene de la tunelo. La revena trafiko ne havas konsekvencan respondon, kiun el ili validas.

Eĉ kiam ŝajnas, ke ĝi funkcias, la dezajno kaŝis la veran demandon. Klientoj aŭ atingas la privatan adreson tra la tunelo aŭ atingas la publikan finpunkton tra la interreto, kaj la du vojoj havas malsamajn sekurecgrupojn, malsaman protokoladon kaj malsamajn fiaskmanierojn.

La adreso neniam estis la problemo. La elekto de vojo estis.

Tri celoj, tri dezajnoj

Se la celo estas publika VPN-finpunkto, la Elastic IP estas la ĝusta ilo: foraj egaluloj konektiĝas al ĝi tra la interreto kaj la ĉifrita transporto finiĝas sur la instanco. La interna aplikaĵa trafiko tiam uzas la privatan adreson.

Se la celo estas privata aliro al la aplikaĵo, la celo estas la privata adreso aŭ privata DNS-nomo, kiu solvas al ĝi, kaj la VPN-vojo, sekurecgrupo kaj revena vojo devas ĉiuj kongrui. La Elastic IP tute ne aperas en tiu dezajno.

Se la celo estas stabila publika elira identeco por VPN-uzantoj, tio estas NAT-dezajno sur la elira flanko, ne adreso sur la tunelo de la kliento. Tri celoj, kiuj sonas simile, produktas tri malsamajn diagramojn, kaj nur unu el ili implikas meti Elastic IP en novan lokon.

Kontrolu la vojon, kiun vi elektis

Por privata aliro, konfirmu, ke la VPN-vojo kovras la privatan prefikson, ke la voja tabelo de la VPC resendas trafikon al la tunelo, ke la sekurecgrupo permesas la fonton de la kliento kaj ke la propra fajroŝirmilo de la kliento permesas la respondon. Poste testu unu realan peton anstataŭ ping.

Por publika aliro, konfirmu la interretan eliron de la kliento, la enkursigon de la publika eniro kaj ĝian sekurec-politikon. Ĉu VPN-kliento povas atingi publikan finpunkton tra la tunelo dependas de la eliraj kaj fajroŝirmilaj reguloj de la tunelo, ne de la asocio de Elastic IP.

Se publika gastigantnomo devas funkcii de ambaŭ flankoj, uzu DNS-dezajnon, kiu respondas per la privata adreso por VPN-klientoj kaj per la publika adreso por ĉiuj aliaj, kaj tenu la atestilon valida por la nomo anstataŭ por la adreso. Ordo de laboro: nomu la celon, elektu la adreson, kiu apartenas al ĝi, poste kontrolu vojojn, politikon kaj unu peton.