Problemen met virtuele netwerken oplossen

Dit artikel bevat richtlijnen voor het oplossen van veelvoorkomende scenario's voor virtuele netwerken in Microsoft Power Platform. Het artikel richt zich op het gebruik van de PowerShell-module Microsoft.PowerPlatform.EnterprisePolicies om u te helpen bij het identificeren en oplossen van problemen die betrekking hebben op configuraties van virtuele netwerken.

Gebruik de diagnostische PowerShell-module

De Microsoft.PowerPlatform.EnterprisePolicies PowerShell-module helpt u bij het vaststellen en oplossen van problemen die betrekking hebben op configuraties van virtuele netwerken in Power Platform. U kunt het hulpprogramma gebruiken om de connectiviteit tussen uw Power Platform-omgeving en uw virtuele netwerk te controleren. U kunt deze ook gebruiken om eventuele onjuiste configuraties te identificeren die problemen kunnen veroorzaken. De Diagnostische PowerShell-module is beschikbaar in de PowerShell Gallery en de Bijbehorende GitHub-opslagplaats, PowerPlatform-EnterprisePolicies.

Installeer de module

Voer de volgende PowerShell-opdracht uit om de Diagnostische PowerShell-module te installeren:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

De diagnostische functies uitvoeren

Nadat u de module hebt geïnstalleerd, importeert u deze in uw PowerShell-sessie door de volgende opdracht uit te voeren:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

De module bevat verschillende functies voor het vaststellen en oplossen van problemen die betrekking hebben op configuraties van virtuele netwerken. Enkele van de belangrijkste functies zijn:

• Get-EnvironmentRegion: haalt de regio van de opgegeven Power Platform-omgeving op.
• Get-EnvironmentUsage: biedt informatie over het gebruik van de opgegeven Power Platform-omgeving.
• Test-DnsResolution: Test de DNS-omzetting voor de opgegeven domeinnaam.
• Test-NetworkConnectivity: test de netwerkverbinding tussen de Power Platform-omgeving en de doelresource.
• Test-TLSHandshake: test of er een TLS-handshake tot stand kan worden gebracht tussen de Power Platform-omgeving en de doelresource.

Zie de module Microsoft.PowerPlatform.EnterprisePolicies voor een volledige lijst met beschikbare functies in de diagnostische module.

Problemen melden in de diagnostische module

Als u problemen ondervindt bij het uitvoeren van de diagnostische module, meldt u deze via de GitHub-opslagplaats waar de module wordt gehost. De opslagplaats is beschikbaar op: PowerPlatform-EnterprisePolicies.

Als u een probleem wilt melden, gaat u naar de sectie Problemen van de opslagplaats en opent u een nieuw probleem. Geef gedetailleerde informatie op over het probleem dat u tegenkomt. Neem eventuele foutberichten of logboekvermeldingen op die u kunnen helpen bij het onderzoeken van het probleem. Neem geen gevoelige informatie op in uw rapport.

Veelvoorkomende problemen oplossen

De ene omgeving werkt, maar een andere omgeving doet dat niet

Als alles correct is geconfigureerd, maar nog steeds problemen ondervindt, gebruikt u de functie Get-EnvironmentRegion uit de diagnostische PowerShell-module om te controleren of de regio's van uw Power Platform-omgevingen hetzelfde zijn. Voer de volgende opdracht uit:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Als de omgevingen zich in verschillende regio's bevinden en een omgeving werkt maar de andere niet, is het probleem in de installatie van het virtuele netwerk voor de mislukte regio. Als u ervoor wilt zorgen dat uw volledige installatie juist is geconfigureerd, voert u eventuele verdere diagnostische opdrachten uit voor beide regio's. Als u een regio wilt opgeven, neemt u de -Region parameter op. Voorbeeld:

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

Uw omgeving behoort tot een specifieke geografie van Power Platform. Een Power Platform-regio kan echter twee Azure-regio's omvatten. Uw omgeving kan zich in beide regio's bevinden en er kan ook automatisch een failover plaatsvinden. Daarom moet u, om hoge beschikbaarheid en connectiviteit te garanderen, uw virtuele netwerken configureren in beide Azure-regio's die zijn gekoppeld aan uw Power Platform-regio. Zie Power Platform-regio's voor meer informatie over hoe Power Platform-regio's worden toegewezen aan Azure-regio's die ondersteuning bieden voor de functionaliteit van het virtuele netwerk.

