Watter bron-IP gebruik ’n AWS NAT-gateway na ’n VPN?

Jy maak die VPC-konsole oop omdat ’n vennoot gevra het watter bronbestek oor die Site-to-Site VPN sal aankom. Die bladsy NAT-gateways wys ’n openbare gateway met ’n gekoppelde Elastic IP, en die versoeking is om daardie adres te stuur en aan te beweeg. Dit is die regte antwoord vir die internetpad en die verkeerde antwoord vir die VPN-pad, en die verskil is na watter gateway die roetekaart wys. Stap die roete na voordat jy die toelatingslys skryf.

Begin by die bladsy NAT-gateways, nie by die toelatingslys

Die bladsy NAT-gateways vertel jou die subnet, die tipe en die Elastic IP, en daardie drie velde is genoeg om te begin. Wat dit nie sê nie, is watter pad die verkeer daarna volg. Dit kom uit die roetekaarte wat aan die NAT-gateway se subnet gekoppel is.

Lees eers die tipe, want openbaar of privaat bepaal of daar later in die ketting ’n internetgateway verskyn. Lees dan die subnet, want dit is waar die tweede roete woon.

Volg die twee vertalings

Beide openbare en private NAT-gateways vertaal die werklas se private IPv4-bron na die NAT-gateway se eie private IPv4-adres. Daardie eerste vertaling gebeur ongeag die tipe. Die tweede vertaling is die een wat mense vergeet: ’n openbare NAT-gateway gee die verkeer aan die internetgateway oor, wat die adres na die gekoppelde Elastic IP kaart.

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 die private pad is daar geen internetgateway in die ketting nie. Wanneer verkeer deur ’n transitgateway of ’n virtuele private gateway uitgaan, beskryf die NAT-gatewaygids die NAT-gateway se private adres as die bron wat die afgeleë kant ontvang. Dit is die adres wat die vennoot moet toelaat, nie die Elastic IP nie.

Die VPN-pad wys gewoonlik die private adres

Vir ’n werklas in 10.20.1.0/24 wat ’n vennootvoorvoegsel bereik, wys die werklas-subnet se roetekaart na die NAT-gateway, en die NAT-gateway se subnet-roetekaart wys na die private gateway-pad. Beide spronge maak saak, en net die tweede bepaal wat die vennoot sien. As die NAT-subnet geen roete na die VPN-pad het nie, kom die pakket nooit aan nie, wat ’n ander fout is as ’n verkeerde bronadres.

Kontroleer daardie tweede roete voordat jy hoegenaamd oor adresse praat. ’n Ontbrekende roete en ’n verkeerd gerapporteerde bron lyk identies vir ’n vennoot wat bloot geen verkeer sien nie.

Wanneer ’n tweede vertaling die antwoord verander

AWS bied ook ’n eksplisiete, bypassende een-tot-een NAT-kaart op ’n transitgateway-aanhegsel. Daardie kaart kan die bron weer vertaal voordat die afgeleë diens dit sien, en dit is nie die verstekgedrag wat net roeteer nie. Omdat dit doelbewus opgestel moet word, behandel dit as ’n ontwerpuitsondering eerder as iets wat jy per ongeluk erf. As niemand in jou span onthou dat dit aangeskakel is nie, neem aan dit ontbreek totdat jy die aanhegsel gelees het.

As jou ontwerp dit gebruik, moet die toelatingslys die finale kaart beskryf, nie die NAT-gateway se adres nie. Dieselfde waarskuwing geld vir beskikbaarheidspaaie: wanneer verskeie gateway-adresse deelneem, is die verwagte bronversameling die vereniging, nie een verteenwoordigende adres nie. Skryf neer by watter vertaling elke adres hoort, want ’n lys sonder herkoms is later onmoontlik om te oudit.

’n Private NAT-gateway kan nie internetdiens kry deur dit op ’n internetgateway te rig nie; AWS dokumenteer dat sulke verkeer laat vaar word. Kies die tipe op grond van die volle pad, nie op grond van die woord VPN in die vereiste nie.

Skryf die kontrak neer waarop jou vennoot kan handel

Die bruikbare kontrak het vier dele: die rigting waarin strome begin word, die vertaalde identiteit wat die vennoot sal sien, die terugroete vir daardie identiteit, en die beskermingsomvang wat geld. NAT-gateway-strome begin van die ondersteunde oorsprongkant, so dit is nie ’n inkomende poortaanstuurdiens om ’n private werklas bloot te stel nie. Om dit vroeg hardop te sê, verhoed ’n ontwerphersiening waarin elke kant aangeneem het die ander kant begin die stroom.

Vertaling koop verligting van adresoorvleueling en ’n voorspelbare bronbeleid, en dit kos jou individuele werklas-identiteit in die vennoot se logs. As oudit attribusie per werklas nodig het, hou daardie identiteit op die toepassingslaag eerder as om dit uit ’n vertaalde bronadres te probeer herstel.

Kontroleer dan albei roetekaarte ná enige verandering, want ’n nuwe aanhegsel of ’n hergekoppelde subnet herskryf die antwoord stilweg.