Hvilken kilde-IP bruger en AWS NAT-gateway mod en VPN?

Du åbner VPC-konsollen, fordi en partner spurgte, hvilket kildeområde der ankommer over Site-to-Site-VPN’en. Siden NAT-gateways viser en offentlig gateway med en tilknyttet Elastic IP, og fristelsen er at sende den adresse og gå videre. Det er det rigtige svar for internetstien og det forkerte svar for VPN-stien, og forskellen er, hvilken gateway rutetabellen peger på. Gå ruten igennem, før du skriver allowlisten.

Start på siden NAT-gateways, ikke i allowlisten

Siden NAT-gateways fortæller dig subnettet, typen og Elastic IP’en, og de tre felter er nok til at begynde. Det, den ikke fortæller, er den sti, trafikken tager bagefter. Det kommer fra de rutetabeller, der er knyttet til NAT-gatewayens subnet.

Læs typen først, fordi offentlig eller privat afgør, om der senere dukker en internetgateway op i kæden. Læs derefter subnettet, fordi det er der, den anden rute bor.

Følg de to oversættelser

Både offentlige og private NAT-gateways oversætter arbejdsbyrdens private IPv4-kilde til NAT-gatewayens egen private IPv4-adresse. Den første oversættelse sker uanset type. Den anden oversættelse er den, folk glemmer: en offentlig NAT-gateway giver trafikken videre til internetgatewayen, som mapper adressen til den tilknyttede 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

På den private sti er der ingen internetgateway i kæden. Når trafik forlader gennem en transitgateway eller en virtuel privat gateway, dokumenterer vejledningen for NAT-gateways NAT-gatewayens private adresse som den kilde, den fjernede side modtager. Det er den adresse, partneren skal tillade, ikke Elastic IP’en.

VPN-stien viser normalt den private adresse

For en arbejdsbyrde i 10.20.1.0/24, der når et partnerpræfiks, peger arbejdsbyrdens subnet-rutetabel på NAT-gatewayen, og NAT-gatewayens subnet-rutetabel peger på den private gateway-sti. Begge hop betyder noget, og kun det andet afgør, hvad partneren ser. Hvis NAT-subnettet ikke har nogen rute til VPN-stien, ankommer pakken aldrig, og det er en anden fejl end en forkert kildeadresse.

Bekræft den anden rute, før du overhovedet taler om adresser. En manglende rute og en forkert rapporteret kilde ser identiske ud for en partner, der simpelthen ikke ser trafik.

Når en anden oversættelse ændrer svaret

AWS tilbyder også en eksplicit, matchende en-til-en NAT-mapping på en transitgateway-tilknytning. Den mapping kan oversætte kilden endnu en gang, før den fjernede tjeneste ser den, og det er ikke standardadfærden, der kun router. Fordi den skal konfigureres bevidst, skal du behandle den som en designundtagelse og ikke som noget, du arver ved et uheld. Hvis ingen i dit team husker at have slået den til, skal du antage, at den ikke findes, indtil du har læst tilknytningen.

Hvis dit design bruger den, skal allowlisten beskrive den endelige mapping og ikke NAT-gatewayens adresse. Samme forsigtighed gælder for tilgængelighedsstier: når flere gatewayadresser deltager, er det forventede kildesæt foreningen, ikke én repræsentativ adresse. Skriv ned, hvilken oversættelse hver adresse hører til, fordi en liste uden oprindelse er umulig at revidere senere.

En privat NAT-gateway kan ikke få internettjeneste ved at pege den på en internetgateway; AWS dokumenterer, at sådan trafik kasseres. Vælg typen ud fra den fulde sti, ikke ud fra ordet VPN i kravet.

Skriv den kontrakt, din partner kan handle på

Den brugbare kontrakt har fire dele: den retning, strømme startes fra, den oversatte identitet, partneren vil se, returruten for den identitet og det beskyttelsesomfang, der gælder. NAT-gateway-strømme startes fra den understøttede oprindelsesside, så dette er ikke en indgående port-forwarding-tjeneste til at eksponere en privat arbejdsbyrde. At sige det højt tidligt forhindrer en designgennemgang, hvor hver side antog, at den anden startede.

Oversættelse køber lettelse for adresseoverlap og en forudsigelig kildepolitik, og det koster dig den individuelle arbejdsbyrdeidentitet i partnerens logfiler. Hvis revisionen kræver tildeling per arbejdsbyrde, skal du beholde den identitet i applikationslaget i stedet for at forsøge at genskabe den fra en oversat kildeadresse.

Kontroller derefter begge rutetabeller efter enhver ændring, fordi en ny tilknytning eller et gentilknyttet subnet stille omskriver svaret.