Anypoint VPN oder Transit Gateway NAT: Wo übersetzt wird
Anypoint VPN übersetzt Adressen nicht selbst. Entscheiden Sie sich zwischen einem PAT-Design auf der Firewall, einer AWS-Prefixmap oder einem anderen Attachment, bevor Sie NAT zusagen.
Eine NAT-Anforderung ist keine Anforderung, solange sie nicht die Adressen nennt, die sich ändern, und die Komponente, die sie ändern darf. Bei MuleSoft-Konnektivität hat diese Entscheidung drei Eingaben: ob das Backend eine Viele-zu-eins-Portübersetzung oder einen Eins-zu-eins-Präfixalias braucht, ob das AWS-Attachment, das Sie tatsächlich besitzen, diese Zuordnung leisten kann und ob der gesamte Pfad in einer vom Anbieter unterstützten Kombination bleibt. Machen Sie dabei Fehler, bauen Sie ein funktionierendes Labor, das im Review scheitert.
Der eine feste Punkt ist, dass Anypoint VPN selbst kein Übersetzungsgerät ist. Die CloudHub 2.0-Dokumentation führt NAT dort als nicht unterstützt, also ist jedes Design, das annimmt, der Tunnel verberge Ihre Worker-Adressen, bereits defekt.
Legen Sie fest, was die Übersetzung leisten muss
Müssen viele Anwendungs-Worker für das Backend als eine einzige Adresse erscheinen, ist die Anforderung eine gemeinsame Quellübersetzung, üblicherweise zustandsbehaftetes SNAT oder PAT auf einer Firewall, die Sie kontrollieren. Dieses Element muss auf einem freigegebenen Pfad sitzen, seinen Zustand über die Lebensdauer des Flows halten und den Rückverkehr für jede Verbindung sehen, die es umgeschrieben hat. Zustandsverlust mitten in der Sitzung verschlechtert die Verbindung nicht; er beendet sie. Ein Firewall-Paar, das Übersetzungszustand nicht teilt, verwirft jede Sitzung, die nach dem Failover auf dem Standby-Mitglied landet. Dimensionieren Sie dieses Element nach gleichzeitigen Flows, nicht nach Durchsatz.
Überlappen sich dagegen zwei Netze und braucht jeder Host einen eigenen Alias, ist die Anforderung ein Eins-zu-eins-Adressplan mit eindeutigen zugeordneten Präfixen, passenden Routen und Namensauflösung, die zur Zuordnung passt. Alle Worker hinter einer Adresse zu verbergen ist keine billigere Variante davon, und das eine gegen das andere in einem Design-Review zu tauschen, ist der Weg, auf dem Projekte ein Quartal verlieren.
Halten Sie die Entscheidung in konkreten Begriffen fest, bevor Sie ein Produkt wählen: ursprüngliche Quelle, ursprüngliches Ziel, übersetzter Wert, Richtung der Initiierung, Eigentümer des Übersetzers und erwartete Antwortroute. Ergänzen Sie, welche Identität die Backend-Logs behalten, denn ein Design, das alle Quellen verbirgt, zerstört auch die Prüfung pro Client.
Prüfen Sie, ob AWS die Zuordnung für Sie erledigen kann
AWS dokumentiert inzwischen verwaltetes Eins-zu-eins-NAT auf Transit-Gateway- und Cloud-WAN-Attachments, angekündigt Ende Oktober 2026, die alte pauschale Behauptung, ein Transit Gateway könne niemals übersetzen, ist also überholt. Die Transit Gateway NAT-Dokumentation beschreibt eine zustandslose IPv4-Präfixzuordnung: ursprüngliche und übersetzte Präfixe behalten dieselbe Länge, und Host-Bits sowie Transportports überstehen die Übersetzung. Lesen Sie die Ingress- und Egress-Richtungen als getrennte Designentscheidungen, denn sie werden getrennt konfiguriert, und eine kann fertig sein, während die andere es nicht ist. Nichts in dieser Beschreibung setzt Zustand pro Flow voraus, erwarten Sie also nicht, dass die Zuordnung Verbindungen für Sie verfolgt.
Das heißt, 10.80.0.0/16 auf 172.28.0.0/16 abgebildet macht aus 10.80.10.23 die Adresse 172.28.10.23. Es staucht das /16 nicht auf eine Adresse und ersetzt keine PAT-Anforderung. Es deckt außerdem ausgewählte Attachment-Typen ab, darunter VPC und Site-to-Site VPN, aber keine Client-VPN-Attachments, und die Konfiguration liegt beim Eigentümer des Transit Gateway, nicht auf der Anypoint-Seite.
Behandeln Sie die Funktion als einen weiteren möglichen Kontrollpunkt, nicht als Beweis dafür, dass Ihre Bereitstellung sie nutzen kann. CloudHub 2.0 dokumentiert Private-Space-Attachments an ein Transit Gateway im eigenen AWS-Konto des Kunden, mit regionalen Bedingungen und Berechtigungsbedingungen, bestätigen Sie also den realen Attachment-Typ, seinen Eigentümer und die Support-Position des Anbieters, bevor Sie um die neue Option herum entwerfen.
Halten Sie den Pfad innerhalb einer unterstützten Grenze
Nutzen Sie für einen Firewall-Übersetzer das unterstützte VPN-, Übersetzungs- und Routingmodell dieses Produkts, statt eine generische NAT-Regel in einen funktionierenden Tunnel zu kleben. Die Antwort des Backends muss durch dasselbe Übersetzungselement zurückkommen, und ein gesunder ausgehender Tunnel sagt nichts über diesen Rückweg aus.
Erfassen Sie für die Transit-Gateway-Route das Private-Space-Attachment, die relevanten Routentabellen, das On-Premises-Attachment und die Teile, die der Kunde tatsächlich konfigurieren kann. Das ist eine andere Konnektivitätsarchitektur, kein NAT-Häkchen an einer bestehenden Anypoint-VPN-Verbindung, und die Supportgrenze verschiebt sich mit.
Vergleichen Sie die drei Optionen in einer Tabelle
Die meisten Teams müssen nur zwei Fragen beantworten: viele zu eins oder eins zu eins, und wem gehört das Attachment. Die Tabelle unten macht aus diesen Antworten eine Startoption.
| 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 |
Lesen Sie die dritte Spalte als Reviewfrage, nicht als Nachgedanken. Eine Prefixmap, die auf dem Papier erlaubt, aber auf einem Attachment konfiguriert ist, das Sie nicht besitzen, bleibt ein blockiertes Projekt, und eine PAT-Regel, die Verkehr durchlässt, aber die Protokollierung pro Client bricht, scheitert an der Prüfung, die folgt.
Validieren Sie die Zuordnung, bevor Sie sie zusagen
Schicken Sie eine frische Anwendungsoperation durch den Pfad und bestätigen Sie die Antwort, nicht nur die Anfrage. Fragen Sie den Backend-Eigentümer, welche Quelladresse seine Logs aufgezeichnet haben, prüfen Sie, dass die Behandlung der Adressfamilie in beiden Richtungen zum Plan passt, und verifizieren Sie, dass ein Pfad, der abgelehnt werden soll, es weiterhin wird. Eine alte Verbindung beweist nichts über die Zuordnung, die Sie gerade geändert haben.
Halten Sie die Backend-Authentifizierung unabhängig davon, welche übersetzte Adresse ihre Allowlist erfüllt, denn die Zuordnung ist Netzwerkverkabelung und keine Zugriffskontrollentscheidung. In dem Moment, in dem ein Passwort-Reset von einem NAT-Präfix abhängt, wird jede künftige Bereichsänderung zu einem Ausfall.
Schreiben Sie vor der Freigabe die drei Antworten auf: Übersetzungstyp, Eigentümer des Übersetzers und das unterstützte Attachment oder der Produktpfad, der es trägt. Ist eine davon noch eine Vermutung, ist das Design nicht bereit für ein Änderungsfenster.