Hostnaam is niet gevonden

Als u problemen ondervindt die van invloed zijn op hostnaamomzetting, gebruikt u de functie Test-DnsResolution uit de diagnostische PowerShell-module om te controleren of de hostnaam correct is opgelost. Voer de volgende opdracht uit:

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

Met deze opdracht wordt de DNS-omzetting voor de opgegeven hostnaam getest in de context van uw Power Platform-omgeving. De aanvraag wordt gestart vanuit uw gedelegeerde subnet en probeert de hostnaam om te zetten met behulp van de DNS-server die is geconfigureerd voor uw virtuele netwerk. Als de hostnaam niet correct is omgezet, moet u mogelijk uw DNS-instellingen controleren om ervoor te zorgen dat de hostnaam juist is geconfigureerd.

Aanvraag maakt gebruik van een openbaar IP-adres in plaats van het privé-IP-adres

Als u problemen ondervindt waarbij aanvragen voor een resource een openbaar IP-adres gebruiken in plaats van het privé-IP-adres, retourneert de DNS-omzetting voor de hostnaam van de resource mogelijk een openbaar IP-adres. Dit probleem kan van invloed zijn op zowel Azure- als niet-Azure-resources.

Niet-Azure-resource zonder een privé-eindpunt

Als een niet-Azure-resource geen privé-eindpunt heeft, maar u er wel toegang toe hebt vanuit uw virtuele netwerk, moet u uw DNS-server configureren om de hostnaam van de resource om te lossen naar het privé-IP-adres. Voeg een DNS A-record toe aan uw DNS-server waarmee de hostnaam van de resource wordt toegewezen aan het privé-IP-adres:

• Als u een aangepaste DNS-server gebruikt, voegt u de A-record rechtstreeks toe aan uw server.
• Als u een door Azure geleverde DNS gebruikt, maakt u een privé-DNS-zone van Azure en koppelt u deze aan uw virtuele netwerk. Voeg vervolgens de A-record toe aan de privé-DNS-zone.

Deze toewijzing zorgt ervoor dat u toegang krijgt tot de resource via het privé-IP-adres.

Azure-resource met een privé-eindpunt

Als een Azure-resource een privé-eindpunt heeft, moet de DNS-omzetting voor de hostnaam van de resource het privé-IP-adres retourneren dat is gekoppeld aan het privé-eindpunt. Als de DNS-omzetting in plaats daarvan een openbaar IP-adres retourneert, ontbreken er mogelijk records in uw DNS-configuratie. Volg deze stappen:

1. Controleer of er een privé-DNS-zone bestaat voor uw resourcetype. Bijvoorbeeld privatelink.database.windows.net voor Azure SQL Database. Als de privé-DNS-zone niet bestaat, maakt u er een.
2. Controleer of de privé-DNS-zone is gekoppeld aan uw virtuele netwerk. Als de privé-DNS-zone niet is gekoppeld aan uw virtuele netwerk, koppelt u deze.

Nadat u de privé-DNS-zone aan uw virtuele netwerk hebt gekoppeld, moet de hostnaam van de resource worden omgezet in het privé-IP-adres dat is gekoppeld aan het privé-eindpunt.

DNS-configuratiewijzigingen testen

Nadat u de DNS-configuratie hebt bijgewerkt, gebruikt u de functie Test-DnsResolution uit de diagnostische PowerShell-module om te controleren of de hostnaam wordt omgezet in het juiste privé-IP-adres. Voer de volgende opdracht uit:

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

Kan geen verbinding maken met de resource

Als u problemen ondervindt die van invloed zijn op de connectiviteit met een resource, gebruikt u de functie Test-NetworkConnectivity van de Diagnostische PowerShell-module om te controleren op connectiviteit. Voer de volgende opdracht uit:

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

Met deze opdracht wordt geprobeerd een TCP-verbinding tot stand te brengen met de opgegeven bestemming en poort in de context van uw Power Platform-omgeving. De aanvraag wordt gestart vanuit uw gedelegeerde subnet en probeert verbinding te maken met de opgegeven bestemming met behulp van de netwerkconfiguratie van uw virtuele netwerk. Als de verbinding mislukt, moet u mogelijk de netwerkinstellingen controleren om ervoor te zorgen dat de bestemming bereikbaar is vanuit uw virtuele netwerk. Een geslaagde verbinding geeft aan dat er netwerkconnectiviteit bestaat tussen de Power Platform-omgeving en de opgegeven resource.

