Behandeln von Problemen mit virtuellen Netzwerken

Dieser Artikel enthält Anleitungen zur Problembehandlung allgemeiner Szenarien für virtuelle Netzwerke in Microsoft Power Platform. Der Artikel konzentriert sich auf die Verwendung des PowerShell-Moduls "Microsoft.PowerPlatform.EnterprisePolicies ", um Probleme im Zusammenhang mit virtuellen Netzwerkkonfigurationen zu identifizieren und zu beheben.

Verwenden des PowerShell-Diagnosemoduls

Mit dem Microsoft.PowerPlatform.EnterprisePolicies PowerShell-Modul können Sie Probleme im Zusammenhang mit virtuellen Netzwerkkonfigurationen in Power Platform diagnostizieren und beheben. Sie können das Tool verwenden, um die Konnektivität zwischen Ihrer Power Platform-Umgebung und Ihrem virtuellen Netzwerk zu überprüfen. Sie können sie auch verwenden, um Fehlkonfigurationen zu identifizieren, die Probleme verursachen können. Das PowerShell-Diagnosemodul steht im PowerShell-Katalog und dem GitHub-Repository PowerPlatform-EnterprisePolicies zur Verfügung.

Installieren Sie das -Modul

Führen Sie zum Installieren des PowerShell-Diagnosemoduls den folgenden PowerShell-Befehl aus:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Ausführen der Diagnosefunktionen

Nachdem Sie das Modul installiert haben, importieren Sie es in Ihre PowerShell-Sitzung, indem Sie den folgenden Befehl ausführen:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

Das Modul enthält mehrere Funktionen zum Diagnostizieren und Beheben von Problemen im Zusammenhang mit virtuellen Netzwerkkonfigurationen. Einige der wichtigsten Funktionen sind:

• Get-EnvironmentRegion: Ruft den Bereich der angegebenen Power Platform-Umgebung ab.
• Get-EnvironmentUsage: Stellt Informationen zur Verwendung der angegebenen Power Platform-Umgebung bereit.
• Test-DnsResolution: Testet die DNS-Auflösung für den angegebenen Domänennamen.
• Test-NetworkConnectivity: Testet die Netzwerkverbindung zwischen der Power Platform-Umgebung und der Zielressource.
• Test-TLSHandshake: Testet, ob ein TLS-Handshake zwischen der Power Platform-Umgebung und der Zielressource hergestellt werden kann.

Eine vollständige Liste der verfügbaren Funktionen im Diagnosemodul finden Sie unter "Microsoft.PowerPlatform.EnterprisePolicies Module".

Melden von Problemen im Diagnosemodul

Wenn Beim Ausführen des Diagnosemoduls Probleme auftreten, melden Sie sie über das GitHub-Repository, in dem das Modul gehostet wird. Das Repository ist verfügbar unter: PowerPlatform-EnterprisePolicies.

Um ein Problem zu melden, wechseln Sie zum Abschnitt "Probleme " des Repositorys, und öffnen Sie ein neues Problem. Geben Sie detaillierte Informationen zu dem Auftreten des Problems an. Schließen Sie alle Fehlermeldungen oder Protokolleinträge ein, die bei der Untersuchung des Problems hilfreich sein können. Fügen Sie keine vertraulichen Informationen in Ihren Bericht ein.

Häufige Probleme beheben

Eine Umgebung funktioniert, aber eine andere nicht.

Wenn alles ordnungsgemäß konfiguriert ist, aber weiterhin Probleme auftreten, verwenden Sie die Funktion "Get-EnvironmentRegion " aus dem PowerShell-Diagnosemodul, um zu überprüfen, ob die Regionen Ihrer Power Platform-Umgebungen identisch sind. Führen Sie den folgenden Befehl aus:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Wenn sich die Umgebungen in verschiedenen Regionen befinden und eine funktioniert, die andere jedoch nicht funktioniert, befindet sich das Problem im virtuellen Netzwerksetup für die fehlerhafte Region. Um sicherzustellen, dass Das vollständige Setup ordnungsgemäß konfiguriert ist, führen Sie alle weiteren Diagnosebefehle für beide Regionen aus. Um einen Bereich anzugeben, schließen Sie den -Region Parameter ein. Beispiel:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>" -Region "<AzureRegion>"

