Felsöka problem med virtuella nätverk

Den här artikeln innehåller vägledning för att felsöka vanliga scenarier för virtuella nätverk i Microsoft Power Platform. Artikeln fokuserar på hur du använder PowerShell-modulen Microsoft.PowerPlatform.EnterprisePolicies för att identifiera och lösa problem som rör konfigurationer av virtuella nätverk.

Använda PowerShell-modulen för diagnostik

Microsoft.PowerPlatform.EnterprisePolicies PowerShell-modulen hjälper dig att diagnostisera och felsöka problem som rör konfigurationer av virtuella nätverk i Power Platform. Du kan använda verktyget för att kontrollera anslutningen mellan din Power Platform-miljö och ditt virtuella nätverk. Du kan också använda den för att identifiera eventuella felkonfigurationer som kan orsaka problem. PowerShell-modulen för diagnostik är tillgänglig från PowerShell-galleriet och dess GitHub-lagringsplats, PowerPlatform-EnterprisePolicies.

Installera modulen

Om du vill installera PowerShell-modulen för diagnostik kör du följande PowerShell-kommando:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Kör diagnostikfunktionerna

När du har installerat modulen importerar du den till PowerShell-sessionen genom att köra följande kommando:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

Modulen innehåller flera funktioner för att diagnostisera och felsöka problem som är relaterade till konfigurationer av virtuella nätverk. Några av de viktigaste funktionerna är:

• Get-EnvironmentRegion: Hämtar regionen för den angivna Power Platform-miljön.
• Get-EnvironmentUsage: Innehåller information om användningen av den angivna Power Platform-miljön.
• Test-DnsResolution: Testar DNS-matchningen för det angivna domännamnet.
• Test-NetworkConnectivity: Testar nätverksanslutningen mellan Power Platform-miljön och målresursen.
• Test-TLSHandshake: Testar om en TLS-handskakning kan upprättas mellan Power Platform-miljön och målresursen.

En fullständig lista över tillgängliga funktioner i diagnostikmodulen finns i Modulen Microsoft.PowerPlatform.EnterprisePolicies.

Rapportera problem i diagnostikmodulen

Om du får problem när du kör diagnostikmodulen rapporterar du dem via GitHub-lagringsplatsen där modulen finns. Lagringsplatsen är tillgänglig på: PowerPlatform-EnterprisePolicies.

Om du vill rapportera ett problem går du till avsnittet Problem på lagringsplatsen och öppnar ett nytt problem. Ange detaljerad information om det problem som du stöter på. Inkludera eventuella felmeddelanden eller loggposter som kan vara till hjälp när du undersöker problemet. Ta inte med någon känslig information i rapporten.

Felsökning av vanliga problem

En miljö fungerar men en annan fungerar inte

Om allt är korrekt konfigurerat, men du fortfarande stöter på problem, använder du funktionen Get-EnvironmentRegion från PowerShell-diagnostikmodulen för att kontrollera om regionerna i dina Power Platform-miljöer är desamma. Kör följande kommando:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Om miljöerna finns i olika regioner och den ena fungerar men den andra inte gör det, finns problemet i konfigurationen av det virtuella nätverket för den misslyckade regionen. Om du vill se till att den fullständiga konfigurationen är korrekt konfigurerad kör du ytterligare diagnostikkommandon mot båda regionerna. Inkludera parametern -Region om du vill ange en region. Till exempel:

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

Din miljö tillhör ett specifikt power platform-geografiskt område. En Power Platform-region kan dock omfatta två Azure-regioner. Din miljö kan vara i båda regionerna, och den kan också automatiskt växla över mellan dem. För att säkerställa hög tillgänglighet och anslutning måste du därför konfigurera dina virtuella nätverk i båda Azure-regionerna som är associerade med din Power Platform-region. Information om hur Power Platform-regioner mappas till Azure-regioner som stöder funktioner för virtuella nätverk finns i Power Platform-regioner.

Värdnamnet hittades inte

Om du stöter på problem som påverkar värdnamnsmatchningen använder du funktionen Test-DnsResolution från PowerShell-diagnostikmodulen för att kontrollera om värdnamnet har lösts korrekt. Kör följande kommando:

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

Det här kommandot testar DNS-matchningen för det angivna värdnamnet i kontexten för din Power Platform-miljö. Begäran initieras från ditt delegerade undernät och försöker matcha värdnamnet med hjälp av den DNS-server som har konfigurerats för ditt virtuella nätverk. Om värdnamnet inte matchas korrekt kan du behöva kontrollera DNS-inställningarna för att kontrollera att värdnamnet är korrekt konfigurerat.

Begäran använder en offentlig IP-adress i stället för den privata IP-adressen

Om du stöter på problem där begäranden till en resurs använder en offentlig IP-adress i stället för den privata IP-adressen kan DNS-matchningen för resursens värdnamn returnera en offentlig IP-adress. Det här problemet kan påverka både Azure- och icke-Azure-resurser.