Kan geen TLS-handshake tot stand brengen

Sommige firewalls kunnen toestaan dat TCP-verbindingen tot stand worden gebracht, maar vervolgens blokkeren ze het werkelijke verkeer naar de resource (bijvoorbeeld HTTPS). Dus zelfs als de functie Test-NetworkConnectivity de netwerkverbinding aangeeft, garandeert deze status niet dat de resource volledig toegankelijk is.

Gebruik de functie Test-TLSHandshake om te diagnosticeren waarom een handshake niet tot stand kan worden gebracht. Voer de volgende opdracht uit:

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

Met deze opdracht wordt informatie geretourneerd die u kan helpen fouten op te sporen waarom de handshake is mislukt. De uitvoer bevat het certificaat dat de server heeft gepresenteerd, de coderingssuite, het protocol en eventuele SSL-foutbeschrijvingen.

De verbinding is geslaagd, maar de toepassing werkt nog steeds niet

Als de connectiviteitstests zijn geslaagd, maar u nog steeds problemen ondervindt in uw toepassing, controleert u de instellingen en configuraties op toepassingsniveau:

1. Controleer of uw firewall toegang toestaat vanuit het gedelegeerde subnet naar de resource.
2. Controleer of het certificaat dat de resource presenteert door het publiek vertrouwd wordt.
3. Zorg ervoor dat geen verificatie- of autorisatieproblemen toegang tot de resource verhinderen.

Mogelijk kunt u het probleem niet vaststellen of oplossen met behulp van de PowerShell-module voor diagnostiek. In dit geval maakt u een subnet zonder delegatie in uw virtuele netwerk en implementeert u een virtuele machine (VM) in dat subnet. Vervolgens kunt u de virtuele machine gebruiken om verdere diagnostische gegevens en stappen voor probleemoplossing uit te voeren, zoals het controleren van netwerkverkeer, het analyseren van logboeken en het testen van connectiviteit op toepassingsniveau.

Voorbeeldscenario's voor probleemoplossing

Maak kennis met Contoso LLC, een multi-nationaal bedrijf met meerdere Power Platform-omgevingen in heel Europa en virtuele netwerken in Europa - west en Europa - noord. Elk virtueel netwerk heeft een subnet dat is gedelegeerd aan Power Platform. Elk subnet is gekoppeld aan een ondernemingsbeleid dat is gekoppeld aan de Power Platform-omgeving.

In de volgende scenario's ziet u hoe Contoso gebruikmaakt van de diagnostische cmdlets die in de vorige secties zijn opgegeven om verbindingsproblemen op te lossen die van invloed zijn op deze installatie.

Verbinding maken met een Azure Key Vault via een privé-eindpunt

Contoso wil dat de Power Platform-omgevingen verbinding maken met de sleutelkluis via het virtuele netwerk en de sleutelkluis zo configureert dat aanvragen van het openbare internet worden geweigerd. Wanneer Contoso probeert verbinding te maken met de sleutelkluis vanuit zijn omgeving, wordt de verbinding geweigerd omdat de aanvragen niet correct worden gerouteerd. Contoso gebruikt de volgende stappen voor probleemoplossing om het probleem vast te stellen.

Eerst wordt Get-EnvironmentRegion uitgevoerd om te controleren naar welke subnetaanvragen worden verzonden:

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

De geretourneerde regio identificeert welk virtueel netwerk moet worden onderzocht. Als de opdracht bijvoorbeeld West-Europa retourneert, moet Contoso zich concentreren op het virtuele netwerk West-Europa.

Vervolgens controleert Contoso of het IP-adres dat wordt geretourneerd door DNS-omzetting van de FQDN (Fully Qualified Domain Name) van de sleutelkluis een privé-IP-adres is. Omdat het bedrijf omgevingen in beide regio's heeft, moet het DNS-omzetting voor elke regio testen met behulp van Test-DnsResolution:

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"

Als de DNS-omzetting een openbaar IP-adres retourneert in plaats van een privé-IP-adres, is het privé-eindpunt voor de sleutelkluis mogelijk niet juist geconfigureerd. Contoso moet controleren of:

