Konfigurieren der Integration virtueller Netzwerke mit erforderlichem Gateway

Die von einem Gateway abhängige Integration virtueller Netzwerke unterstützt das Herstellen einer Verbindung mit einem virtuellen Netzwerk in einer anderen Region oder mit einem klassischen virtuellen Netzwerk. Die Integration virtueller Netzwerke mit erforderlichem Gateway funktioniert nur für Windows-Pläne. Für die Integration in virtuelle Netzwerke wird empfohlen, regionale virtuelle Netzwerke zu verwenden.

Integration des virtuellen Netzwerks mit erforderlichem Gateway:

• Eine App kann nur jeweils mit einem virtuellen Netzwerk eine Verbindung herstellen.
• Bis zu fünf virtuelle Netzwerke können in einen App Service-Plan integriert werden.
• Ermöglicht die Verwendung desselben virtuellen Netzwerks durch mehrere Apps in einem App Service-Plan, ohne dass sich dies auf die für einen App Service-Plan zulässige Gesamtanzahl von VNets auswirkt. Wenn Sie über sechs Apps verfügen, die dasselbe virtuelle Netzwerk im selben App Service-Plan nutzen, zählt dies als ein verwendetes virtuelles Netzwerk.
• Die SLA für das Gateway kann sich auf die allgemeine SLA auswirken.
• Ermöglicht Ihren Apps die Verwendung des DNS, mit dem das virtuelle Netzwerk konfiguriert ist.
• Erfordert ein routenbasiertes Virtual Network-Gateway, das mit einem Point-to-Site-VPN für SSTP konfiguriert ist, bevor es mit einer App verbunden werden kann.

Sie können die Integration des virtuellen Netzwerks mit erforderlichem Gateway in den folgenden Fällen nicht verwenden:

• Mit einem virtuellen Netzwerk, das mit ExpressRoute verbunden ist
• Aus einer Linux-App.
• Aus einem Windows-Container.
• Für den Zugriff auf durch Dienstendpunkte geschützte Ressourcen
• Um App-Einstellungen aufzulösen, die auf eine netzwerkgeschützte Key Vault-Instanz verweisen.
• Mit einem Koexistenzgateway, das sowohl ExpressRoute als auch Point-to-Site- oder Site-to-Site-VPNs unterstützt.

Durch die regionale Integration virtueller Netzwerke werden die oben genannten Einschränkungen entschärft.

Einrichten eines Gateways in Ihrem virtuellen Azure-Netzwerk

So erstellen Sie ein Gateway

1. Erstellen Sie das VPN-Gateway und das Subnetz. Wählen Sie einen routenbasierten VPN-Typ aus.

2. Legen Sie die Point-to-Site-Adressen fest. Wenn sich das Gateway nicht in der Basic-SKU befindet, muss IKEV2 in der Point-to-Site-Konfiguration deaktiviert und SSTP ausgewählt werden. Der Point-to Site-Adressraum muss in den RFC 1918-Adressblöcken 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 liegen.

Wenn Sie das Gateway für die Verwendung mit einer von einem Gateway abhängigen VNet-Integration erstellen, müssen Sie kein Zertifikat hochladen. Das Erstellen des Gateways kann 30 Minuten dauern. Sie können Ihre App erst in Ihr virtuelles Netzwerk integrieren, nachdem das Gateway erstellt wurde.

Funktionsweise der Integration des virtuellen Netzwerks mit erforderlichem Gateway

Die von einem Gateway abhängige VNet-Integration basiert auf der Point-to-Site-VPN-Technologie. Point-to-Site-VPNs beschränken den Netzwerkzugriff auf den virtuellen Computer, auf dem die App gehostet wird. Apps sind darauf beschränkt, Datenverkehr an das Internet nur über Hybridverbindungen oder die Integration virtueller Netzwerke zu senden. Wenn Ihre App über das Portal so konfiguriert wurde, dass sie die von einem Gateway abhängige VNet-Integration verwendet, wird eine komplexe Aushandlung in Ihrem Namen verwaltet, um Zertifikate auf der Gateway- und der Anwendungsseite zu erstellen und zuzuweisen. Das Ergebnis ist, dass die Worker, die Ihre Apps hosten, in der Lage sind, eine direkte Verbindung mit dem VNet-Gateway im ausgewählten virtuellen Netzwerk herzustellen.