Ihre Umgebung gehört zu einer bestimmten Power Platform-Geografie. Eine Power Platform-Region kann jedoch zwei Azure-Regionen umfassen. Ihre Umgebung kann sich entweder in der einen oder der anderen Region befinden, und sie kann auch automatisch zwischen ihnen umschalten. Um hohe Verfügbarkeit und Konnektivität sicherzustellen, müssen Sie ihre virtuellen Netzwerke in beiden Azure-Regionen konfigurieren, die Ihrer Power Platform-Region zugeordnet sind. Informationen dazu, wie Power Platform-Regionen Azure-Regionen zugeordnet werden, die die Funktionalität des virtuellen Netzwerks unterstützen, finden Sie unter Power Platform-Regionen.

Hostname nicht gefunden

Wenn Probleme auftreten, die sich auf die Hostnamenauflösung auswirken, verwenden Sie die Test-DnsResolution-Funktion aus dem PowerShell-Diagnosemodul, um zu überprüfen, ob der Hostname ordnungsgemäß behoben ist. Führen Sie den folgenden Befehl aus:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

Dieser Befehl testet die DNS-Auflösung für den angegebenen Hostnamen im Kontext Ihrer Power Platform-Umgebung. Die Anforderung wird von Ihrem delegierten Subnetz initiiert und versucht, den Hostnamen mithilfe des DNS-Servers aufzulösen, der für Ihr virtuelles Netzwerk konfiguriert ist. Wenn der Hostname nicht ordnungsgemäß aufgelöst wird, müssen Sie möglicherweise Ihre DNS-Einstellungen überprüfen, um sicherzustellen, dass der Hostname ordnungsgemäß konfiguriert ist.

Anforderung verwendet eine öffentliche IP-Adresse anstelle der privaten IP-Adresse.

Wenn Probleme auftreten, bei denen Anforderungen an eine Ressource eine öffentliche IP-Adresse anstelle der privaten IP-Adresse verwenden, kann es sein, dass die DNS-Auflösung für den Ressourcen-Hostname eine öffentliche IP-Adresse zurückgibt. Dieses Problem kann sich sowohl auf Azure- als auch auf Nicht-Azure-Ressourcen auswirken.

Nicht-Azure-Ressource ohne privaten Endpunkt

Wenn eine Nicht-Azure-Ressource keinen privaten Endpunkt hat, Sie aber über Ihr virtuelles Netzwerk darauf zugreifen können, müssen Sie Ihren DNS-Server so konfigurieren, dass der Hostname der Ressource in seine private IP-Adresse aufgelöst wird. Fügen Sie Ihrem DNS-Server einen DNS-A-Eintrag hinzu, der dem Hostnamen der Ressource seine private IP-Adresse zuordnet:

• Wenn Sie einen benutzerdefinierten DNS-Server verwenden, fügen Sie den A-Eintrag direkt zu Ihrem Server hinzu.
• Wenn Sie ein von Azure bereitgestelltes DNS verwenden, erstellen Sie eine private Azure DNS-Zone, und verknüpfen Sie sie mit Ihrem virtuellen Netzwerk. Fügen Sie dann den A-Eintrag zur privaten DNS-Zone hinzu.

Diese Zuordnung stellt sicher, dass Sie über die private IP-Adresse auf die Ressource zugreifen.

Azure-Ressource mit einem privaten Endpunkt

Wenn eine Azure-Ressource über einen privaten Endpunkt verfügt, sollte die DNS-Auflösung für den Hostnamen der Ressource die private IP-Adresse zurückgeben, die dem privaten Endpunkt zugeordnet ist. Wenn die DNS-Auflösung stattdessen eine öffentliche IP-Adresse zurückgibt, könnten in Ihrer DNS-Konfiguration eventuell Einträge fehlen. Folgen Sie diesen Schritten:

1. Stellen Sie sicher, dass für Ihren Ressourcentyp eine private DNS-Zone vorhanden ist. Beispiel: privatelink.database.windows.net für Azure SQL-Datenbank. Wenn die private DNS-Zone nicht vorhanden ist, erstellen Sie eine.
2. Stellen Sie sicher, dass die private DNS-Zone mit Ihrem virtuellen Netzwerk verknüpft ist. Wenn die private DNS-Zone nicht mit Ihrem virtuellen Netzwerk verknüpft ist, verknüpfen Sie sie.