1. Er bestaat een privé-eindpunt voor de sleutelkluis en het is gekoppeld aan het juiste virtuele netwerk.
2. Er bestaat een privé-DNS-zone voor de sleutelkluis (bijvoorbeeld privatelink.vaultcore.azure.net) en deze is gekoppeld aan het virtuele netwerk.
3. De privé-DNS-zone bevat een A-record waarmee de hostnaam van de sleutelkluis wordt toegewezen aan het privé-IP-adres van het privé-eindpunt.

Wanneer Contoso de DNS-omzettingstest uitvoert voor Europa - west, detecteert het bedrijf dat de opdracht een openbaar IP-adres retourneert. Nadat het bedrijf heeft onderzocht, wordt ontdekt dat de privé-DNS-zone voor de sleutelkluis niet is gekoppeld aan het virtuele netwerk europa - west. Nadat Contoso de privé-DNS-zone aan het virtuele netwerk heeft gekoppeld en de test opnieuw uitvoert, retourneert de DNS-omzetting het juiste privé-IP-adres.

Nadat de DNS-omzetting het juiste privé-IP-adres in beide regio's retourneert, is de volgende stap het testen van de netwerkverbinding met de sleutelkluis met behulp van Test-NetworkConnectivity:

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"

Als de verbinding mislukt, blokkeren de NSG-regels (netwerkbeveiligingsgroep) of firewallinstellingen mogelijk verkeer van het gedelegeerde subnet naar de sleutelkluis. Contoso moet controleren of:

1. De NSG-regels die zijn gekoppeld aan het gedelegeerde subnet staan uitgaand verkeer toe op poort 443.
2. Met de Key Vault-firewall worden binnenkomende verbindingen vanuit het IP-bereik van het gedelegeerde subnet toegestaan.
3. Elk virtueel Azure Firewall - of netwerkapparaat in het verkeerspad maakt de verbinding mogelijk.

In dit geval vindt Contoso dat de firewall van de sleutelkluis niet is geconfigureerd om binnenkomende verbindingen van een privébron toe te staan. Nadat de firewallinstellingen zijn bijgewerkt om verbindingen van het gedelegeerde subnet toe te staan, slaagt de netwerkconnectiviteitstest en kan de Power Platform-omgeving verbinding maken met de sleutelkluis via het virtuele netwerk.

Verbinding maken met een webserver die wordt gehost in een on-premises netwerk

Contoso wil ook dat de Power Platform-omgeving verbinding maakt met een webserver die wordt gehost in het on-premises netwerk. De webserver is toegankelijk via het virtuele netwerk van het bedrijf via een ExpressRoute-verbinding . Wanneer Contoso vanuit de Power Platform-omgeving verbinding probeert te maken met de webserver, mislukt de verbinding.

Hoewel de DNS-omzetting het juiste IP-adres retourneert en de netwerkverbindingstest slaagt, heeft Contoso nog steeds geen toegang tot de webserver. Om dit probleem vast te stellen, test het bedrijf de TLS-handshake met behulp van Test-TLSHandshake:

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

Als de TLS-handshake mislukt, bevat de uitvoer details over het certificaat, de coderingssuite en het gebruikte protocol. Contoso kan deze informatie gebruiken om certificaat- of TLS-configuratieproblemen te identificeren. De opdracht voert een eerste analyse uit van de geretourneerde uitvoer en waarschuwingen over enkele basisproblemen. Contoso kan echter de volledige uitvoer analyseren om het probleem gedetailleerder te onderzoeken.

In dit geval detecteert Contoso dat de TLS-handshake niet tot stand kan worden gebracht omdat het certificaat niet wordt vertrouwd. Nadat het bedrijf de certificaatgegevens in de opdrachtuitvoer heeft onderzocht, wordt bepaald dat de webserver een zelfondertekend certificaat gebruikt. Power Platform vereist openbaar vertrouwde certificaten voor TLS-verbindingen. Nadat Contoso de webserver heeft bijgewerkt om een certificaat te gebruiken dat is ondertekend door een openbaar vertrouwde certificeringsinstantie, slaagt de TLS-handshake en kan de Power Platform-omgeving verbinding maken met de webserver.

Zie de details van de Azure-certificeringsinstantie voor meer informatie over certificeringsinstanties die worden vertrouwd door Azure-services.