So leiten Sie SaaS-Verkehr zum richtigen Kunden-VPN
Überlappende Kundensubnetze brechen gemeinsames Routing. Wählen Sie ein Isolationsmodell, binden Sie jeden Job an einen verifizierten Mandanten und testen Sie mandantenübergreifende Pfade vor dem Start.
Eine SaaS-Plattform verbindet sich mit einem Dutzend Kundennetzen, und zwei dieser Kunden verwenden beide 10.20.0.10 für ihre primäre Datenbank. Ein Worker, der diese Adresse in einem Job erhält, kann nicht erkennen, welche Datenbank der Job meint, und eine gemeinsame Routing-Tabelle schickt ihn bereitwillig zu dem Tunnel, auf den das Präfix zeigt. Die Lösung sind nicht mehr Tunnel; sie besteht darin, zu entscheiden, wo die Mandantenidentität in den Pfad eintritt und welches Isolationsmodell der Adressplan erfordert. Drei Bedingungen entscheiden die Wahl: ob sich Kundenpräfixe überlappen, wie weit sich ein Fehler ausbreiten kann und wer den Connector betreibt.
Zwei Kundendatenbanken, eine Zieladresse
Eine IP-Adresse ist ein Ort, keine Identität. Die Anfrage muss einen vom Server verifizierten Mandanten tragen, und dieser Mandant muss den Netzwerkkontext auswählen, bevor das Ziel aufgelöst wird.
Wenn das nicht geschieht, ist der Fehler still. Die Verbindung gelingt, die Abfrage läuft, und die Antwort kommt aus der Datenbank des falschen Kunden, weil die Routing-Tabelle einen Eintrag für 10.20.0.10 hatte. DNS verschlimmert es: Ein gecachter Name, der im Kontext von Mandant A aufgelöst wurde, kann von einem Job wiederverwendet werden, der für Mandant B läuft. Nichts im Paket unterscheidet die beiden, daher repariert keine Wiederholungslogik das.
Entscheiden Sie zuerst über das Isolationsmodell
Schreiben Sie die drei Bedingungen auf, bevor Sie Produkte vergleichen. Überlappung entscheidet, ob ein Adressraum überhaupt geteilt werden kann; der Blast-Radius entscheidet, ob ein Routing-Fehler ein Support-Ticket oder ein Sicherheitsvorfall ist; die betriebliche Zuständigkeit entscheidet, ob Sie eine Connector-Flotte pro Mandant betreiben können.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
Wenn die Präfixe verschieden sind und die Richtlinie einen kontrollierten Hub erlaubt, ist ein Transit Gateway mit Routing-Tabellen pro Mandant machbar. Die Attachment-Assoziation wählt die Routing-Tabelle, die für Verkehr verwendet wird, der von diesem Attachment eintritt, und die Propagation wählt, welche Routen in einer Tabelle erscheinen. Ein Mandanten-Attachment, das nur seiner eigenen Tabelle zugeordnet ist und nur seine eigenen Präfixe propagiert, erreicht den Hub und nichts anderes. Das ist eine Routing-Entscheidung, und sie bleibt nur korrekt, solange niemand eine Standardroute in die gemeinsame Tabelle einfügt.
Wenn sich Präfixe überlappen, kann Routing allein sie nicht trennen. Sie brauchen entweder einen eigenen Netzwerkkontext pro Mandant oder einen Übersetzungsplan, der dem Raum jedes Kunden eine eindeutige Bedeutung gibt.
Was Transit-Gateway-Isolation tatsächlich bedeutet
Assoziation und Propagation sind die beiden entscheidenden Stellschrauben, und sie sind leicht zu verwechseln. Die Assoziation beantwortet, in welcher Tabelle ein Paket von diesem Attachment nachgeschlagen wird; die Propagation beantwortet, welche Tabellen die Routen dieses Attachments lernen. Isolation entsteht dadurch, dass beides mandantenspezifisch wird, nicht durch mehr Attachments.
Eine standardmäßige All-to-all-Konfiguration ist bequem und keine Isolation. Getrennte Routing-Tabellen beschränken die Konnektivität, geben aber einer unveränderten Zieladresse nicht zwei Bedeutungen innerhalb desselben Routing-Kontexts. Wenn die Anwendung 10.20.0.10 auflöst, bevor sie den Mandanten kennt, hat die Routing-Schicht die Information bereits verloren, die sie bräuchte.
AWS hat am 23. Oktober 2026 1:1-NAT auf Attachment-Ebene für Transit Gateway und Cloud WAN hinzugefügt, was die Überlappungsantwort für unterstützte Attachments ändert. Die Transit Gateway NAT-Dokumentation beschreibt statische, zustandslose IPv4-Zuordnungen mit gleichem Präfix und erhaltenen Host-Bits. Prüfen Sie unterstützte Attachment-Typen und regionale Einschränkungen, bevor Sie darauf aufbauen.
Binden Sie den Job an einen verifizierten Mandanten
Jeder Job sollte eine vom Server verifizierte Mandantenidentität tragen, und diese Identität sollte einen vom Administrator verwalteten Verbindungsdatensatz auswählen. Der Datensatz nennt den genehmigten Netzwerkkontext, die Dienstadresse, die Referenz auf die Anmeldedaten und die dort erlaubten Operationen. Eine nicht vertrauenswürdige Anfrage darf niemals ihre eigene VPN-Kennung, ihr Gateway oder ihr privates Ziel liefern, denn eine gültige Anmeldung ist keine Erlaubnis, den Adressraum jedes verbundenen Kunden zu prüfen.
In einem Design mit isolierten Connectors geht die Arbeit von Mandant A an einen A-spezifischen Connector, der in der VPC von A läuft und nur die genehmigten Ressourcen von A erreichen kann. Getrennte Container auf einem Host erzeugen diese Trennung nicht von selbst; die Netzwerk-Namespaces, Routen und die Egress-Richtlinie müssen sie umsetzen. Der Connector benötigt außerdem mandantenbezogene Anmeldedaten und Warteschlangen, denn eine private Route begrenzt weder ein gemeinsames Geheimnis noch ein gemeinsames Arbeitselement. Gepoolte Anwendungs-Worker sind in Ordnung, solange Netzwerkkontext und Anmeldedaten pro Mandant und nicht pro Host gewählt werden.
Health-Checks sollten den Mandanten und die Stufe nennen: Tunnel aufgebaut, Route vorhanden und eine echte Dienstanfrage erfolgreich sind drei verschiedene Signale. Eine aggregierte Zahl laufender Tunnel verbirgt den einen Kunden, dessen Connector defekt ist.
Testen Sie die Pfade, die scheitern müssen
Führen Sie vor dem Start drei Tests aus. Eine erlaubte A-Operation muss gelingen, eine erlaubte B-Operation muss gelingen, und ein A-Job, der absichtlich auf Bs Connector oder übersetzten Alias gerichtet ist, muss fail-closed scheitern. Unterbrechen Sie dann einen Tunnel und bestätigen Sie, dass der Job nur für diesen Mandanten scheitert, ohne auf das gleichnamige Subnetz eines anderen Kunden zurückzufallen. Auch die Wiederherstellung sollte getestet werden, denn eine veraltete Route oder gecachte Anmeldedaten können den Ausfall überleben.
Die Architektur kann aus gepoolten Workern mit isolierten Connectors oder vollständig getrennten Mandantenressourcen bestehen. Die Invariante ist dieselbe: Verifizierter Mandantenkontext wählt die Route und die Anmeldedaten, und keine Routenänderung gewährt jemals Anwendungsberechtigung über Mandanten hinweg.