Anypoint VPN nebo NAT v Transit Gateway: kde se překlad odehrává
Anypoint VPN sám adresy nepřekládá. Rozhodněte se mezi PAT na firewallu, mapou prefixů v AWS nebo jiným připojením, než NAT slíbíte.
Požadavek na NAT není požadavkem, dokud nepojmenuje adresy, které se mění, a komponentu, které je dovoleno je měnit. U konektivity MuleSoft má toto rozhodnutí tři vstupy: zda backend potřebuje překlad portů many-to-one, nebo alias prefixu one-to-one, zda připojení AWS, které skutečně vlastníte, umí toto mapování provést, a zda celá cesta zůstává v kombinaci, kterou dodavatel podporuje. Spletete-li to, postavíte funkční laboratoř, která neprojde revizí.
Jediný pevný bod je, že Anypoint VPN sám není překladové zařízení. Dokumentace CloudHub 2.0 uvádí NAT jako nepodporovaný, takže každý návrh, který předpokládá, že tunel skryje adresy vašich workerů, je už rozbitý.
Určete, co má překlad dělat
Pokud se mnoho aplikačních workerů musí backendu jevit jako jediná adresa, požadavkem je sdílený překlad zdroje, obvykle stavový SNAT nebo PAT na firewallu, který ovládáte. Tento prvek musí stát na schválené cestě, držet svůj stav po celou dobu životnosti toku a vidět návratový provoz pro každé spojení, které přepsal. Ztráta stavu uprostřed relace spojení nezhorší; ukončí ho. Pár firewallů, který odmítá sdílet překladový stav, zahodí každou relaci, která po failoveru skončí na záložním členu. Dimenziujte tento prvek na souběžné toky, ne na propustnost.
Pokud se naopak dvě sítě překrývají a každý hostitel potřebuje vlastní alias, požadavkem je plán adres one-to-one s jednoznačnými mapovanými prefixy, odpovídajícími trasami a překladem jmen, který s mapováním souhlasí. Skrýt každý worker za jednu adresu není levnější verze tohoto a záměna jednoho za druhé při revizi návrhu je způsob, jak projekty ztratí čtvrtletí.
Zapište rozhodnutí konkrétními termíny, než vyberete produkt: původní zdroj, původní cíl, přeložená hodnota, směr inicializace, vlastník překladače a očekávaná návratová trasa. Doplňte, jakou identitu si backendové logy ponechají, protože návrh, který skryje všechny zdroje, ničí i audit po klientech.
Ověřte, zda mapování může udělat AWS za vás
AWS nyní dokumentuje spravovaný NAT one-to-one na připojeních Transit Gateway a Cloud WAN, oznámený na konci října 2026, takže staré paušální tvrzení, že transit gateway nikdy nemůže překládat, je zastaralé. Dokumentace Transit Gateway NAT popisuje bezstavové mapování prefixů IPv4: původní a přeložené prefixy si zachovávají stejnou délku a hostitelské bity a transportní porty překlad přežijí. Čtěte směry ingress a egress jako samostatná návrhová rozhodnutí, protože se konfigurují odděleně a jeden může být hotový, zatímco druhý ne. Nic v tomto popisu neimplikuje stav na tok, takže nečekejte, že mapování bude za vás sledovat spojení.
To znamená, že 10.80.0.0/16 mapovaný na 172.28.0.0/16 mění 10.80.10.23 na 172.28.10.23. Nesbalí /16 do jedné adresy a nenahrazuje požadavek na PAT. Pokrývá také vybrané typy připojení, mimo jiné VPC a Site-to-Site VPN, ale ne připojení Client VPN, a konfigurace žije u vlastníka transit gateway, ne na straně Anypoint.
Berte funkci jako další možný řídicí bod, ne jako důkaz, že ji vaše nasazení může použít. CloudHub 2.0 dokumentuje připojení privátního prostoru k transit gateway ve vlastním účtu AWS zákazníka, s regionálními podmínkami a podmínkami nároku, takže před návrhem kolem nové možnosti potvrďte skutečný typ připojení, jeho vlastníka a postoj dodavatele k podpoře.
Držte cestu uvnitř podporované hranice
U překladače na firewallu použijte podporovaný model VPN, překladu a směrování daného produktu, místo abyste vložili obecné NAT pravidlo do funkčního tunelu. Odpověď backendu se musí vrátit stejným překladovým prvkem a zdravý odchozí tunel o této zpáteční cestě nic neříká.
U trasy přes transit gateway zinventarizujte připojení privátního prostoru, příslušné směrovací tabulky, lokální připojení a části, které zákazník skutečně může konfigurovat. Je to jiná architektura konektivity, ne zaškrtávací políčko NAT přišroubované k existujícímu připojení Anypoint VPN, a hranice podpory se s ní posouvá.
Porovnejte tři možnosti v jedné tabulce
Většina týmů potřebuje odpovědět jen na dvě otázky: many-to-one, nebo one-to-one, a kdo vlastní připojení. Tabulka níže mění tyto odpovědi na výchozí možnost.
| 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 |
Čtěte třetí sloupec jako otázku revize, ne jako dodatečný nápad. Mapa prefixů povolená na papíře, ale nakonfigurovaná na připojení, které nevlastníte, je stále zablokovaný projekt, a pravidlo PAT, které propustí provoz, ale rozbije logování po klientech, neprojde auditem, který následuje.
Ověřte mapování, než ho slíbíte
Pošlete cestou jednu novou operaci aplikace a potvrďte odpověď, ne jen požadavek. Zeptejte se vlastníka backendu, kterou zdrojovou adresu jejich logy zaznamenaly, zkontrolujte, že zpracování adresní rodiny odpovídá plánu v obou směrech, a ověřte, že jedna cesta, která má být zamítnuta, jí stále je. Zastaralé spojení nic nedokazuje o mapování, které jste právě změnili.
Držte autentizaci backendu nezávislou na tom, která přeložená adresa splňuje jeho allowlist, protože mapování je síťařina, ne rozhodnutí o řízení přístupu. Ve chvíli, kdy reset hesla závisí na NAT prefixu, se každá budoucí změna rozsahu stane výpadkem.
Před schválením zapište tři odpovědi: typ překladu, vlastníka překladače a podporované připojení nebo produktovou cestu, která ho nese. Pokud je některá z nich stále odhad, návrh není připraven na změnové okno.