Hvilken kilde-IP bruker en AWS NAT-gateway mot en VPN?

Du åpner VPC-konsollen fordi en partner spurte hvilket kildeområde som kommer inn over Site-to-Site-VPN-en. Siden NAT-gateways viser en offentlig gateway med en tilknyttet Elastic IP, og fristelsen er å sende den adressen og gå videre. Det er det riktige svaret for internettveien og det gale svaret for VPN-veien, og forskjellen er hvilken gateway rutetabellen peker på. Gå gjennom ruten før du skriver allowlisten.

Start på siden NAT-gateways, ikke i allowlisten

Siden NAT-gateways forteller deg subnettet, typen og Elastic IP-en, og de tre feltene er nok til å begynne. Det den ikke forteller, er veien trafikken tar etterpå. Det kommer fra rutetabellene som er knyttet til NAT-gatewayens subnett.

Les typen først, fordi offentlig eller privat avgjør om det senere dukker opp en internettgateway i kjeden. Les deretter subnettet, fordi det er der den andre ruten bor.

Følg de to oversettelsene

Både offentlige og private NAT-gatewayer oversetter arbeidsbelastningens private IPv4-kilde til NAT-gatewayens egen private IPv4-adresse. Den første oversettelsen skjer uansett type. Den andre oversettelsen er den folk glemmer: en offentlig NAT-gateway gir trafikken videre til internettgatewayen, som mapper adressen til den tilknyttede 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 veien er det ingen internettgateway i kjeden. Når trafikk går ut gjennom en transitgateway eller en virtuell privat gateway, dokumenterer veiledningen for NAT-gatewayer NAT-gatewayens private adresse som kilden den eksterne siden mottar. Det er den adressen partneren skal tillate, ikke Elastic IP-en.

VPN-veien viser vanligvis den private adressen

For en arbeidsbelastning i 10.20.1.0/24 som når et partnerprefiks, peker rutetabellen for arbeidsbelastningens subnett på NAT-gatewayen, og rutetabellen for NAT-gatewayens subnett peker på veien til den private gatewayen. Begge hoppene betyr noe, og bare det andre avgjør hva partneren ser. Hvis NAT-subnettet ikke har noen rute til VPN-veien, kommer pakken aldri frem, og det er en annen feil enn en gal kildeadresse.

Bekreft den andre ruten før du i det hele tatt snakker om adresser. En manglende rute og en feil rapportert kilde ser identiske ut for en partner som rett og slett ikke ser trafikk.

Når en andre oversettelse endrer svaret

AWS tilbyr også en eksplisitt, samsvarende en-til-en NAT-mapping på en transitgateway-tilknytning. Den mappingen kan oversette kilden enda en gang før den eksterne tjenesten ser den, og det er ikke standardatferden som bare ruter. Fordi den må konfigureres bevisst, bør du behandle den som et designunntak og ikke som noe du arver ved et uhell. Hvis ingen på teamet ditt husker å ha slått den på, antar du at den mangler til du har lest tilknytningen.

Hvis designet ditt bruker den, må allowlisten beskrive den endelige mappingen og ikke adressen til NAT-gatewayen. Samme forsiktighet gjelder for tilgjengelighetsveier: når flere gatewayadresser deltar, er det forventede kildesettet unionen, ikke én representativ adresse. Skriv ned hvilken oversettelse hver adresse hører til, fordi en liste uten opphav er umulig å revidere senere.

En privat NAT-gateway kan ikke få internettjeneste ved å peke den mot en internettgateway; AWS dokumenterer at slik trafikk forkastes. Velg typen ut fra hele veien, ikke ut fra ordet VPN i kravet.

Skriv kontrakten partneren din kan handle etter

Den brukbare kontrakten har fire deler: retningen strømmene startes fra, den oversatte identiteten partneren vil se, returruten for den identiteten og beskyttelsesomfanget som gjelder. NAT-gateway-strømmer startes fra den støttede opprinnelsessiden, så dette er ikke en inngående port-forwarding-tjeneste for å eksponere en privat arbeidsbelastning. Å si det høyt tidlig forhindrer en designgjennomgang der hver side antok at den andre startet.

Oversettelse kjøper lettelse for adresseoverlapp og en forutsigbar kildepolitikk, og det koster deg den individuelle arbeidsbelastningsidentiteten i partnerens logger. Hvis revisjonen trenger tilordning per arbeidsbelastning, behold den identiteten i applikasjonslaget i stedet for å prøve å gjenopprette den fra en oversatt kildeadresse.

Kontroller deretter begge rutetabellene etter enhver endring, fordi en ny tilknytning eller et subnett som er tilknyttet på nytt stille skriver om svaret.