Icke-Azure-resurs utan en privat slutpunkt

Om en icke-Azure-resurs inte har någon privat slutpunkt, men du kan komma åt den från ditt virtuella nätverk, måste du konfigurera DNS-servern för att matcha resursens värdnamn till dess privata IP-adress. Lägg till en DNS A-post till din DNS-server som mappar resursens värdnamn till dess privata IP-adress.

• Om du använder en anpassad DNS-server, lägg till A-posten direkt på servern.
• Om du använder en Azure-tillhandahållen DNS skapar du en privat DNS-zon i Azure och länkar den till ditt virtuella nätverk. Lägg sedan till A-posten i den privata DNS-zonen.

Den här mappningen ser till att du får åtkomst till resursen via dess privata IP-adress.

Azure-resurs som har en privat slutpunkt

Om en Azure-resurs har en privat slutpunkt ska DNS-matchningen för resursens värdnamn returnera den privata IP-adress som är associerad med den privata slutpunkten. Om DNS-matchningen returnerar en offentlig IP-adress i stället kanske DNS-konfigurationen saknar poster. Följ de här stegen:

1. Kontrollera att det finns en privat DNS-zon för din resurstyp. Till exempel privatelink.database.windows.net för Azure SQL Database. Om den privata DNS-zonen inte finns skapar du en.
2. Kontrollera att den privata DNS-zonen är länkad till ditt virtuella nätverk. Om den privata DNS-zonen inte är länkad till ditt virtuella nätverk länkar du den.

När du har länkat den privata DNS-zonen till det virtuella nätverket bör resursens värdnamn matchas mot den privata IP-adress som är associerad med den privata slutpunkten.

Testa DNS-konfigurationsändringar

När du har uppdaterat DNS-konfigurationen använder du funktionen Test-DnsResolution från PowerShell-diagnostikmodulen för att kontrollera att värdnamnet matchar rätt privata IP-adress. Kör följande kommando:

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

Det går inte att ansluta till resursen

Om du får problem som påverkar anslutningen till en resurs använder du funktionen Test-NetworkConnectivity från PowerShell-diagnostikmodulen för att söka efter anslutning. Kör följande kommando:

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

Det här kommandot försöker upprätta en TCP-anslutning till det angivna målet och porten i samband med din Power Platform-miljö. Begäran initieras från ditt delegerade undernät och försöker ansluta till det angivna målet med hjälp av nätverkskonfigurationen från det virtuella nätverket. Om anslutningen misslyckas kan du behöva kontrollera nätverksinställningarna för att se till att målet kan nås från det virtuella nätverket. En lyckad anslutning anger att nätverksanslutningen finns mellan Power Platform-miljön och den angivna resursen.

Det går inte att upprätta en TLS-handskakning

Vissa brandväggar kan tillåta att TCP-anslutningar upprättas, men sedan blockerar de faktisk trafik till resursen (till exempel HTTPS). Även om funktionen Test-NetworkConnectivity anger nätverksanslutning garanterar den statusen därför inte att resursen är helt tillgänglig.

Använd funktionen Test-TLSHandshake för att diagnostisera varför en handskakning inte kan upprättas. Kör följande kommando:

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

Det här kommandot returnerar information som kan hjälpa dig att felsöka varför handskakningen misslyckades. Utdata innehåller certifikatet som servern presenterade, chiffersviten, protokollet och eventuella SSL-felbeskrivningar.

Anslutningen lyckades, men programmet fungerar fortfarande inte

Om anslutningstesterna lyckas, men du fortfarande har problem i ditt program, kontrollerar du inställningar och konfigurationer på programnivå:

1. Kontrollera att brandväggen tillåter åtkomst från det delegerade undernätet till resursen.
2. Kontrollera att certifikatet som resursen presenterar är allmänt betrott.
3. Kontrollera att inga autentiserings- eller auktoriseringsproblem förhindrar åtkomst till resursen.

Du kanske inte kan diagnostisera eller lösa problemet med hjälp av PowerShell-modulen för diagnostik. I det här fallet skapar du ett undernät utan delegering i ditt virtuella nätverk och distribuerar en virtuell dator (VM) i undernätet. Sedan kan du använda den virtuella datorn för att utföra ytterligare diagnostik- och felsökningssteg, till exempel kontrollera nätverkstrafik, analysera loggar och testa anslutning på programnivå.

Exempel på felsökningsscenarier

Möt Contoso LLC, ett multinationellt företag som har flera Power Platform-miljöer och virtuella nätverk i hela Europa, i Västeuropa och i Nordeuropa. Varje virtuellt nätverk har ett undernät som delegeras till Power Platform. Varje undernät är associerat med en företagsprincip som är länkad till Power Platform-miljön.

Följande scenarier visar hur Contoso använder de diagnostiska cmdletar som finns i föregående avsnitt för att felsöka anslutningsproblem som påverkar den här konfigurationen.

Ansluta till ett Azure Key Vault via en privat slutpunkt

