Kva kjelde-IP brukar ein AWS NAT-gateway mot ein VPN?

Du opnar VPC-konsollen fordi ein partnar spurde kva kjeldeområde som kjem inn over Site-to-Site-VPN-en. Sida NAT-gateways viser ein offentleg gateway med ein tilknytt Elastic IP, og freistinga er å sende den adressa og gå vidare. Det er det rette svaret for internettvegen og det gale svaret for VPN-vegen, og skilnaden er kva gateway rutetabellen peikar på. Gå gjennom ruta før du skriv allowlista.

Start på sida NAT-gateways, ikkje i allowlista

Sida NAT-gateways fortel deg subnettet, typen og Elastic IP-en, og dei tre felta er nok til å byrje. Det ho ikkje fortel, er vegen trafikken tek etterpå. Det kjem frå rutetabellane som er knytte til subnettet til NAT-gatewayen.

Les typen først, fordi offentleg eller privat avgjer om det seinare dukkar opp ein internettgateway i kjeda. Les deretter subnettet, fordi det er der den andre ruta bur.

Følg dei to omsetjingane

Både offentlege og private NAT-gatewayar omset den private IPv4-kjelda til arbeidslasta til NAT-gatewayen si eiga private IPv4-adresse. Den første omsetjinga skjer uansett type. Den andre omsetjinga er den folk gløymer: ein offentleg NAT-gateway gjev trafikken vidare til internettgatewayen, som mappar adressa til den tilknytte Elastic IP-en.

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

På den private vegen er det ingen internettgateway i kjeda. Når trafikk går ut gjennom ein transitgateway eller ein virtuell privat gateway, dokumenterer rettleiinga for NAT-gatewayar den private adressa til NAT-gatewayen som kjelda den fjerne sida tek imot. Det er den adressa partnaren skal tillate, ikkje Elastic IP-en.

VPN-vegen viser vanlegvis den private adressa

For ei arbeidslast i 10.20.1.0/24 som når eit partnarprefiks, peikar rutetabellen for subnettet til arbeidslasta på NAT-gatewayen, og rutetabellen for subnettet til NAT-gatewayen peikar på vegen til den private gatewayen. Begge hoppa tel, og berre det andre avgjer kva partnaren ser. Viss NAT-subnettet ikkje har noka rute til VPN-vegen, kjem pakken aldri fram, og det er ein annan feil enn ei gal kjeldeadresse.

Stadfest den andre ruta før du i det heile snakkar om adresser. Ei manglande rute og ei feil rapportert kjelde ser identiske ut for ein partnar som rett og slett ikkje ser trafikk.

Når ei andre omsetjing endrar svaret

AWS tilbyr også ein eksplisitt, samsvarande ein-til-ein NAT-mapping på ein transitgateway-tilknyting. Den mappinga kan omsetje kjelda endå ein gong før den fjerne tenesta ser ho, og det er ikkje standardåtferda som berre rutar. Fordi ho må konfigurerast medvite, bør du handsame ho som eit designunntak og ikkje som noko du arvar ved eit uhell. Viss ingen på teamet ditt hugsar å ha slått ho på, går du ut frå at ho manglar til du har lese tilknytinga.

Viss designet ditt brukar ho, må allowlista skildre den endelege mappinga og ikkje adressa til NAT-gatewayen. Same varsemd gjeld for tilgjengelegheitsvegar: når fleire gatewayadresser deltek, er det forventa kjeldemengda unionen, ikkje éi representativ adresse. Skriv ned kva omsetjing kvar adresse høyrer til, fordi ei liste utan opphav er umogleg å revidere seinare.

Ein privat NAT-gateway kan ikkje få internettteneste ved å peike han mot ein internettgateway; AWS dokumenterer at slik trafikk blir kasta. Vel typen ut frå heile vegen, ikkje ut frå ordet VPN i kravet.

Skriv kontrakten partnaren din kan handle etter

Den brukbare kontrakten har fire delar: retninga som straumane blir starta frå, den omsette identiteten partnaren vil sjå, returruta for den identiteten og beskyttelsesomfanget som gjeld. NAT-gateway-straumar blir starta frå den støtta opphavssida, så dette er ikkje ei inngåande port-forwarding-teneste for å eksponere ei privat arbeidslast. Å seie det høgt tidleg hindrar ein designgjennomgang der kvar side antok at den andre starta.

Omsetjing kjøper lettnad for adresseoverlapp og ein føreseieleg kjelde politikk, og det kostar deg den individuelle arbeidslastidentiteten i loggane til partnaren. Viss revisjonen treng tildeling per arbeidslast, hald den identiteten i applikasjonslaget i staden for å prøve å gjenopprette han frå ei omsett kjeldeadresse.

Kontroller deretter begge rutetabellane etter kvar endring, fordi ei ny tilknyting eller eit subnett som er knytt til på nytt stille skriv om svaret.