Welk bron-IP gebruikt een AWS NAT-gateway richting een VPN?

Je opent de VPC-console omdat een partner vroeg welk bronbereik er via de Site-to-Site VPN zal aankomen. De pagina NAT-gateways toont een openbare gateway met een gekoppeld Elastic IP, en de verleiding is om dat adres te sturen en verder te gaan. Het is het juiste antwoord voor het internetpad en het verkeerde antwoord voor het VPN-pad, en het verschil is naar welke gateway de routetabel wijst. Loop de route na voordat je de allowlist schrijft.

Begin bij de pagina NAT-gateways, niet bij de allowlist

De pagina NAT-gateways vertelt je het subnet, het type en het Elastic IP, en die drie velden zijn genoeg om te beginnen. Wat de pagina niet vertelt, is welk pad het verkeer daarna aflegt. Dat komt uit de routetabellen die aan het subnet van de NAT-gateway hangen.

Lees eerst het type, want openbaar of privé bepaalt of er later in de keten een internetgateway opduikt. Lees dan het subnet, want daar zit de tweede route.

Volg de twee vertalingen

Zowel openbare als privé-NAT-gateways vertalen de privé-IPv4-bron van de workload naar het eigen privé-IPv4-adres van de NAT-gateway. Die eerste vertaling gebeurt ongeacht het type. De tweede vertaling is degene die mensen vergeten: een openbare NAT-gateway geeft het verkeer door aan de internetgateway, die het adres koppelt aan het bijbehorende 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

Op het privé-pad zit er geen internetgateway in de keten. Wanneer verkeer via een transitgateway of een virtual private gateway naar buiten gaat, beschrijft de NAT-gatewaygids het privéadres van de NAT-gateway als de bron die de externe kant ontvangt. Dat is het adres dat de partner moet toestaan, niet het Elastic IP.

Het VPN-pad laat meestal het privéadres zien

Voor een workload in 10.20.1.0/24 die een partnerprefix bereikt, wijst de routetabel van het workload-subnet naar de NAT-gateway, en de routetabel van het NAT-gateway-subnet wijst naar het pad van de private gateway. Beide hops zijn belangrijk, en alleen de tweede bepaalt wat de partner ziet. Als het NAT-subnet geen route naar het VPN-pad heeft, komt het pakket nooit aan, en dat is een ander falen dan een verkeerd bronadres.

Controleer die tweede route voordat je überhaupt over adressen praat. Een ontbrekende route en een verkeerd gemelde bron zien er voor een partner die simpelweg geen verkeer ziet precies hetzelfde uit.

Wanneer een tweede vertaling het antwoord verandert

AWS biedt ook een expliciete, bijpassende één-op-één NAT-mapping op een transitgateway-attachment. Die mapping kan de bron nog een keer vertalen voordat de externe service hem ziet, en dat is niet het standaardgedrag dat alleen routeert. Omdat je hem bewust moet configureren, behandel je hem als een ontwerpuitzondering en niet als iets wat je per ongeluk erft. Als niemand in je team zich herinnert dat hij is aangezet, ga er dan van uit dat hij ontbreekt tot je de attachment hebt gelezen.

Als je ontwerp hem gebruikt, moet de allowlist de uiteindelijke mapping beschrijven en niet het adres van de NAT-gateway. Dezelfde waarschuwing geldt voor beschikbaarheidspaden: wanneer er meerdere gatewayadressen meedoen, is de verwachte bronverzameling de vereniging, niet één representatief adres. Schrijf op bij welke vertaling elk adres hoort, want een lijst zonder herkomst is later niet te auditen.

Een privé-NAT-gateway kun je geen internetdienst geven door hem op een internetgateway te richten; AWS documenteert dat zulk verkeer wordt weggegooid. Kies het type op basis van het volledige pad, niet op basis van het woord VPN in de eis.

Schrijf het contract op waar je partner mee kan werken

Het bruikbare contract heeft vier onderdelen: de richting waarin stromen worden gestart, de vertaalde identiteit die de partner zal zien, de retourroute voor die identiteit, en de beschermingsscope die geldt. NAT-gatewaystromen worden gestart vanaf de ondersteunde oorsprongzijde, dus dit is geen inkomende port-forwardingdienst om een privé-workload bloot te leggen. Dat vroeg hardop zeggen voorkomt een ontwerpbeoordeling waarin elke kant aannam dat de andere kant het initiatief nam.

Vertaling levert verlichting van adresoverlap en een voorspelbaar bronbeleid, en het kost je de individuele workload-identiteit in de logs van de partner. Als audit attributie per workload nodig heeft, houd die identiteit dan op de applicatielaag in plaats van haar uit een vertaald bronadres te willen herstellen.

Controleer daarna beide routetabellen na elke wijziging, want een nieuwe attachment of een opnieuw gekoppeld subnet herschrijft het antwoord stilzwijgend.