AWS Site-to-Site VPN către NAT Gateway: VGW versus Transit Gateway

Toți desenează aceeași schemă prima dată: VPN în VPC, NAT gateway spre internet, gata. Însă AWS nu acceptă acea cale când VPN-ul se termină pe un virtual private gateway, iar eșecul este atât de silențios încât echipele îl reconstruiesc mai mult de o dată. Proiectul care funcționează necesită un transit gateway, ceea ce schimbă gateway-ul și tabelele de rute pe ambele părți. Comparați cele două forme înainte de a desena ceva.

Topologia care pare evidentă și nu este acceptată

Documentația pentru NAT gateway din AWS trasează o linie care surprinde pe oricine a construit doar proiecte cu un singur VPC: traficul dintr-o conexiune Site-to-Site VPN nu poate fi rutat către un NAT gateway printr-un virtual private gateway. Tipul de gateway pe care se termină VPN-ul decide dacă există deloc o cale de traducere. Eroarea supraviețuiește pentru că starea tunelului este UP și o instanță EC2 din același subnet ajunge la internet fără probleme. Niciuna dintre cele două observații nu testează direcția stricată.

În practică pachetul sosește cu o adresă sursă din rețeaua locală și nu găsește un hop următor acceptat care să îl traducă. În funcție de tabele, este aruncat la granița de ieșire, iar pentru că tunelul rămâne UP în timp ce o instanță din același subnet ajunge la internet, eșecul este raportat ca problemă de firewall local.

Virtual private gateway versus transit gateway

Un virtual private gateway aparține unui singur VPC. Termină VPN-ul, instalează rute în tabelele acelui VPC și se oprește acolo. Nu are model de attachment, deci nu poate preda trafic altui VPC sau unui segment de ieșire partajat. Această anvergură de un singur VPC este întreaga limitare, iar nicio rută adăugată în VPC nu o schimbă.

Un transit gateway este un hub regional în care VPN-ul, fiecare VPC spoke și un VPC de servicii partajate apar ca attachment-uri. Are propriile tabele de rute, care aleg ce attachment primește un anumit prefix.

Acest hub face posibilă ieșirea centralizată: VPN-ul aterizează ca un attachment, VPC-ul de ieșire ca altul, iar o tabelă de rute a transit gateway trimite prefixele către internet de la primul la al doilea. Cu un virtual private gateway nu există un al doilea attachment către care să trimiți ceva, de aceea proiectul nu poate fi peticit ulterior.

Calea de ieșire acceptată, hop cu hop

Proiectul de referință are cinci hop-uri și fiecare săgeată este o decizie de rutare pe care trebuie să o configurați. Traficul iese din rețeaua locală în attachment-ul Site-to-Site VPN, tabela transit gateway îl trimite mai departe către attachment-ul VPC de ieșire, unde tabela subnet-ului îl trimite către un NAT gateway public. NAT gateway traduce sursa, iar internet gateway scoate pachetul afară.

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

Două detalii decid dacă ultimele hop-uri funcționează. NAT gateway trebuie să fie public, cu un elastic IP și o rută către un internet gateway, pentru că un NAT gateway privat traduce între rețele și nu devine niciodată o ieșire spre internet.

Planificați un NAT gateway pentru fiecare Availability Zone pe care intenționați să o deserviți, cu fiecare tabelă de subnet îndreptată către cel local. Țineți tabela transit gateway și tabelele VPC ca obiecte separate în notițe, pentru că una alege un attachment, iar cealaltă alege o resursă din interiorul VPC. O rută implicită doar într-una dintre ele lasă jumătate din cale nedefinită și produce eșecurile parțiale care sunt cel mai greu de atribuit.

Pe calea de întoarcere eșuează aceste proiecte

Un NAT gateway ține starea pentru fluxurile pe care le-a văzut deja, așa că răspunsurile la o conexiune de ieșire se întorc fără o regulă nouă de intrare. Această proprietate nu publică un serviciu local pe internet, iar a o trata ca și cum ar face-o costă o echipă o zi de depanare a unei conexiuni care nu s-ar fi stabilit niciodată. Pentru traficul inițiat de client trebuie să fie de acord patru rute: politica locală, tabela transit gateway, tabela subnet-ului de ieșire și tabela subnet-ului NAT. Dacă lipsește ultima, cererea părăsește clădirea în timp ce răspunsul moare în interiorul AWS.

Validați cu un client real din spatele VPN-ului și uitați-vă ce adresă sursă publică prezintă. Dacă este elastic IP-ul NAT gateway-ului, traducerea are loc; dacă este altceva, măsurați o altă ieșire.

Versiunea asimetrică a acestui eșec merită recunoscută devreme. Când tabela subnet-ului NAT dintr-o Availability Zone are ruta de întoarcere către prefixul clientului, iar alta nu, conexiunile noi reușesc sau eșuează în funcție de zona în care aterizează fluxul, iar tiparul este citit greșit ca internet instabil. Comparați tabelele de subnet pentru fiecare zonă pe care o deserviți în loc să o reparați pe cea în care s-a deschis tichetul, pentru că ruta lipsă este întreaga defecțiune și nimic nu trebuie schimbat în cealaltă parte.

Când un proxy explicit este proiectul mai bun

Un proxy HTTP pe o instanță din VPC-ul de ieșire este o alternativă legitimă și adesea mai ieftină. Clienții sunt configurați să îl folosească, proxy-ul își deschide propria conexiune spre exterior, iar calea de întoarcere devine problema lui, nu un rebus de rutare simetrică. Pentru puține aplicații, asta elimină cea mai mare parte a muncii cu transit gateway. Oferă și jurnalizare pe utilizator pe care un NAT gateway nu o poate produce.

Nu este însă transparent. Orice ignoră setările de proxy, și orice protocol care nu este HTTP, nu vor urma acea cale.

Alegerea depinde de ce vorbesc de fapt aplicațiile dumneavoastră și de câtă identitate aveți nevoie în jurnale. Acolo unde vorbesc HTTP, proxy-ul își câștigă locul; acolo unde aveți nevoie de ieșire generală pentru protocoale arbitrare, proiectul cu transit gateway este cel acceptat de AWS. Să decideți asta dinainte costă mai puțin decât să descoperiți după ce tabelele de rute sunt construite.