Zugriff auf lokale Ressourcen

Apps können durch Integration mit virtuellen Netzwerken, die Site-to-Site-Verbindungen aufweisen, auf lokale Ressourcen zugreifen. Wenn Sie die von einem Gateway abhängige VNet-Integration verwenden, aktualisieren Sie Ihre lokalen VPN-Gatewayrouten mit Ihren Point-to-Site-Adressblöcken. Verwenden Sie beim ersten Einrichten des Site-to-Site-VPN die Skripts für die Konfiguration. Die Routen sollten damit richtig eingerichtet werden. Wenn Sie die Point-to-Site-Adressen nach dem Erstellen des Site-to-Site-VPN hinzufügen, müssen Sie die Routen manuell aktualisieren. Die Details zur Vorgehensweise variieren je nach Gateway und sind hier nicht beschrieben.

BGP-Routen von der lokalen Umgebung werden nicht automatisch an App Service weitergegeben. Sie müssen sie manuell in der Point-to-Site-Konfiguration verteilen, indem Sie die Schritte im Dokument Ankündigen von benutzerdefinierten Routen für P2S-VPN-Clients ausführen.

Peering

Bei der von einem Gateway abhängigen VNet-Integration mit Peering müssen Sie einige weitere Elemente konfigurieren. So konfigurieren Sie Peering für Ihre App

1. Fügen Sie eine Peeringverbindung mit dem virtuellen Netzwerk hinzu, mit dem Ihre App eine Verbindung herstellt. Aktivieren Sie beim Hinzufügen der Peeringverbindung Zugriff auf virtuelles Netzwerk zulassen sowie Weitergeleiteten Datenverkehr zulassen und Gatewaytransit zulassen.
2. Fügen Sie in dem virtuellen Netzwerk, das mit dem virtuellen Netzwerk, mit dem Sie verbunden sind, mittels Peering verknüpft ist, eine Peeringverbindung hinzu. Aktivieren Sie beim Hinzufügen der Peeringverbindung im virtuellen Zielnetzwerk Zugriff auf virtuelles Netzwerk zulassen, und aktivieren Sie Weitergeleiteten Datenverkehr zulassen und Allow remote gateways (Remotegateways zulassen).
3. Wechseln Sie im Portal zu App Service-Plan>Netzwerk>VNET-Integration. Wählen Sie das virtuelle Netzwerk aus, mit dem Ihre App eine Verbindung herstellt. Fügen Sie den Adressbereich des virtuellen Netzwerks, das mit dem virtuellen Netzwerk, mit dem Ihre App verbunden ist, mittels Peering verknüpft ist, im Abschnitt „Routing“ hinzu.

Verwalten der Integration virtueller Netzwerke

Das Verbinden und Trennen der Verbindung mit einem virtuellen Netzwerk erfolgt auf App-Ebene. Vorgänge, die sich auf die VNet-Integration über mehrere Apps auswirken können, werden auf Ebene des App Service-Plans ausgeführt. Sie können im Portal unter „App“ >Netzwerk>VNet-Integration Details zu Ihrem virtuellen Netzwerk abrufen. Ähnliche Informationen finden Sie auf der App Service-Planebene im Portal unter App Service-Plan>Netzwerk>VNET-Integration.

