Quale IP di origine usa un gateway NAT di AWS verso una VPN?

Apri la console VPC perché un partner ha chiesto quale intervallo di origine arriverà tramite la VPN da sito a sito. La pagina dei gateway NAT mostra un gateway pubblico con un Elastic IP associato, e la tentazione è inviare quell’indirizzo e proseguire. È la risposta giusta per il percorso internet e quella sbagliata per il percorso VPN, e la differenza sta a quale gateway punta la tabella di routing. Ripercorri la rotta prima di scrivere l’elenco degli indirizzi consentiti.

Parti dalla pagina dei gateway NAT, non dall’elenco degli indirizzi consentiti

La pagina dei gateway NAT ti dice la subnet, il tipo e l’Elastic IP, e questi tre campi bastano per iniziare. Quello che non dice è il percorso che il traffico segue dopo. Questo deriva dalle tabelle di routing associate alla subnet del gateway NAT.

Leggi prima il tipo, perché pubblico o privato decide se più avanti nella catena comparirà un gateway internet. Poi leggi la subnet, perché è lì che vive la seconda rotta.

Segui le due traduzioni

Sia i gateway NAT pubblici sia quelli privati traducono l’origine IPv4 privata del carico di lavoro nell’indirizzo IPv4 privato del gateway NAT stesso. Questa prima traduzione avviene indipendentemente dal tipo. La seconda traduzione è quella che si dimentica: un gateway NAT pubblico consegna il traffico al gateway internet, che mappa l’indirizzo sull’Elastic IP associato.

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

Sul percorso privato non c’è alcun gateway internet nella catena. Quando il traffico esce attraverso un gateway di transito o un gateway privato virtuale, la guida ai gateway NAT documenta l’indirizzo privato del gateway NAT come origine che il lato remoto riceve. È quell’indirizzo che il partner deve consentire, non l’Elastic IP.

Il percorso VPN di solito mostra l’indirizzo privato

Per un carico di lavoro in 10.20.1.0/24 che raggiunge un prefisso del partner, la tabella di routing della subnet del carico punta al gateway NAT, e la tabella di routing della subnet del gateway NAT punta al percorso del gateway privato. Entrambi i salti contano, e solo il secondo decide ciò che vede il partner. Se la subnet NAT non ha alcuna rotta verso il percorso VPN, il pacchetto non arriva mai, e questo è un guasto diverso da un indirizzo di origine errato.

Verifica quella seconda rotta prima ancora di parlare di indirizzi. Una rotta mancante e un’origine dichiarata male sembrano identiche a un partner che semplicemente non vede traffico.

Quando una seconda traduzione cambia la risposta

AWS offre anche una mappatura NAT esplicita e corrispondente uno a uno su un allegato di gateway di transito. Quella mappatura può tradurre di nuovo l’origine prima che il servizio remoto la veda, e non è il comportamento predefinito che si limita a instradare. Poiché va configurata di proposito, trattala come un’eccezione di progetto e non come qualcosa che erediti per caso. Se nessuno del tuo team ricorda di averla attivata, supponi che manchi finché non avrai letto l’allegato.

Se il tuo progetto la usa, l’elenco degli indirizzi consentiti deve descrivere la mappatura finale e non l’indirizzo del gateway NAT. La stessa cautela vale per i percorsi di disponibilità: quando partecipano più indirizzi di gateway, l’insieme di origini atteso è l’unione, non un solo indirizzo rappresentativo. Annota a quale traduzione appartiene ogni indirizzo, perché un elenco senza provenienza è impossibile da verificare in seguito.

A un gateway NAT privato non si può dare servizio internet puntandolo a un gateway internet; AWS documenta che tale traffico viene scartato. Scegli il tipo dal percorso completo, non dalla parola VPN nel requisito.

Scrivi il contratto su cui il tuo partner può agire

Il contratto utilizzabile ha quattro parti: la direzione da cui partono i flussi, l’identità tradotta che il partner vedrà, la rotta di ritorno per quell’identità e l’ambito di protezione applicabile. I flussi del gateway NAT partono dal lato di origine supportato, quindi non è un servizio di inoltro di porte in ingresso per esporre un carico di lavoro privato. Dirlo ad alta voce presto evita una revisione di progetto in cui ciascun lato presumeva che iniziasse l’altro.

La traduzione compra sollievo dalla sovrapposizione degli indirizzi e una politica di origine prevedibile, e ti costa l’identità individuale del carico di lavoro nei log del partner. Se la verifica richiede l’attribuzione per carico di lavoro, mantieni quell’identità a livello applicativo invece di cercare di recuperarla da un indirizzo di origine tradotto.

Poi ricontrolla entrambe le tabelle di routing dopo qualsiasi modifica, perché un nuovo allegato o una subnet riassociata riscrive silenziosamente la risposta.