Kiun fontan IP uzas AWS NAT-gateway direkte al VPN?

Vi malfermas la VPC-konzolon ĉar partnero demandis, kiu fonta intervalo alvenos tra la Site-to-Site VPN. La paĝo NAT-gateways montras publikan gateway kun ligita Elastic IP, kaj la tento estas sendi tiun adreson kaj iri plu. Ĝi estas la ĝusta respondo por la interreta vojo kaj la malĝusta respondo por la VPN-vojo, kaj la diferenco estas, al kiu gateway la enkursiga tabelo montras. Trairu la itineron antaŭ ol vi skribos la permesliston.

Komencu ĉe la paĝo NAT-gateways, ne ĉe la permeslisto

La paĝo NAT-gateways diras al vi la subreton, la tipon kaj la Elastic IP, kaj tiuj tri kampoj sufiĉas por komenci. Kion ĝi ne diras, estas la vojo, kiun la trafiko poste sekvas. Tio venas el la enkursigaj tabeloj ligitaj al la subreto de la NAT-gateway.

Legi unue la tipon, ĉar publika aŭ privata decidas, ĉu poste en la ĉeno aperos interreta gateway. Poste legi la subreton, ĉar tie loĝas la dua itinero.

Sekvu la du tradukojn

Kaj publikaj kaj privataj NAT-gateways tradukas la privatan IPv4-fonton de la laborŝarĝo al la propra privata IPv4-adreso de la NAT-gateway. Tiu unua traduko okazas sendepende de la tipo. La dua traduko estas tiu, kiun homoj forgesas: publika NAT-gateway transdonas la trafikon al la interreta gateway, kiu mapas la adreson al la ligita Elastic IP.

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

Sur la privata vojo mankas interreta gateway en la ĉeno. Kiam trafiko eliras tra transiga gateway aŭ virtuala privata gateway, la gvidilo pri NAT-gateways dokumentas la privatan adreson de la NAT-gateway kiel la fonton, kiun ricevas la malproksima flanko. Tiu estas la adreso, kiun la partnero devus permesi, ne la Elastic IP.

La VPN-vojo kutime montras la privatan adreson

Por laborŝarĝo en 10.20.1.0/24, kiu atingas partneran prefikson, la enkursiga tabelo de la subreto de la laborŝarĝo montras al la NAT-gateway, kaj la enkursiga tabelo de la subreto de la NAT-gateway montras al la vojo de la privata gateway. Ambaŭ saltoj gravas, kaj nur la dua decidas, kion vidas la partnero. Se la NAT-subreto havas neniun itineron al la VPN-vojo, la pako neniam alvenas, kaj tio estas alia fiasko ol malĝusta fonta adreso.

Kontrolu tiun duan itineron antaŭ ol vi entute parolos pri adresoj. Mankanta itinero kaj malĝuste raportita fonto aspektas idente al partnero, kiu simple ne vidas trafikon.

Kiam dua traduko ŝanĝas la respondon

AWS ankaŭ proponas eksplicitan, kongruan unu-al-unu NAT-mapon sur transiga gateway-ligo. Tiu mapo povas traduki la fonton denove antaŭ ol la malproksima servo vidas ĝin, kaj ĝi ne estas la defaŭlta konduto, kiu nur enkursigas. Ĉar ĝi devas esti agordita intence, traktu ĝin kiel projektan escepton, ne kiel ion, kion vi heredas hazarde. Se neniu en via teamo memoras ŝalti ĝin, supozu, ke ĝi mankas, ĝis vi legos la ligon.

Se via projekto uzas ĝin, la permeslisto devas priskribi la finan mapon, ne la adreson de la NAT-gateway. La sama singardo validas por haveblaj vojoj: kiam pluraj gateway-adresoj partoprenas, la atendata fonta aro estas la kuniĝo, ne unu reprezenta adreso. Notu, al kiu traduko apartenas ĉiu adreso, ĉar listo sen deveno neeblas revizii poste.

Privata NAT-gateway ne povas ricevi interretan servon per direktado al interreta gateway; AWS dokumentas, ke tia trafiko estas forĵetata. Elektu la tipon laŭ la tuta vojo, ne laŭ la vorto VPN en la postulo.

Skribu la kontrakton, laŭ kiu via partnero povas agi

La uzebla kontrakto havas kvar partojn: la direkton, el kiu la fluoj estas iniciatitaj, la tradukitan identecon, kiun la partnero vidos, la revenan itineron por tiu identeco, kaj la validan protektan amplekson. La fluoj de NAT-gateway estas iniciatitaj de la subtenata origina flanko, do tio ne estas envena pordadresada servo por elmeti privatan laborŝarĝon. Diri tion laŭte frue malhelpas projektan revizion, en kiu ĉiu flanko supozis, ke la alia iniciatis.

Traduko aĉetas malpeziĝon de adresa interkovro kaj antaŭvideblan fontan politikon, kaj ĝi kostas al vi la individuan identecon de la laborŝarĝo en la protokoloj de la partnero. Se revizio bezonas atribuon po laborŝarĝo, tenu tiun identecon en la aplikaĵa tavolo anstataŭ provi reakiri ĝin el tradukita fonta adreso.

Poste rekontrolu ambaŭ enkursigajn tabelojn post ajna ŝanĝo, ĉar nova ligo aŭ re-ligita subreto silente reverkas la respondon.