AWS Site-to-Site VPN naar NAT Gateway: VGW versus Transit Gateway

Iedereen tekent de eerste keer hetzelfde diagram: VPN de VPC in, NAT gateway naar internet, klaar. Maar AWS ondersteunt dat pad niet wanneer de VPN eindigt op een virtual private gateway, en de fout is zo stil dat teams hem meer dan eens opnieuw bouwen. Het ontwerp dat werkt vereist een transit gateway, wat de gateway en de routetabellen aan beide kanten verandert. Vergelijk de twee vormen voordat u iets tekent.

De topologie die vanzelfsprekend lijkt en niet wordt ondersteund

De documentatie over de NAT gateway van AWS trekt een lijn die iedereen verrast die alleen ontwerpen met één VPC heeft gebouwd: verkeer van een Site-to-Site VPN-verbinding kan niet via een virtual private gateway naar een NAT gateway worden gerouteerd. Het gatewaytype waarop de VPN eindigt bepaalt of er überhaupt een vertaalpad bestaat. De fout overleeft omdat de tunnelstatus UP is en een EC2-instantie in hetzelfde subnet zonder problemen internet bereikt. Geen van beide observaties test de kapotte richting.

In de praktijk komt het pakket aan met een bronadres uit het lokale netwerk en vindt het geen ondersteunde volgende hop die het zou vertalen. Afhankelijk van de tabellen wordt het bij de uitgangsgrens weggegooid, en omdat de tunnel UP blijft terwijl een instantie in hetzelfde subnet internet bereikt, wordt de fout gemeld als een firewallprobleem aan de lokale kant.

Virtual private gateway versus transit gateway

Een virtual private gateway hoort bij één VPC. Hij beëindigt de VPN, installeert routes in de routetabellen van die VPC en stopt daar. Hij heeft geen attachment-model en kan verkeer dus niet aan een andere VPC of aan een gedeeld uitgangssegment overhandigen. Die reikwijdte van één VPC is de hele beperking, en geen route die u in de VPC toevoegt verandert dat.

Een transit gateway is een regionale hub waar de VPN, elke spoke-VPC en een VPC voor gedeelde diensten allemaal als attachments verschijnen. Hij heeft eigen routetabellen, die bepalen welke attachment een bepaald prefix ontvangt.

Die hub maakt centrale uitgang mogelijk: de VPN landt als één attachment, de uitgangs-VPC als een tweede, en een routetabel van de transit gateway stuurt internetgerichte prefixen van de eerste naar de tweede. Met een virtual private gateway is er geen tweede attachment om iets naartoe te sturen, en daarom kan het ontwerp niet achteraf worden gerepareerd.

Het ondersteunde uitgangspad, hop voor hop

Het referentieontwerp heeft vijf hops en elke pijl is een routingbeslissing die u moet configureren. Het verkeer verlaat het lokale netwerk naar de Site-to-Site VPN-attachment, de transit-gateway-tabel stuurt het door naar de uitgangs-VPC-attachment, waar de subnettabel het naar een openbare NAT gateway stuurt. De NAT gateway vertaalt de bron en de internetgateway draagt het pakket naar buiten.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Twee details bepalen of de laatste hops werken. De NAT gateway moet openbaar zijn, met een elastisch IP en een route naar een internetgateway, want een private NAT gateway vertaalt tussen netwerken en wordt nooit een internetuitgang.

Plan één NAT gateway per Availability Zone die u wilt bedienen, met elke subnettabel die naar de lokale wijst. Houd de transit-gateway-tabel en de VPC-tabellen als aparte objecten in uw notities, want de ene kiest een attachment en de andere een resource binnen de VPC. Een standaardroute in slechts één van beide laat de helft van het pad ongedefinieerd en levert de deelstoringen op die het moeilijkst toe te schrijven zijn.

Op de retourweg falen deze ontwerpen

Een NAT gateway is stateful voor stromen die hij al heeft gezien, dus antwoorden op een uitgaande verbinding komen terug zonder nieuwe inkomende regel. Die eigenschap publiceert geen lokale dienst op internet, en haar behandelen alsof ze dat wel doet kost een team een dag debuggen aan een verbinding die nooit tot stand zou zijn gekomen. Voor verkeer dat de client start moeten vier routes overeenkomen: het lokale beleid, de transit-gateway-tabel, de uitgangs-subnettabel en de NAT-subnettabel. Mist u de laatste, dan verlaat het verzoek het gebouw terwijl het antwoord binnen AWS sterft.

Valideer met een echte client achter de VPN en kijk welk openbaar bronadres hij presenteert. Is dat het elastische IP van de NAT gateway, dan vindt vertaling plaats; is het iets anders, dan meet u een andere uitgang.

De asymmetrische variant van deze fout is het vroeg herkennen waard. Wanneer de NAT-subnettabel van de ene Availability Zone de retourroute naar het clientprefix heeft en een andere niet, slagen of falen nieuwe verbindingen afhankelijk van de zone waar de stroom landt, en het patroon wordt verkeerd gelezen als onstabiel internet. Vergelijk de subnettabellen van elke zone die u bedient in plaats van die te repareren waar het ticket werd geopend, want de ontbrekende route is de hele fout en aan de andere kant hoeft niets te veranderen.

Wanneer een expliciete proxy het betere ontwerp is

Een HTTP-proxy op een instantie in de uitgangs-VPC is een legitiem alternatief en vaak goedkoper. Clients worden geconfigureerd om hem te gebruiken, de proxy opent zijn eigen verbinding naar buiten, en de retourweg wordt zijn probleem in plaats van een symmetrische routingpuzzel. Voor enkele applicaties haalt dat het grootste deel van het transit-gateway-werk weg. Het levert ook logging per gebruiker die een NAT gateway niet kan produceren.

Transparant is hij echter niet. Alles wat proxyinstellingen negeert, en elk protocol dat geen HTTP is, volgt dat pad niet.

De keuze hangt af van wat uw applicaties feitelijk spreken en hoeveel identiteit u in de logs nodig heeft. Waar ze HTTP spreken, verdient de proxy zijn plek; waar u algemene uitgang voor willekeurige protocollen nodig heeft, is het transit-gateway-ontwerp het ontwerp dat AWS ondersteunt. Dat vooraf beslissen is goedkoper dan het ontdekken nadat de routetabellen zijn gebouwd.