Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Note
Dieses Entwurfsmuster ist mit allen unterstützten nächsten Hop-Sicherheitslösungen kompatibel, die im Virtual WAN Hub bereitgestellt werden, einschließlich Azure Firewall, einer integrierten NVA oder einer Software as a Service(SaaS)-Lösung. Verwenden Sie außerdem die Option "Konfiguration der statischen Route 1 " beim Konfigurieren statischer Routen in der virtuellen Netzwerkverbindung, um eine ordnungsgemäße Verteilung der statischen Routen an den Hub und andere verbundene Speichen sicherzustellen. Konfigurationsoption 2 wird bei Verwendung der Routingabsicht nicht unterstützt .
Beschreibung des Szenarios
In diesem Entwurfsmuster wird erläutert, wie routing intent and routing policies mit static routes on a virtual network connection in Azure Virtual WAN kombiniert werden. Dieses Muster ist nützlich, wenn Sie möchten, dass eine Sicherheitslösung im virtuellen Hub zuerst den Datenverkehr überprüft, während ausgewählte Ziele weiterhin über eine virtuelle Netzwerkanwendung (Network Virtual Appliance, NVA) erreicht werden können, die in einem virtuellen Speichennetzwerk bereitgestellt wird.
Typische Beispiele sind das Senden von Datenverkehr an:
- Indirekte Spokes, die mit dem virtuellen NVA-Netzwerk gepeert werden, aber nicht direkt mit dem Virtual WAN Hub verbunden sind.
- VPN- oder SDWAN-Tunnel, die im virtuellen Spoke-Netzwerk am NVA enden.
- Internetgebundener Datenverkehr (erzwungener Tunnel)
Verkehrsmuster
Die folgende Verbindungsmatrix fasst die allgemeinen Datenverkehrsmuster in diesem Entwurf zusammen.
| Quelle/Ziel | Direkte Spoke | On-premises | Indirekte Spoke und mit NVA verbundene Standorte | Internet |
|---|---|---|---|---|
| Direkte Spoke | Über Routing-Intent Next Hop im Hub | Über Routing-Intent Next Hop im Hub | Über Routing Intent Next Hop im Hub, dann über die Spoke NVA | Über Routing-Intent Next Hop im Hub, dann über den Spoke NVA, wenn der Hub im erzwungenen Tunnelmodus konfiguriert ist |
| On-premises | Über Routing-Intent Next Hop im Hub | Über Routing-Intent Next Hop im Hub | Über Routing Intent Next Hop im Hub, dann über die Spoke NVA | Über Routing-Intent Next Hop im Hub, dann über den Spoke NVA, wenn der Hub im erzwungenen Tunnelmodus konfiguriert ist |
| Indirekte Spoke und mit NVA verbundene Standorte | Über den Spoke NVA, dann über den Routing Intent Next Hop im Hub | Über den Spoke NVA, dann über den Routing Intent Next Hop im Hub | Über den Spoke NVA | Über den Spoke NVA |
Netzwerkdiagramm
Diagramm, das Routingabsichten im virtuellen Hub in Kombination mit statischen Routen in einer virtuellen Speichennetzwerkverbindung zeigt, um indirekte Speichen, mit NVA verbundene Sites und das Internet zu erreichen.
Im obigen Diagramm gibt es drei Arten von Speichen:
- Direkt verbundene Speichen: direkt mit dem Virtual WAN Hub verbunden.
- NVA-Spoke: direkt mit dem Virtual WAN Hub verbunden und mit einem NVA bereitgestellt.
- Indirekte Speiche: nicht direkt mit dem Virtual WAN Hub verbunden. Der indirekte Spoke wird mit dem NVA-Spoke gepeered. Der Datenverkehr zu und von diesen Spokes muss den NVA durchlaufen, bevor er eine andere Verbindung zum Virtual WAN Hub erreicht.
Configuration
Routingabsichts- und Routingrichtlinien
Der virtuelle Hub muss den Routing-Intent verwenden. Verwenden Sie eine Private Traffic Routingrichtlinie, wobei der nächste Hop auf die im virtuellen Hub bereitgestellte Sicherheitslösung festgelegt ist, z. B. Azure Firewall, eine unterstützte integrierte NVA oder eine SaaS-Sicherheitslösung (Software-as-a-Service).
Statische Routen in der virtuellen NVA-Netzwerkverbindung
Note
Für Routing-Intent-Hubs ist das einzige unterstützte Integrationsmuster für statische Routen die Konfigurationsoption 1 für statische Routen. Konfigurieren Sie statische Routen in der virtuellen Netzwerkverbindung und legen Sie Propagate static route auf "true" fest.
| Präfixtyp | Beispielpräfixe | Argumentation |
|---|---|---|
| Präfixe für indirekte Speichen | 10.20.0.0/16 | Ermöglicht die Weiterleitung des im Hub inspizierten Datenverkehrs an Präfixe, die hinter der in der Spoke bereitgestellten NVA erreichbar sind. |
| SDWAN-Präfixe | 192.168.0.0/24 | Ermöglicht die Weiterleitung des im Hub geprüften Datenverkehrs an SDWAN-verbundene Standorte oder Präfixe, die über Tunnel erreichbar sind, die an dem in der Spoke bereitgestellten NVA terminiert sind. |
Zusätzliche Überlegungen
- Bei Bereitstellungen, bei denen statische Routen auf einer virtuellen Netzwerkverbindung mit Statische Route weiterleiten aktiviert sind, wird das Verhalten Bypass Next Hop IP ignoriert, wenn Routing-Intent angewendet wird. Weitere Informationen finden Sie unter Bypass von Next Hop IP für Workloads innerhalb dieses VNet.
- Wenn mehrere statische Routen konfiguriert sind, bei denen sich die Ziel-CIDRs nicht in IANA RFC1918 befinden, müssen alle statischen Routen mit nicht RFC1918 Zielen die gleiche ip-Adresse des nächsten Hops verwenden.
- Routing-Intent ist der einzige unterstützte Mechanismus im Virtual WAN, um den Inter-Hub-Datenverkehr durch im virtuellen Hub bereitgestellte Sicherheitslösungen zu überprüfen.
- Wenn Sie einen Entwurf benötigen, bei dem eine NVA, die in einem Speichennetz bereitgestellt ist, nur für den Internetzugang verwendet wird, während die Sicherheitslösung des virtuellen Hubs den privaten Datenverkehr überwacht, lesen Sie Kombination von Azure Firewall und in Speichen bereitgestellten NVAs. In diesem Szenario wird der Internet-Datenverkehr nur von der in der Spoke bereitgestellten NVA inspiziert.
- Wenn Sie eine designbedingte Anforderung haben, bei der ein in einer Spoke bereitgestellter NVA verwendet wird, um den Datenverkehr ohne Routing-Intent an indirekte Spokes oder das Internet zu routen, siehe Datenverkehr an indirekte Spokes routen.