AWS Site-to-Site VPN verso NAT Gateway: VGW o Transit Gateway

Tutti disegnano lo stesso schema la prima volta: VPN nella VPC, NAT gateway verso Internet, fatto. Ma AWS non supporta quel percorso quando la VPN termina su un virtual private gateway, e il guasto è abbastanza silenzioso che i team lo ricostruiscono più di una volta. Il progetto che funziona richiede un transit gateway, che cambia il gateway e le tabelle di routing su entrambi i lati. Confrontate le due forme prima di disegnare qualsiasi cosa.

La topologia che sembra ovvia e non è supportata

La documentazione del NAT gateway di AWS traccia una linea che sorprende chiunque abbia costruito solo progetti a VPC singola: il traffico di una connessione Site-to-Site VPN non può essere instradato verso un NAT gateway attraverso un virtual private gateway. Il tipo di gateway su cui termina la VPN decide se esiste un percorso di traduzione. L’errore sopravvive perché il tunnel è UP e un’istanza EC2 nella stessa subnet raggiunge Internet senza problemi. Nessuna delle due osservazioni verifica la direzione rotta.

In pratica il pacchetto arriva con un indirizzo di origine della rete locale e non trova un salto successivo supportato che lo traduca. A seconda delle tabelle viene scartato al confine di uscita e, poiché il tunnel resta UP mentre un’istanza nella stessa subnet raggiunge Internet, il guasto viene segnalato come problema di firewall locale.

Virtual private gateway o transit gateway

Un virtual private gateway appartiene a una sola VPC. Termina la VPN, installa le route nelle tabelle di quella VPC e si ferma lì. Non ha un modello di attachment, quindi non può consegnare traffico a un’altra VPC né a un segmento di uscita condiviso. Quella portata di una sola VPC è tutta la limitazione, e nessuna route aggiunta dentro la VPC la cambia.

Un transit gateway è un hub regionale dove la VPN, ogni VPC spoke e una VPC di servizi condivisi compaiono come attachment. Ha le proprie tabelle di routing, che scelgono quale attachment riceve un dato prefisso.

È quell’hub a rendere possibile l’uscita centralizzata: la VPN atterra come un attachment, la VPC di uscita come un altro, e una tabella del transit gateway invia i prefissi verso Internet dal primo al secondo. Con un virtual private gateway non c’è un secondo attachment a cui inviare qualcosa, per questo il progetto non si può rattoppare dopo.

Il percorso di uscita supportato, salto per salto

Il progetto di riferimento ha cinque salti e ogni freccia è una decisione di routing da configurare. Il traffico lascia la rete locale verso l’attachment Site-to-Site VPN, la tabella del transit gateway lo inoltra all’attachment della VPC di uscita, dove la tabella della subnet lo manda a un NAT gateway pubblico. Il NAT gateway traduce l’origine e l’internet gateway porta il pacchetto fuori.

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

Due dettagli decidono se gli ultimi salti funzionano. Il NAT gateway deve essere pubblico, con un elastic IP e una route verso un internet gateway, perché un NAT gateway privato traduce tra reti e non diventa mai un’uscita Internet.

Pianificate un NAT gateway per ogni Availability Zone che volete servire, con ogni tabella di subnet che punta a quella locale. Tenete la tabella del transit gateway e le tabelle della VPC come oggetti separati nelle vostre note, perché una sceglie un attachment e l’altra una risorsa dentro la VPC. Una route predefinita solo in una delle due lascia metà del percorso indefinito e produce i guasti parziali più difficili da attribuire.

Il percorso di ritorno è dove questi progetti falliscono

Un NAT gateway è stateful per i flussi che ha già visto, quindi le risposte a una connessione in uscita tornano senza una nuova regola in ingresso. Questa proprietà non pubblica un servizio locale su Internet, e trattarla come se lo facesse è come un team perde una giornata a fare debug di una connessione che non si sarebbe mai stabilita. Per il traffico originato dal client devono concordare quattro route: la policy locale, la tabella del transit gateway, la tabella della subnet di uscita e la tabella della subnet NAT. Se manca l’ultima, la richiesta esce dall’edificio mentre la risposta muore dentro AWS.

Verificate con un client reale dietro la VPN e guardate quale indirizzo di origine pubblico presenta. Se è l’elastic IP del NAT gateway, la traduzione avviene; se è altro, state misurando un’altra uscita.

La versione asimmetrica di questo guasto vale la pena riconoscerla presto. Quando la tabella della subnet NAT di una Availability Zone ha la route di ritorno verso il prefisso del client e un’altra no, le nuove connessioni riescono o falliscono a seconda della zona in cui cade il flusso, e il modello viene letto male come Internet instabile. Confrontate le tabelle delle subnet di ogni zona che servite invece di riparare quella dove è stato aperto il ticket, perché la route mancante è tutto il guasto e dall’altro lato non serve cambiare nulla.

Quando un proxy esplicito è il progetto migliore

Un proxy HTTP su un’istanza nella VPC di uscita è un’alternativa legittima e spesso più economica. I client vengono configurati per usarlo, il proxy apre la propria connessione verso l’esterno e il percorso di ritorno diventa un suo problema invece di un rebus di routing simmetrico. Per poche applicazioni questo elimina la maggior parte del lavoro del transit gateway. Dà anche log per utente che un NAT gateway non può produrre.

Non è trasparente, però. Tutto ciò che ignora le impostazioni del proxy, e ogni protocollo che non sia HTTP, non seguirà quel percorso.

La scelta dipende da cosa parlano davvero le vostre applicazioni e da quanta identità serve nei log. Dove parlano HTTP, il proxy si guadagna il suo posto; dove serve un’uscita generale per protocolli arbitrari, il progetto con transit gateway è quello supportato da AWS. Deciderlo in anticipo costa meno che scoprirlo dopo aver costruito le tabelle di routing.