Nachdem Sie die private DNS-Zone mit Ihrem virtuellen Netzwerk verknüpft haben, sollte der Ressourcenhostname in die private IP-Adresse aufgelöst werden, die dem privaten Endpunkt zugeordnet ist.

Testen von DNS-Konfigurationsänderungen

Nachdem Sie die DNS-Konfiguration aktualisiert haben, verwenden Sie die Funktion "Test-DnsResolution " aus dem PowerShell-Modul der Diagnose, um zu überprüfen, ob der Hostname in die richtige private IP-Adresse aufgelöst wird. Führen Sie den folgenden Befehl aus:

Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"

Eine Verbindung mit der Ressource kann nicht hergestellt werden.

Wenn Probleme auftreten, die sich auf die Verbindung mit einer Ressource auswirken, verwenden Sie die Test-NetworkConnectivity-Funktion aus dem PowerShell-Diagnosemodul, um die Verbindung zu überprüfen. Führen Sie den folgenden Befehl aus:

Test-NetworkConnectivity -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

Dieser Befehl versucht, eine TCP-Verbindung mit dem angegebenen Ziel und Port im Kontext Ihrer Power Platform-Umgebung herzustellen. Die Anforderung wird von Ihrem delegierten Subnetz initiiert und versucht, mithilfe der Netzwerkkonfiguration aus Ihrem virtuellen Netzwerk eine Verbindung mit dem angegebenen Ziel herzustellen. Wenn die Verbindung fehlschlägt, müssen Sie möglicherweise Die Netzwerkeinstellungen überprüfen, um sicherzustellen, dass das Ziel über Ihr virtuelles Netzwerk erreichbar ist. Eine erfolgreiche Verbindung gibt an, dass die Netzwerkkonnektivität zwischen der Power Platform-Umgebung und der angegebenen Ressource vorhanden ist.

Ein TLS-Handshake kann nicht hergestellt werden.

Einige Firewalls ermöglichen möglicherweise das Herstellen von TCP-Verbindungen, aber dann blockieren sie den tatsächlichen Datenverkehr an die Ressource (z. B. HTTPS). Selbst wenn die Test-NetworkConnectivity-Funktion die Netzwerkkonnektivität angibt, garantiert dieser Status daher nicht, dass die Ressource vollständig zugänglich ist.

Verwenden Sie die Funktion "Test-TLSHandshake ", um zu diagnostizieren, warum ein Handshake nicht hergestellt werden kann. Führen Sie den folgenden Befehl aus:

Test-TLSHandshake -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433

Dieser Befehl gibt Informationen zurück, die Ihnen beim Debuggen helfen können, warum der Handshake fehlgeschlagen ist. Die Ausgabe enthält das vom Server dargestellte Zertifikat, die Verschlüsselungssuite, das Protokoll und alle SSL-Fehlerbeschreibungen.

Die Konnektivität ist erfolgreich, aber die Anwendung funktioniert immer noch nicht.

Wenn die Verbindungstests erfolgreich sind, aber weiterhin Probleme in Ihrer Anwendung auftreten, überprüfen Sie die Einstellungen und Konfigurationen auf Anwendungsebene:

1. Überprüfen Sie, ob Ihre Firewall den Zugriff vom delegierten Subnetz auf die Ressource zulässt.
2. Stellen Sie sicher, dass das von der Ressource angezeigte Zertifikat öffentlich vertrauenswürdig ist.
3. Stellen Sie sicher, dass keine Authentifizierungs- oder Autorisierungsprobleme den Zugriff auf die Ressource verhindern.

Möglicherweise können Sie das Problem nicht mithilfe des PowerShell-Diagnosemoduls diagnostizieren oder beheben. Erstellen Sie in diesem Fall ein Subnetz ohne Delegierung in Ihrem virtuellen Netzwerk, und stellen Sie einen virtuellen Computer (VM) in diesem Subnetz bereit. Anschließend können Sie den virtuellen Computer verwenden, um weitere Diagnose- und Problembehandlungsschritte auszuführen, z. B. das Überprüfen des Netzwerkdatenverkehrs, die Analyse von Protokollen und das Testen der Konnektivität auf Anwendungsebene.