Der einzige Vorgang, den Sie in der App-Ansicht Ihrer VNet-Integrationsinstanz durchführen können, ist das Trennen Ihrer App von dem virtuellen Netzwerk, mit dem derzeit eine Verbindung besteht. Um Ihre App von einem virtuellen Netzwerk zu trennen, wählen Sie Verbindung trennen aus. Wenn Sie die Verbindung mit einem virtuellen Netzwerk trennen, wird Ihre App neu gestartet. Das Trennen der Verbindung führt nicht zu Änderungen in Ihrem virtuellen Netzwerk. Das Subnetz oder Gateway wird nicht entfernt. Wenn Sie Ihr virtuelles Netzwerk löschen möchten, trennen Sie zuerst Ihre App vom virtuellen Netzwerk und löschen die darin enthaltenen Ressourcen (z. B. Gateways).

Auf der Benutzeroberfläche der VNet-Integration des App Service-Plans werden alle Integrationen virtueller Netzwerke angezeigt, die von den Apps in Ihrem App Service-Plan verwendet werden. Um Details zu jedem virtuellen Netzwerk anzuzeigen, wählen Sie das virtuelle Netzwerk aus, an dem Sie interessiert sind. Es gibt zwei Aktionen, die Sie hier für die VNet-Integration mit erforderlichem Gateway durchführen können:

• Synchronisieren des Netzwerks: Der Vorgang zum Synchronisieren des Netzwerks wird nur für die von einem Gateway abhängige VNet-Integration verwendet. Durch die Netzwerksynchronisierung wird sichergestellt, dass Ihre Zertifikate und Netzwerkinformationen synchronisiert sind. Wenn Sie das DNS Ihres virtuellen Netzwerks hinzufügen oder ändern, führen Sie eine Netzwerksynchronisierung durch. Mit diesem Vorgang werden alle Apps, die dieses virtuelle Netzwerk verwenden, neu gestartet. Dieser Vorgang funktioniert nicht, wenn Sie eine App und ein virtuelles Netzwerk verwenden, die zu verschiedenen Abonnements gehören.
• Routen hinzufügen: Durch das Hinzufügen von Routen wird ausgehender Datenverkehr in Ihr virtuelles Netzwerk geleitet.

Die private IP-Adresse, die der Instanz zugewiesen ist, wird über die Umgebungsvariable WEBSITE_PRIVATE_IP verfügbar gemacht. Auf der Benutzeroberfläche der Kudu-Konsole wird auch die Liste der Umgebungsvariablen angezeigt, die für die Web-App verfügbar sind. Diese IP-Adresse ist eine IP-Adresse aus dem Adressbereich des Point-to-Site-Adresspools, der für das VNet-Gateway konfiguriert ist. Diese IP-Adresse wird von der Web-App zum Herstellen einer Verbindung mit den Ressourcen über das virtuelle Azure-Netzwerk verwendet.

Routing bei der Integration des virtuellen Netzwerks mit erforderlichem Gateway

Die in Ihrem virtuellen Netzwerk definierten Routen werden zum Leiten des Datenverkehrs aus der App in Ihr virtuelles Netzwerk verwendet. Wenn Sie weiteren ausgehenden Datenverkehr in das virtuelle Netzwerk senden möchten, fügen Sie diese Adressblöcke hier hinzu. Diese Funktion kann nur mit der von einem Gateway abhängigen VNet-Integration verwendet werden. Routingtabellen wirken sich nicht auf den App-Datenverkehr aus, wenn die Integration virtueller Netzwerke mit erforderlichem Gateway verwendet wird.

Zertifikate für die Integration des virtuellen Netzwerks mit erforderlichem Gateway

Wenn die von einem Gateway abhängige VNet-Integration aktiviert ist, müssen Zertifikate ausgetauscht werden, um die Sicherheit der Verbindung zu gewährleisten. Zusammen mit den Zertifikaten werden die DNS-Konfiguration, Routen und anderen Elemente, mit denen das Netzwerk beschrieben wird, ausgetauscht.

Wenn Zertifikate oder Netzwerkinformationen geändert werden, wählen Sie Netzwerk synchronisieren aus. Wenn Sie Netzwerk synchronisieren auswählen, bewirkt dies einen kurzen Ausfall der Verbindung zwischen der App und Ihrem virtuellen Netzwerk. Die App wird nicht neu gestartet, aber der Konnektivitätsverlust kann dazu führen, dass Ihre Website nicht richtig funktioniert.

