Vilken käll-IP använder en AWS NAT-gateway mot en VPN?

Du öppnar VPC-konsolen eftersom en partner frågade vilket källområde som kommer in över Site-to-Site-VPN:en. Sidan NAT-gateways visar en offentlig gateway med en kopplad Elastic IP, och frestelsen är att skicka den adressen och gå vidare. Det är rätt svar för internetvägen och fel svar för VPN-vägen, och skillnaden är vilken gateway routtabellen pekar på. Gå igenom rutten innan du skriver allowlistan.

Börja på sidan NAT-gateways, inte i allowlistan

Sidan NAT-gateways berättar subnätet, typen och Elastic IP:n, och de tre fälten räcker för att börja. Det den inte berättar är vägen trafiken tar efteråt. Det kommer från de routtabeller som är kopplade till NAT-gatewayens subnät.

Läs typen först, eftersom offentlig eller privat avgör om en internetgateway dyker upp senare i kedjan. Läs sedan subnätet, eftersom det är där den andra rutten bor.

Följ de två översättningarna

Både offentliga och privata NAT-gatewayer översätter arbetslastens privata IPv4-källa till NAT-gatewayens egen privata IPv4-adress. Den första översättningen sker oavsett typ. Den andra översättningen är den folk glömmer: en offentlig NAT-gateway lämnar trafiken vidare till internetgatewayen, som mappar adressen till den kopplade Elastic IP:n.

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 privata vägen finns ingen internetgateway i kedjan. När trafik går ut genom en transitgateway eller en virtuell privat gateway dokumenterar guiden för NAT-gatewayer NAT-gatewayens privata adress som den källa som fjärrsidan tar emot. Det är den adressen partnern ska tillåta, inte Elastic IP:n.

VPN-vägen visar oftast den privata adressen

För en arbetslast i 10.20.1.0/24 som når ett partnerprefix pekar arbetslastens subnät-routtabell på NAT-gatewayen, och NAT-gatewayens subnät-routtabell pekar på den privata gatewayens väg. Båda hoppen spelar roll, och bara det andra avgör vad partnern ser. Om NAT-subnätet inte har någon rutt till VPN-vägen kommer paketet aldrig fram, och det är ett annat fel än en felaktig källadress.

Verifiera den andra rutten innan du ens pratar om adresser. En saknad rutt och en felaktigt rapporterad källa ser identiska ut för en partner som helt enkelt inte ser någon trafik.

När en andra översättning ändrar svaret

AWS erbjuder också en explicit, matchande en-till-en-NAT-mappning på en transitgateway-anslutning. Den mappningen kan översätta källan ännu en gång innan fjärrtjänsten ser den, och det är inte standardbeteendet som bara routar. Eftersom den måste konfigureras medvetet bör du behandla den som ett designundantag och inte som något du ärver av misstag. Om ingen i ditt team minns att den slogs på, utgå från att den saknas tills du har läst anslutningen.

Om din design använder den måste allowlistan beskriva den slutliga mappningen och inte NAT-gatewayens adress. Samma försiktighet gäller för tillgänglighetsvägar: när flera gatewayadresser deltar är den förväntade källmängden unionen, inte en representativ adress. Skriv ned vilken översättning varje adress hör till, eftersom en lista utan ursprung är omöjlig att granska senare.

En privat NAT-gateway kan inte få internettjänst genom att peka den mot en internetgateway; AWS dokumenterar att sådan trafik kastas. Välj typen utifrån hela vägen, inte utifrån ordet VPN i kravet.

Skriv kontraktet som din partner kan agera på

Det användbara kontraktet har fyra delar: riktningen som flöden startas från, den översatta identitet partnern kommer att se, returrutten för den identiteten och det skyddsomfång som gäller. NAT-gateway-flöden startas från den stödda ursprungssidan, så detta är inte en ingående port-forwarding-tjänst för att exponera en privat arbetslast. Att säga det högt tidigt förhindrar en designgranskning där varje sida antog att den andra startade.

Översättning köper lättnad för adressöverlapp och en förutsägbar källpolicy, och det kostar dig den individuella arbetslastsidentiteten i partnerns loggar. Om revisionen behöver tilldelning per arbetslast, behåll den identiteten i applikationslagret i stället för att försöka återvinna den från en översatt källadress.

Kontrollera sedan båda routtabellerna efter varje ändring, eftersom en ny anslutning eller ett omkopplat subnät tyst skriver om svaret.