Azure VPN NAT behebt überlappende VNet-Adressen nicht
Zwei VNets mit demselben privaten Bereich verbinden sich nicht, nur weil NAT vorhanden ist. Prüfen Sie zuerst den Verbindungstyp und nummerieren Sie dann neu oder besitzen Sie einen Übersetzungsalias.
Beide VNets verwenden 10.40.1.0/24, die Tunnel kommen hoch, und nichts funktioniert. Ein zweites VPN-Gateway ändert das nicht, eine niedrigere Routenmetrik ebenso wenig, denn das Problem ist nicht die Pfadwahl. Zwei Workloads, die auf dieselbe private Adresse antworten, hinterlassen jedes Paket mit einem mehrdeutigen Ziel und einem nicht überprüfbaren Rückweg. Bevor Sie irgendeine Übersetzung planen, finden Sie heraus, welchen Verbindungstyp Sie tatsächlich erstellt haben, denn diese eine Wahl entscheidet, ob die NAT-Funktion von Azure überhaupt verfügbar ist.
Was das Symptom Ihnen wirklich sagt
Wenn ein Host in VNet A an 10.40.1.10 sendet, kann die Routingtabelle ihn nur irgendwohin zeigen. Enthält auch VNet B 10.40.1.10, ist diese Adresse kein Ziel, das der Pfad unterscheiden kann; sie ist eine Adresse mit zwei Eigentümern.
Das zweite Gateway, das man üblicherweise einsetzt, hilft nicht. Es liefert einen weiteren Tunnel, nicht eine weitere Adresse, und der doppelte Bereich reist unverändert im Tunnel mit. Es verdoppelt außerdem die Konfiguration, die Sie konsistent halten müssen. Was es nicht kann, ist eine Adresse zwei Hosts bedeuten zu lassen.
Auch das Ändern der öffentlichen Adressen der VPN-Peers hilft nicht. Diese Adressen kennzeichnen die Tunnelendpunkte, während die Kollision im privaten Bereich liegt, der darin transportiert wird.
Der Verbindungstyp entscheidet, ob NAT verfügbar ist
Azure VPN Gateway besitzt durchaus eine NAT-Funktion, und sie ist für routenbasierte IPsec-Standort-zu-Standort-Verbindungen auf bestimmten Gateway-SKUs dokumentiert. Dieselbe Dokumentation schließt VNet-zu-VNet- und Point-to-Site-Verbindungen aus, sodass die Funktion kein Kontrollkästchen ist, das bei jeder Gateway-Beziehung erscheint.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Auch natives VNet-zu-VNet setzt voraus, dass sich VNet- und lokale Netzwerkbereiche von vornherein nicht überlappen, was zur Ausnahme passt. VNet-Peering ist aus demselben Grund keine Lösung für Überlappungen.
Es gibt eine unterstützte Alternative, die oft mit dem nativen Typ verwechselt wird: das andere VNet als lokales Netzwerk modellieren und als Standort-zu-Standort-Verbindung anbinden. Das ist eine andere Ressource und ein anderes Design, behandeln Sie eine umbenannte Verbindung also als zu validierende Änderung und nicht als bloße Umbenennung.
Neu nummerieren oder mit etwas übersetzen, das den Alias besitzt
Wenn beide VNets Ihnen gehören, vergleichen Sie eine geplante Umnummerierung mit den laufenden Kosten der Übersetzung. Eine Umnummerierung berührt Anwendungskonfiguration, DNS-Einträge, Sicherheitsregeln und jede bestehende Verbindung, hinterlässt aber ein Netzwerk, das sich danach normal liest. Machen Sie es ein Subnetz nach dem anderen, mit der DNS-Änderung zuletzt. Ein halb umnummerierter Bereich ist schlechter als beide Optionen, weil dann beide Präfixe für den nächsten Leser der Tabelle maßgeblich aussehen.
Wo eine Umnummerierung nicht praktikabel ist, verwenden Sie ein übersetztes Design mit einem echten Eigentümer für den Alias. Aufrufer in VNet A erreichen 10.40.1.10 in VNet B vielleicht als 10.140.1.10, aber dieser Alias braucht ein Gerät, das übersetzt, eine Route dorthin und passendes Verhalten für die Antwort. Eine nur im DNS ergänzte Adresse ist keine Übersetzung.
Halten Sie beide Bereiche in beiden Richtungen fest: was der Aufrufer wählt, was das Ziel als Quelle sieht und welche Seite initiieren darf. Azures eigene NAT-Regeln enthalten die Rückübersetzung für ihre SNAT-Zuordnungen, Sie schreiben also keine passende DNAT-Regel von Hand, doch dieser Komfort endet bei den Verbindungstypen, die die Funktion unterstützt.
Was nicht funktionieren wird
Eine benutzerdefinierte Route oder eine Routenmetrik kann eine fehlende Adressunterscheidung nicht erzeugen. Beide wirken auf ein Ziel, das weiterhin mehrdeutig ist, und das Paket kommt an dem nächsten Hop an, den die Tabelle bevorzugt.
Den doppelten Bereich als spezifischeres Präfix in eine Routentabelle aufzunehmen, verschiebt die Mehrdeutigkeit nur um einen Schritt. Es bricht außerdem häufig die Gegenrichtung, in der die Antwort nun zwei plausible Quellen hat.
Akzeptieren Sie das Design mit Verkehr in beiden Richtungen
Beweisen Sie das Design mit einer frisch erlaubten Operation von jeder Seite, nicht mit dem Tunnelstatus. Ein verbundener IPsec-Tunnel besagt, dass sich die Peers über Kryptografie einig sind; er sagt nichts darüber, ob die Ziele unterscheidbar geworden sind.
Führen Sie dann die verbotenen Pfade aus: eine Adresse, die unerreichbar bleiben soll, und einen Dienst, den die Richtlinie blockieren soll. Gelingen beide weiterhin, ist die Übersetzung breiter als vom Design beabsichtigt.
Schließen Sie mit den Fakten, die das Setup später erklären: der ursprüngliche Bereich, der präsentierte Bereich, das Gerät, das übersetzt, und die Richtung, in der jede Seite initiieren darf. Fehlt eines davon, erbt der nächste Engineer ein Netzwerk, in dem zwei Hosts einen Namen teilen und niemand sich erinnert, warum einer von ihnen antwortet.