Zertifikatverlängerung

Das zertifikat, das von der Gateway-erforderlichen Integration des virtuellen Netzwerks verwendet wird, hat eine Lebensdauer von 8 Jahren. Wenn Sie Über Apps mit gateway erforderlichen Integrationen für virtuelle Netzwerke verfügen, die länger leben, müssen Sie das Zertifikat verlängern. Sie können überprüfen, ob Ihr Zertifikat abgelaufen ist oder weniger als 6 Monate abgelaufen ist, indem Sie die VNet-Integrationsseite im Azure-Portal besuchen.

Sie können Ihr Zertifikat verlängern, wenn im Portal ein nahezu ablaufendes oder abgelaufenes Zertifikat angezeigt wird. Um das Zertifikat zu verlängern, müssen Sie das virtuelle Netzwerk trennen und erneut verbinden. Die erneute Verbindung führt zu einem kurzen Ausfall der Verbindung zwischen Ihrer App und Ihrem virtuellen Netzwerk. Die App wird nicht neu gestartet, aber der Konnektivitätsverlust kann dazu führen, dass Ihre Website nicht richtig funktioniert.

Preisübersicht

Bei der Verwendung der Funktion für die von einem Gateway abhängige VNet-Integration fallen drei Gebühren an:

• Gebühren laut App Service-Plantarif: Ihre Apps müssen in einem App Service-Plan mit dem Tarif „Basic“, „Standard“, „Premium“, „Premium v2“ oder „Premium v3“ enthalten sein. Weitere Informationen zu diesen Kosten finden Sie unter App Service-Preise.
• Datenübertragungskosten: Es gibt eine Gebühr für ausgehende Daten, auch wenn sich das virtuelle Netzwerk im selben Rechenzentrum befindet. Diese Gebühren werden unter Bandbreite – Preise beschrieben.
• Kosten für VPN Gateway: Es gibt Kosten für das virtuelle Netzwerkgateway, das für das Point-to-Site-VPN erforderlich ist. Weitere Informationen finden Sie unter VPN-Gateway: Preise.

Problembehandlung

Es gibt verschiedene Gründe, aus denen Ihre App einen bestimmten Host und Port nicht erreichen kann. In den meisten Fällen liegt eine der drei folgenden Ursachen vor:

• Eine Firewall. Falls eine Firewall den Zugriff verhindert, wird das TCP-Timeout ausgelöst. Das TCP-Timeout entspricht hier 21 Sekunden. Überprüfen Sie die Verbindung mithilfe des tcpping-Tools. TCP-Timeouts können zwar auch viele andere Ursachen haben, es empfiehlt sich jedoch, bei der Firewall zu beginnen.
• Kein DNS-Zugriff. Das DNS-Timeout beträgt 3 Sekunden pro DNS-Server. Wenn Sie zwei DNS-Server besitzen, beträgt das Timeout 6 Sekunden. Überprüfen Sie mithilfe des nameresolver-Tools, ob DNS funktioniert. Das nslookup-Tool kann nicht verwendet werden, da es nicht das DNS verwendet, mit dem Ihr virtuelles Netzwerk konfiguriert ist. Dieses Problem kann darauf zurückzuführen sein, dass eine Firewall oder Netzwerksicherheitsgruppe den Zugriff auf das DNS blockiert.

Sollte das Problem weiterhin bestehen, überprüfen Sie zunächst Folgendes:

• Liegt der Point-to-Site-Adressbereich in den RFC 1918-Bereichen (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255)?
• Wird im Portal angezeigt, dass das Gateway ausgeführt wird? Fahren Sie das Gateway hoch, wenn es heruntergefahren ist.
• Werden Zertifikate als synchronisiert angezeigt, oder vermuten Sie, dass die Netzwerkkonfiguration geändert wurde? Wenn Ihre Zertifikate nicht synchronisiert sind oder Sie vermuten, dass an Ihrer VNET-Konfiguration eine Änderung vorgenommen wurde, die nicht mit Ihren ASPs synchronisiert wurde, wählen Sie Netzwerk synchronisieren aus.
• Bei einer Verbindung über ein VPN: Ist Ihr lokales Gateway zum Zurückleiten von Datenverkehr an Azure konfiguriert? Wenn Sie die Endpunkte in Ihrem virtuellen Netzwerk erreichen können, aber nicht lokal, überprüfen Sie Ihre Routen.
• Versuchen Sie, ein Koexistenzgateway zu verwenden, das sowohl Point-to-Site als auch ExpressRoute unterstützt? Koexistenzgateways werden bei der Integration virtueller Netzwerke nicht unterstützt.

Das Debuggen von Netzwerkproblemen ist eine Herausforderung, da Sie nicht sehen können, was den Zugriff auf eine bestimmte Host:Port-Kombination blockiert. Mögliche Ursachen:

• Sie verfügen über eine aktivierte Firewall auf Ihrem Host, die den Zugriff auf den Anwendungsport über Ihren Point-to-Site-IP-Adressbereich verhindert Für die Durchquerung von Subnetzen ist häufig öffentlicher Zugriff erforderlich.
• Zielhost ausgefallen
• Anwendung nicht verfügbar
• Falsche IP-Adresse oder falscher Hostname
• Die Anwendung lauscht über einen anderen Port als erwartet. Sie können Ihre Prozess-ID auf den lauschenden Port festlegen, indem Sie auf dem Endpunkthost „netstat -aon“ verwenden.
• Netzwerksicherheitsgruppen sind so konfiguriert, dass der Zugriff auf Ihren Anwendungshost und -port aus Ihrem Point-to-Site-IP-Adressbereich verhindert wird.

Ihnen ist nicht bekannt, welche Adresse Ihre App tatsächlich verwendet. So kann eine beliebige Adresse im Point-to-Site-Adressbereich dafür verantwortlich sein. Sie müssen daher den Zugriff vom gesamten Adressbereich aus zulassen.

Weitere Debugschritte sind unter anderem:

• Stellen Sie eine Verbindung mit einer VM im virtuellen Netzwerk her, und versuchen Sie, die Ressource host:port von dort aus zu erreichen. Zum Testen des TCP-Zugriffs verwenden Sie den PowerShell-Befehl Test-NetConnection. Die Syntax ist:

Test-NetConnection hostname [optional: -Port]

• Rufen Sie eine Anwendung auf einer VM auf, und testen Sie den Zugriff auf den jeweiligen Host und Port über die Konsole der App mit tcpping.

Lokale Ressourcen

Wenn Ihre App eine Ressource lokal nicht erreichen kann, überprüfen Sie, ob Sie die Ressource über Ihr virtuelles Netzwerk erreichen können. Verwenden Sie den PowerShell-Befehl Test-NetConnection, um den TCP-Zugriff zu überprüfen. Wenn Ihre VM die lokale Ressource nicht erreichen kann, ist Ihre VPN- oder ExpressRoute-Verbindung möglicherweise nicht richtig konfiguriert.

Wenn die im virtuellen Netzwerk gehostete VM auf ein lokales System zugreifen kann, die App jedoch nicht, trifft wahrscheinlich einer der folgenden Gründe zu:

• Die Routen sind in Ihrem lokalen Gateway nicht mit Ihren Subnetz- oder Point-to-Site-Adressbereichen konfiguriert.
• Die Netzwerksicherheitsgruppen blockieren den Zugriff auf den Point-to-Site-IP-Adressbereich.
• Die lokalen Firewalls blockieren den Datenverkehr des Point-to-Site-IP-Adressbereichs.
• Sie versuchen, eine RFC 1918-fremde Adresse mit der Funktion für die Integration regionaler virtueller Netzwerke zu erreichen.

Weitere Informationen finden Sie im Leitfaden zur Problembehandlung bei der Integration virtueller Netzwerke.