Anypoint VPN o NAT su Transit Gateway: dove avviene la traduzione
Anypoint VPN non traduce gli indirizzi da solo. Scegli tra un progetto PAT sul firewall, una mappa di prefissi AWS o un altro collegamento prima di promettere NAT.
Un requisito NAT non è un requisito finché non nomina gli indirizzi che cambiano e il componente autorizzato a cambiarli. Sulla connettività MuleSoft quella decisione ha tre ingressi: se il backend ha bisogno di una traduzione di porte molti-a-uno o di un alias di prefisso uno-a-uno, se il collegamento AWS che possedete davvero può eseguire quella mappatura, e se l'intero percorso resta dentro una combinazione supportata dal fornitore. Se sbagliate, costruite un laboratorio che funziona ma fallisce la revisione.
L'unico punto fermo è che Anypoint VPN non è di per sé un dispositivo di traduzione. La documentazione di CloudHub 2.0 elenca NAT come non supportato lì, quindi qualsiasi progetto che presuppone che il tunnel nasconderà gli indirizzi dei vostri worker è già rotto.
Decidete cosa deve fare la traduzione
Se molti worker applicativi devono apparire al backend come un solo indirizzo, il requisito è una traduzione di origine condivisa, di solito SNAT o PAT con stato su un firewall che controllate. Quell'elemento deve stare su un percorso approvato, conservare il proprio stato per tutta la vita del flusso e vedere il traffico di ritorno di ogni connessione che ha riscritto. Perdere lo stato a metà sessione non degrada la connessione; la termina. Una coppia di firewall che rifiuta di condividere lo stato di traduzione scarterà ogni sessione che dopo il failover finisce sul membro di standby. Dimensionate quell'elemento per flussi concorrenti, non per il throughput.
Se invece due reti si sovrappongono e ogni host ha bisogno di un alias distinto, il requisito è un piano di indirizzi uno-a-uno con prefissi mappati inequivocabili, rotte corrispondenti e risoluzione dei nomi coerente con la mappatura. Nascondere ogni worker dietro un solo indirizzo non è una versione più economica di questo, e scambiare l'uno con l'altro in una revisione di progetto è il modo in cui i progetti perdono un trimestre.
Registrate la decisione in termini concreti prima di scegliere un prodotto: origine originale, destinazione originale, valore tradotto, direzione di avvio, proprietario del traduttore e rotta di risposta attesa. Aggiungete quale identità conserveranno i log del backend, perché un progetto che nasconde tutte le origini distrugge anche l'audit per client.
Verificate se AWS può fare la mappatura per voi
AWS ora documenta NAT gestito uno-a-uno sui collegamenti Transit Gateway e Cloud WAN, annunciato a fine ottobre 2026, quindi la vecchia affermazione generale che un gateway di transito non possa mai tradurre è superata. La documentazione di Transit Gateway NAT descrive una mappatura di prefissi IPv4 senza stato: i prefissi originali e tradotti mantengono la stessa lunghezza, e i bit di host e le porte di trasporto sopravvivono alla traduzione. Leggete le direzioni di ingresso e uscita come decisioni di progetto separate, perché si configurano separatamente e una può essere pronta mentre l'altra no. Nulla in quella descrizione implica uno stato per flusso, quindi non aspettatevi che la mappatura segua le connessioni al posto vostro.
Ciò significa che 10.80.0.0/16 mappato su 172.28.0.0/16 trasforma 10.80.10.23 in 172.28.10.23. Non riduce il /16 a un solo indirizzo e non sostituisce un requisito PAT. Copre anche tipi di collegamento selezionati, tra cui VPC e Site-to-Site VPN, ma non i collegamenti Client VPN, e la configurazione resta presso il proprietario del gateway di transito, non sul lato Anypoint.
Trattate la funzione come un ulteriore possibile punto di controllo, non come la prova che la vostra distribuzione possa usarla. CloudHub 2.0 documenta collegamenti di spazio privato a un gateway di transito nell'account AWS del cliente stesso, con condizioni regionali e di diritto, quindi confermate il tipo reale di collegamento, il suo proprietario e la posizione di supporto del fornitore prima di progettare intorno alla nuova opzione.
Tenete il percorso dentro un confine supportato
Per un traduttore su firewall, usate il modello VPN, di traduzione e di routing supportato di quel prodotto invece di incollare una regola NAT generica in un tunnel funzionante. La risposta del backend deve tornare attraverso lo stesso elemento di traduzione, e un tunnel in uscita sano non dice nulla su quel percorso di ritorno.
Per la rotta del gateway di transito, inventariate il collegamento di spazio privato, le tabelle di routing pertinenti, il collegamento on-premises e le parti che il cliente può davvero configurare. È un'architettura di connettività diversa, non una casella NAT avvitata su una connessione Anypoint VPN esistente, e il confine di supporto si sposta con essa.
Confrontate le tre opzioni in un'unica tabella
La maggior parte dei team deve rispondere solo a due domande: molti-a-uno o uno-a-uno, e chi possiede il collegamento. La tabella qui sotto trasforma quelle risposte in un'opzione di partenza.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
Leggete la terza colonna come la domanda di revisione, non come un pensiero successivo. Una mappa di prefissi consentita sulla carta ma configurata su un collegamento che non possedete resta un progetto bloccato, e una regola PAT che lascia passare il traffico ma rompe la registrazione per client fallisce l'audit che segue.
Validate la mappatura prima di prometterla
Fate passare un'operazione applicativa nuova attraverso il percorso e confermate la risposta, non solo la richiesta. Chiedete al proprietario del backend quale indirizzo di origine hanno registrato i suoi log, verificate che la gestione della famiglia di indirizzi corrisponda al piano in entrambe le direzioni e controllate che un percorso che dovrebbe essere negato lo sia ancora. Una connessione vecchia non dimostra nulla sulla mappatura che avete appena cambiato.
Mantenete l'autenticazione del backend indipendente da quale indirizzo tradotto soddisfa la sua lista di autorizzazione, perché la mappatura è impiantistica di rete e non una decisione di controllo degli accessi. Nel momento in cui un ripristino della password dipende da un prefisso NAT, ogni futura modifica dell'intervallo diventa un'interruzione.
Prima dell'approvazione, scrivete le tre risposte: tipo di traduzione, proprietario del traduttore e collegamento o percorso di prodotto supportato che la porta. Se una di esse è ancora un'ipotesi, il progetto non è pronto per una finestra di cambiamento.