Beispiel für Problembehandlungsszenarien

Treffen Sie Contoso LLC, ein multinationales Unternehmen mit mehreren Power Platform-Umgebungen in ganz Europa und virtuellen Netzwerken in Westeuropa und Nordeuropa. Jedes virtuelle Netzwerk verfügt über ein Subnetz, das an Power Platform delegiert wird. Jedes Subnetz ist einer Unternehmensrichtlinie zugeordnet, die mit der Power Platform-Umgebung verknüpft ist.

In den folgenden Szenarien wird gezeigt, wie Contoso die Diagnose-Cmdlets verwendet, die in den vorherigen Abschnitten bereitgestellt werden, um Konnektivitätsprobleme zu beheben, die sich auf diese Einrichtung auswirken.

Herstellen einer Verbindung mit einem Azure Key Vault über einen privaten Endpunkt

Contoso möchte, dass seine Power Platform-Umgebungen über das virtuelle Netzwerk eine Verbindung mit seinem Schlüsseltresor herstellen und den Schlüsseltresor so konfiguriert, dass Anforderungen aus dem öffentlichen Internet abgelehnt werden. Wenn Contoso versucht, eine Verbindung mit dem Schlüsseltresor aus seiner Umgebung herzustellen, wird die Verbindung abgelehnt, da Anforderungen nicht ordnungsgemäß weitergeleitet werden. Um das Problem zu diagnostizieren, verwendet Contoso die folgenden Schritte zur Problembehandlung.

Zunächst wird Get-EnvironmentRegion ausgeführt, um zu überprüfen, an welche Subnetzanforderungen gesendet werden:

Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000001"
Get-EnvironmentRegion -EnvironmentId "00000000-0000-0000-0000-000000000002"

Die zurückgegebene Region gibt an, welches virtuelle Netzwerk untersucht werden soll. Wenn der Befehl beispielsweise "Westeuropa" zurückgibt, muss Contoso sich auf die Problembehandlung im virtuellen Netzwerk "Westeuropa" konzentrieren.

Als Nächstes überprüft Contoso, ob die IP-Adresse, die von der DNS-Auflösung des vollqualifizierten Schlüsseltresor-Domänennamens (Fully Qualified Domain Name, FQDN) zurückgegeben wird, eine private IP-Adresse ist. Da das Unternehmen umgebungen in beiden Regionen hat, muss es die DNS-Auflösung für jede Region mithilfe von Test-DnsResolution testen:

Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "westeurope"
Test-DnsResolution -EnvironmentId "00000000-0000-0000-0000-000000000001" -HostName "contoso-keyvault.vault.azure.net" -Region "northeurope"

Wenn die DNS-Auflösung eine öffentliche IP-Adresse anstelle einer privaten IP-Adresse zurückgibt, ist der private Endpunkt für den Schlüsseltresor möglicherweise nicht ordnungsgemäß konfiguriert. Contoso muss folgendes überprüfen:

1. Ein privater Endpunkt ist für den Schlüsseltresor vorhanden und dem richtigen virtuellen Netzwerk zugeordnet.
2. Für den Key Vault (z.B.) ist eine privatelink.vaultcore.azure.net vorhanden, die mit dem virtuellen Netzwerk verknüpft ist.
3. Die private DNS-Zone enthält einen A-Eintrag , der den Schlüsseltresor-Hostname der privaten IP-Adresse des privaten Endpunkts zuordnet.

Wenn Contoso den DNS-Auflösungstest für Westeuropa ausführt, ermittelt das Unternehmen, dass der Befehl eine öffentliche IP-Adresse zurückgibt. Nach der Untersuchung durch das Unternehmen stellt es fest, dass die private DNS-Zone für den Key Vault nicht mit dem virtuellen Netzwerk in Westeuropa verknüpft war. Nachdem Contoso die private DNS-Zone mit dem virtuellen Netzwerk verknüpft und den Test erneut ausgeführt hat, gibt die DNS-Auflösung die richtige private IP-Adresse zurück.