Contoso vill att dess Power Platform-miljöer ska ansluta till nyckelvalvet via det virtuella nätverket och konfigurerar nyckelvalvet för att avvisa begäranden från det offentliga Internet. När Contoso försöker ansluta till nyckelvalvet från sin miljö avvisas anslutningen eftersom begäranden inte dirigeras korrekt. För att diagnostisera problemet använder Contoso följande felsökningssteg.

Först kör den Get-EnvironmentRegion för att kontrollera vilka undernätsbegäranden som skickas till:

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

Den returnerade regionen identifierar vilket virtuellt nätverk som ska undersökas. Om kommandot till exempel returnerar Västeuropa måste Contoso fokusera felsökningen på det virtuella nätverket i Västeuropa.

Contoso verifierar sedan att IP-adressen som returneras från DNS-matchningen av det fullständigt kvalificerade domännamnet för nyckelvalvet (FQDN) är en privat IP-adress. Eftersom företaget har miljöer i båda regionerna måste det testa DNS-matchning för varje region med hjälp av 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"

Om DNS-matchningen returnerar en offentlig IP-adress i stället för en privat IP-adress kanske den privata slutpunkten för nyckelvalvet inte är korrekt konfigurerad. Contoso måste kontrollera att:

1. Det finns en privat slutpunkt för nyckelvalvet och den är associerad med rätt virtuellt nätverk.
2. Det finns en privat DNS-zon för nyckelvalvet (till exempel privatelink.vaultcore.azure.net), och den är länkad till det virtuella nätverket.
3. Den privata DNS-zonen innehåller en A-post som mappar värdnamnet för nyckelvalvet till den privata IP-adressen för den privata slutpunkten.

När Contoso kör DNS-upplösningstestet för Västeuropa upptäcker företaget att kommandot returnerar en offentlig IP-adress. När företaget har undersökt konstaterar det att den privata DNS-zonen för nyckelvalvet inte var länkad till det virtuella nätverket i Västeuropa. När Contoso har länkat den privata DNS-zonen till det virtuella nätverket och kör testet igen returnerar DNS-matchningen rätt privat IP-adress.

När DNS-matchningen returnerar rätt privat IP-adress i båda regionerna är nästa steg att testa nätverksanslutningen till nyckelvalvet med hjälp av 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"

Om anslutningen misslyckas kan nätverkssäkerhetsgruppens regler (NSG) eller brandväggsinställningarna blockera trafik från det delegerade undernätet till nyckelvalvet. Contoso måste kontrollera om:

1. NSG-reglerna som är associerade med det delegerade undernätet tillåter utgående trafik på port 443.
2. Key Vault-brandväggen tillåter inkommande anslutningar från det delegerade undernätets IP-intervall.
3. Alla Azure Firewall eller nätverksvirtuella apparater i trafikvägen tillåter anslutningen.

I det här fallet upptäcker Contoso att nyckelvalvsbrandväggen inte har konfigurerats för att tillåta inkommande anslutningar från någon privat källa. När brandväggsinställningarna har uppdaterats för att tillåta anslutningar från det delegerade undernätet lyckas nätverksanslutningstestet och Power Platform-miljön kan ansluta till nyckelvalvet via det virtuella nätverket.

Ansluta till en webbserver som finns i ett lokalt nätverk

Contoso vill också att dess Power Platform-miljö ska ansluta till en webbserver som finns i det lokala nätverket. Webbservern är tillgänglig via företagets virtuella nätverk via en ExpressRoute-anslutning . När Contoso försöker ansluta till webbservern från sin Power Platform-miljö misslyckas anslutningen.

Även om DNS-matchningen returnerar rätt IP-adress och nätverksanslutningstestet lyckas kan Contoso fortfarande inte komma åt webbservern. För att diagnostisera det här problemet testar företaget TLS-handskakningen med hjälp av Test-TLSHandshake:

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

Om TLS-handskakningen misslyckas innehåller utdata information om certifikatet, chiffersviten och protokollet som användes. Contoso kan använda den här informationen för att identifiera eventuella problem med certifikat eller TLS-konfiguration. Kommandot utför en inledande analys av returnerade utdata och aviseringar om några grundläggande problem. Contoso kan dock analysera de fullständiga utdata för att undersöka problemet mer detaljerat.

I det här fallet upptäcker Contoso att TLS-handskakningen inte kan etableras eftersom certifikatet inte är betrott. När företaget har undersökt certifikatinformationen i kommandoutdata avgör det att webbservern använder ett självsignerat certifikat. Power Platform kräver offentligt betrodda certifikat för TLS-anslutningar. När Contoso har uppdaterat webbservern för att använda ett certifikat som har signerats av en offentligt betrodd certifikatutfärdare lyckas TLS-handskakningen och Power Platform-miljön kan ansluta till webbservern.

Mer information om certifikatutfärdare som är betrodda av Azure-tjänster finns i Information om Azure Certificate Authority.