Wir verfügen über Site-to-Site-VPN-Verbindungen mit Azure VPN Gateway und verschiedenen lokalen Netzwerkgeräten an den jeweiligen Client-Standorten. Wir versuchen, eine neue Verbindung einzurichten, haben aber einen IP-Bereichskonflikt mit einem Netzwerk am anderen Ende. Das folgende Diagramm, obwohl es sich um eine freie Interpretation auf der Client-Seite handelt, da ich nicht alle Details auf ihrer Seite habe, erklärt es wahrscheinlich am besten, aber hier sind die Fakten:
IP-Bereichskonflikt an beiden Enden des Azure VPN S2S-Tunnels
- Netzwerk A (192.168.1.0/24) befindet sich hinter unserem Azure VPN Gateway und liegt in unserer Verantwortung.
- Netzwerk B (192.168.2.0/24) ist ein Zielnetzwerk für Pakete, die aus Netzwerk A stammen, liegt in der Verantwortung unseres Kunden und wird in einer privaten Cloud gehostet.
- Netzwerk C (192.168.1.0/24) ist ein weiteres Netzwerk innerhalb der privaten Cloud, das für unseren Datenverkehr nicht relevant ist, außer dass es einen IP-Bereichskonflikt innerhalb der privaten Cloud des Clients darstellt.
Der Azure-Support hat angegeben, dass die einzige Lösung darin besteht, einem der in Konflikt stehenden Netzwerke eine neue IP-Adresse zuzuweisen, da in Konflikt stehende Bereiche derzeit nicht unterstützt werden. Demnach ist NAT an beiden Enden des Tunnels keine praktikable Lösung. Das Hinzufügen eines neuen Subnetzes hinter dem Azure VPN Gateway und das Weiterleiten/NAT des Datenverkehrs an Netzwerk A wird ebenfalls nicht unterstützt.
Aufgrund der Folgen einer Neu-IP-Vergabe für Netzwerk A möchten wir es nicht neu zuweisen. Wenig überraschend möchte der Client auch seinem Netzwerk, Netzwerk C, keine neue IP-Adresse zuweisen. Vielleicht leugne ich es einfach, aber ist jemand anderes schon einmal auf dieses Szenario gestoßen und hat es erfolgreich umgangen oder gelöst?ohneRe-IP? Wenn ja, wären wir für jede Dokumentation oder Konfiguration, die die Lösung unterstützt und auf die verwiesen werden könnte, sehr dankbar.
Vielen Dank im Voraus für jede Hilfe.
Antwort1
- spezifisches Routing
Sie haben geschrieben, dass Sie an einem Routing zwischen den Netzwerken A und B interessiert sind, das nicht in Konflikt steht... Falls SonicWall zwischen diesen „internen Client-Netzwerken“ routet und es möglich ist, bestimmte IPs im Netzwerk C nicht zu verwenden, können Sie das Routing durch das Netzwerk nicht für das gesamte 192.168.1.0/24, sondern für bestimmte IPs wie /32 durchführen. Bei der Routing-Entscheidung „gewinnt die bessere Übereinstimmung“. In diesem Fall würde der spezifische Datenverkehr korrekt von B nach A geroutet, während der Rest an Netzwerk C weitergeleitet würde...
Abhängig vom VPN-Typ kann die Konfiguration auf SonicWall einfacher oder schwieriger sein (falls möglich), aber technisch gesehen könnte dies ohne NAT möglich sein. Im schlimmsten Fall können Sie ein zusätzliches Gerät haben, das VPN zu Azure beendet, und auf SonicWall gibt es eine statische Routing-Regel, um diese IPs an diesen zusätzlichen Knoten weiterzuleiten.
Auf diese Weise wäre die Azure-Seite von C aus nie erreichbar, aber basierend auf dem, was Sie geschrieben haben, wäre das nicht das Problem.
- NAT
Wie Sie geschrieben haben, bietet Azure VPN GW diese Funktion nicht. Die einzige Möglichkeit könnte darin bestehen, dies auf der anderen Seite des Tunnels zu tun – SonicWall Appliance. Von der B-, C-Seite aus können Sie die „Remote“-Site wie jeden nicht verwendeten IP-Bereich ansprechen (z. B. 172.16.0.0/24) und sobald sie SonicWall erreicht, könnte sie zum VPN weitergeleitet werden, während sie vor dem Verlassen des Knotens dNATed/auf 192.168.1.0/24 abgebildet würde, wobei z. B. der letzte Oktettwert beibehalten oder eine 1:1-Abbildung mit allen benötigten IPs erstellt würde. Auf diese Weise wäre für den VPN-Verkehr die Remote-IP auf der Azure-Seite die „richtige“ 192.168.0.0/24 und die Azure-Seite hätte keine Ahnung vom NAT.
Falls Sie dies aus irgendeinem Grund auf SonicWall nicht tun können, besteht die Möglichkeit, ein anderes Gerät zu platzieren, das dazu in der Lage ist bzw. über eine eigene Verwaltung verfügt, das den VPN-Tunnel beendet und vom lokalen Netzwerk aus das Ziel für den 172.16.0.0/24-Datenverkehr ist (Route auf dem lokalen Router).
Problematisch wären nur die Fälle, in denen Sie DNS-Antworten mit 192.168.1.0/24-Adressen und Zertifikaten mit IP zur Identifizierung verwenden. Im Fall von DNS-Sachen benötigen Sie eine lokale DNS-Zone mit „aktualisierten“ Werten, damit die Clients „richtige“ Endpunkte kontaktieren.