Nachdem die DNS-Auflösung die richtige private IP-Adresse in beiden Regionen zurückgibt, besteht der nächste Schritt darin, die Netzwerkkonnektivität mit dem Schlüsseltresor mithilfe von Test-NetworkConnectivity zu testen:

Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "westeurope"
Test-NetworkConnectivity -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "contoso-keyvault.vault.azure.net" -Port 443 -Region "northeurope"

Wenn die Verbindung fehlschlägt, blockieren die NSG-Regeln (Network Security Group) oder Firewalleinstellungen möglicherweise den Datenverkehr vom delegierten Subnetz zum Schlüsseltresor. Contoso muss überprüfen, ob:

1. Die NSG-Regeln, die dem delegierten Subnetz zugeordnet sind, lassen ausgehenden Datenverkehr an Port 443 zu.
2. Die Schlüsseltresorfirewall ermöglicht eingehende Verbindungen aus dem IP-Bereich des delegierten Subnetzes.
3. Jede virtuelle Azure-Firewall oder Netzwerk-Appliance im Datenverkehrspfad ermöglicht die Verbindung.

In diesem Fall stellt Contoso fest, dass die Key Vault-Firewall nicht so konfiguriert wurde, dass eingehende Verbindungen von einer beliebigen privaten Quelle zugelassen werden. Nachdem die Firewalleinstellungen aktualisiert wurden, um Verbindungen vom delegierten Subnetz zuzulassen, ist der Netzwerkkonnektivitätstest erfolgreich, und die Power Platform-Umgebung kann erfolgreich über das virtuelle Netzwerk eine Verbindung mit dem Schlüsseltresor herstellen.

Herstellen einer Verbindung mit einem Webserver, der in einem lokalen Netzwerk gehostet wird

Contoso möchte außerdem, dass seine Power Platform-Umgebung eine Verbindung mit einem Webserver herstellt, der in seinem lokalen Netzwerk gehostet wird. Auf den Webserver kann über das virtuelle Netzwerk des Unternehmens über eine ExpressRoute-Verbindung zugegriffen werden. Wenn Contoso versucht, über seine Power Platform-Umgebung eine Verbindung mit dem Webserver herzustellen, schlägt die Verbindung fehl.

Obwohl die DNS-Auflösung die richtige IP-Adresse zurückgibt und der Netzwerkverbindungstest erfolgreich verläuft, kann Contoso trotzdem nicht auf den Webserver zugreifen. Um dieses Problem zu diagnostizieren, testet das Unternehmen den TLS-Handshake mithilfe von Test-TLSHandshake:

Test-TLSHandshake -EnvironmentId "00000000-0000-0000-0000-000000000001" -Destination "webserver.contoso.local" -Port 443 -Region "westeurope"

Wenn der TLS-Handshake fehlschlägt, enthält die Ausgabe Details zum Zertifikat, der Verschlüsselungssuite und dem verwendeten Protokoll. Contoso kann diese Informationen verwenden, um Zertifikat- oder TLS-Konfigurationsprobleme zu identifizieren. Der Befehl führt eine anfängliche Analyse der zurückgegebenen Ausgabe und Warnungen zu einigen grundlegenden Problemen durch. Contoso kann jedoch die vollständige Ausgabe analysieren, um das Problem ausführlicher zu untersuchen.

In diesem Fall ermittelt Contoso, dass der TLS-Handshake nicht eingerichtet werden kann, da das Zertifikat nicht vertrauenswürdig ist. Nachdem das Unternehmen die Zertifikatdetails in der Befehlsausgabe untersucht hat, bestimmt es, dass der Webserver ein selbstsigniertes Zertifikat verwendet. Power Platform erfordert öffentlich vertrauenswürdige Zertifikate für TLS-Verbindungen. Nachdem Contoso den Webserver aktualisiert hat, um ein Zertifikat zu verwenden, das von einer öffentlich vertrauenswürdigen Zertifizierungsstelle signiert ist, ist der TLS-Handshake erfolgreich, und die Power Platform-Umgebung kann eine Verbindung mit dem Webserver herstellen.

Weitere Informationen zu Zertifizierungsstellen, die von Azure-Diensten als vertrauenswürdig eingestuft werden, finden Sie unter Azure Certificate Authority Details.