Rozwiązywanie problemów z siecią wirtualną

Ten artykuł zawiera wskazówki dotyczące rozwiązywania typowych scenariuszy dla sieci wirtualnych na platformie Microsoft Power Platform. Artykuł koncentruje się na sposobie korzystania z modułu Microsoft.PowerPlatform.EnterprisePolicies programu PowerShell, aby ułatwić identyfikowanie i rozwiązywanie problemów związanych z konfiguracjami sieci wirtualnej.

Korzystanie z modułu diagnostyki programu PowerShell

Moduł Microsoft.PowerPlatform.EnterprisePolicies programu PowerShell ułatwia diagnozowanie i rozwiązywanie problemów związanych z konfiguracjami sieci wirtualnej na platformie Power Platform. Za pomocą tego narzędzia możesz sprawdzić łączność między środowiskiem platformy Power Platform i siecią wirtualną. Można go również użyć do identyfikowania wszelkich błędów konfiguracji, które mogą powodować problemy. Moduł diagnostyki programu PowerShell jest dostępny z galerii programu PowerShell i jego repozytorium GitHub PowerPlatform-EnterprisePolicies.

Instalowanie modułu

Aby zainstalować moduł diagnostyki programu PowerShell, uruchom następujące polecenie programu PowerShell:

Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies

Uruchamianie funkcji diagnostycznych

Po zainstalowaniu modułu zaimportuj go do sesji programu PowerShell, uruchamiając następujące polecenie:

Import-Module Microsoft.PowerPlatform.EnterprisePolicies

Moduł zawiera kilka funkcji do diagnozowania i rozwiązywania problemów związanych z konfiguracjami sieci wirtualnej. Niektóre z kluczowych funkcji to:

• Get-EnvironmentRegion: pobiera region określonego środowiska platformy Power Platform.
• Get-EnvironmentUsage: zawiera informacje o użyciu określonego środowiska platformy Power Platform.
• Test-DnsResolution: testuje rozwiązywanie DNS dla określonej nazwy domeny.
• Test-NetworkConnectivity: testuje łączność sieciową między środowiskiem platformy Power Platform i zasobem docelowym.
• Test-TLSHandshake: testuje, czy można ustanowić handshake protokołu TLS między środowiskiem Power Platform a zasobem docelowym.

Aby uzyskać pełną listę dostępnych funkcji w module diagnostycznym, zobacz Moduł Microsoft.PowerPlatform.EnterprisePolicies.

Zgłaszanie problemów w module diagnostycznym

Jeśli wystąpią problemy podczas uruchamiania modułu diagnostyki, zgłoś je za pośrednictwem repozytorium GitHub, w którym jest hostowany moduł. Repozytorium jest dostępne w witrynie PowerPlatform-EnterprisePolicies.

Aby zgłosić problem, przejdź do sekcji Problemy w repozytorium i otwórz nowy problem. Podaj szczegółowe informacje o napotkanych problemach. Dołącz wszelkie komunikaty o błędach lub wpisy dziennika, które mogą pomóc podczas badania problemu. Nie uwzględniaj żadnych poufnych informacji w raporcie.

Rozwiązywanie typowych problemów

Jedno środowisko działa, ale inne nie działa

Jeśli wszystko jest poprawnie skonfigurowane, ale nadal występują problemy, użyj funkcji Get-EnvironmentRegion z modułu diagnostyki programu PowerShell, aby sprawdzić, czy regiony środowisk platformy Power Platform są takie same. Uruchom następujące polecenie:

Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"

Jeśli środowiska znajdują się w różnych regionach, a jeden działa, ale drugi nie, problem dotyczy konfiguracji sieci wirtualnej dla regionu, w którym występuje awaria. Aby upewnić się, że pełna konfiguracja jest poprawnie skonfigurowana, uruchom dalsze polecenia diagnostyczne dla obu regionów. Aby określić region, dołącz -Region parametr . Przykład:

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

Środowisko należy do określonej lokalizacji geograficznej platformy Power Platform. Jednak region platformy Power Platform może obejmować dwa regiony świadczenia usługi Azure. Środowisko może znajdować się w dowolnym regionie i może również automatycznie przejść w tryb failover między nimi. W związku z tym, aby zapewnić wysoką dostępność i łączność, należy skonfigurować sieci wirtualne w obu regionach świadczenia usługi Azure skojarzonych z regionem platformy Power Platform. Aby dowiedzieć się, jak regiony platformy Power Platform są mapowane na regiony Azure, które obsługują funkcjonalność sieci wirtualnej, zobacz Regiony platformy Power Platform.

Nie można odnaleźć nazwy hosta

Jeśli wystąpią problemy wpływające na rozpoznawanie nazwy hosta, użyj funkcji Test-DnsResolution z modułu diagnostyki programu PowerShell, aby sprawdzić, czy nazwa hosta jest poprawnie rozpoznawana. Uruchom następujące polecenie:

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

To polecenie testuje rozpoznawanie DNS dla określonej nazwy hosta w kontekście środowiska Power Platform. Żądanie inicjuje się z delegowanej podsieci i próbuje rozpoznać nazwę hosta przy użyciu serwera DNS skonfigurowanego dla sieci wirtualnej. Jeśli nazwa hosta nie została poprawnie rozpoznana, może być konieczne sprawdzenie ustawień DNS, aby upewnić się, że nazwa hosta jest poprawnie skonfigurowana.

Ważne

Jeśli zauważysz, że konfiguracja dns jest niepoprawna i musisz zaktualizować ustawienia serwera DNS dla sieci wirtualnej, zobacz Czy mogę zaktualizować adres DNS mojej sieci wirtualnej po jej delegowaniu do "Microsoft.PowerPlatform/enterprisePolicies"?

Żądanie używa publicznego adresu IP zamiast prywatnego adresu IP

Problemy mogą wystąpić, jeśli żądania do zasobu używają publicznego adresu IP zamiast prywatnego; może to być spowodowane tym, że rozwiązywanie nazw DNS dla nazwy hosta zasobu zwraca publiczny adres IP. Ten problem może mieć wpływ zarówno na zasoby platformy Azure, jak i zasoby spoza platformy Azure.

Zasób spoza platformy Azure bez prywatnego punktu końcowego

Jeśli zasób spoza platformy Azure nie ma prywatnego punktu końcowego, ale możesz uzyskać do niego dostęp z sieci wirtualnej, musisz skonfigurować serwer DNS, aby rozpoznać nazwę hosta zasobu na jego prywatny adres IP. Dodaj rekord DNS A do serwera DNS, który mapuje nazwę hosta zasobu na jego prywatny adres IP:

• Jeśli używasz niestandardowego serwera DNS, dodaj rekord A bezpośrednio do serwera.
• Jeśli używasz usługi DNS dostępnej na platformie Azure, utwórz prywatną strefę DNS platformy Azure i połącz ją z siecią wirtualną. Następnie dodaj rekord A do prywatnej strefy DNS.

To mapowanie zapewnia dostęp do zasobu za pośrednictwem jego prywatnego adresu IP.

Zasób platformy Azure, który ma prywatny punkt końcowy

Jeśli zasób w Azure ma prywatny punkt końcowy, rozpoznawanie nazw DNS dla nazwy hosta zasobu powinno zwrócić prywatny adres IP powiązany z tym prywatnym punktem końcowym. Jeśli rozpoznawanie nazw DNS zwraca zamiast tego publiczny adres IP, konfiguracja DNS może nie zawierać rekordów. Wykonaj te kroki:

1. Sprawdź, czy dla danego typu zasobu istnieje prywatna strefa DNS. Na przykład privatelink.database.windows.net w przypadku usługi Azure SQL Database. Jeśli prywatna strefa DNS nie istnieje, utwórz strefę.
2. Sprawdź, czy prywatna strefa DNS jest połączona z siecią wirtualną. Jeśli prywatna strefa DNS nie jest połączona z siecią wirtualną, połącz ją.

Po połączeniu prywatnej strefy DNS z siecią wirtualną nazwa hosta zasobu powinna zostać rozpoznana jako prywatny adres IP skojarzony z prywatnym punktem końcowym.

Testowanie zmian konfiguracji DNS

Po zaktualizowaniu konfiguracji DNS użyj funkcji Test-DnsResolution z modułu diagnostyki programu PowerShell, aby sprawdzić, czy nazwa hosta jest rozpoznawana jako prawidłowy prywatny adres IP. Uruchom następujące polecenie:

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

Nie można nawiązać połączenia z zasobem

Jeśli wystąpią problemy wpływające na łączność z zasobem, użyj funkcji Test-NetworkConnectivity z modułu diagnostyki programu PowerShell, aby sprawdzić łączność. Uruchom następujące polecenie:

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

To polecenie próbuje ustanowić połączenie TCP z określonym miejscem docelowym i portem w kontekście środowiska platformy Power Platform. Żądanie inicjuje się z delegowanej podsieci i próbuje nawiązać połączenie z określonym miejscem docelowym przy użyciu konfiguracji sieci z sieci wirtualnej. Jeśli połączenie nie powiedzie się, może być konieczne sprawdzenie ustawień sieci, aby upewnić się, że miejsce docelowe jest osiągalne z sieci wirtualnej. Pomyślne połączenie wskazuje, że łączność sieciowa istnieje między środowiskiem platformy Power Platform a określonym zasobem.

Uwaga / Notatka

To polecenie sprawdza tylko, czy można ustanowić połączenie TCP z określonym miejscem docelowym i portem. Nie sprawdza, czy zasób jest dostępny, czy też jakiekolwiek problemy na poziomie aplikacji mogą uniemożliwiać dostęp do zasobu.

Nie można ustanowić połączenia TLS

Niektóre zapory mogą zezwalać na nawiązywanie połączeń TCP, ale następnie blokują rzeczywisty ruch do zasobu (na przykład HTTPS). W związku z tym nawet jeśli funkcja Test-NetworkConnectivity wskazuje łączność sieciową, ten stan nie gwarantuje, że zasób jest w pełni dostępny.

Użyj funkcji Test-TLSHandshake, aby zdiagnozować, dlaczego nie można ustanowić handshake'u. Uruchom następujące polecenie:

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

To polecenie zwraca informacje, które mogą pomóc w debugowaniu przyczyny niepowodzenia uzgadniania. Dane wyjściowe obejmują certyfikat przedstawiony przez serwer, zestaw szyfrowania, protokół i opisy błędów SSL.

Ważne

Obsługiwane są tylko publicznie zaufane certyfikaty. Aby uzyskać więcej informacji, zobacz Czy obsługujesz nieznane certyfikaty?

Łączność zakończyła się pomyślnie, ale aplikacja nadal nie działa

Jeśli testy łączności zakończyły się pomyślnie, ale nadal występują problemy w aplikacji, sprawdź ustawienia i konfiguracje na poziomie aplikacji:

1. Sprawdź, czy zapora zezwala na dostęp z delegowanej podsieci do zasobu.
2. Sprawdź, czy certyfikat, który przedstawia zasób, jest publicznie zaufany.
3. Upewnij się, że żadne problemy z uwierzytelnianiem lub autoryzacją nie uniemożliwiają dostępu do zasobu.

Być może nie możesz zdiagnozować lub rozwiązać problemu przy użyciu modułu diagnostyki programu PowerShell. W takim przypadku utwórz podsieć bez delegowania w sieci wirtualnej i wdróż maszynę wirtualną w tej podsieci. Następnie możesz użyć maszyny wirtualnej do wykonania dalszych kroków diagnostycznych i rozwiązywania problemów, takich jak sprawdzanie ruchu sieciowego, analizowanie dzienników i testowanie łączności na poziomie aplikacji.

Przykładowe scenariusze rozwiązywania problemów

Poznaj contoso LLC, wielonarodową firmę, która ma wiele środowisk platformy Power Platform w całej Europie oraz sieci wirtualne w regionie Europa Zachodnia i Europa Północna. Każda sieć wirtualna ma podsieć delegowana do platformy Power Platform. Każda podsieć jest skojarzona z zasadami przedsiębiorstwa połączonymi ze środowiskiem platformy Power Platform.

W poniższych scenariuszach pokazano, jak firma Contoso używa poleceń cmdlet diagnostycznych dostępnych w poprzednich sekcjach, aby rozwiązać problemy z łącznością, które mają wpływ na tę konfigurację.

Nawiązywanie połączenia z usługą Azure Key Vault za pośrednictwem prywatnego punktu końcowego

Firma Contoso chce, aby jej środowiska platformy Power Platform łączyły się z magazynem kluczy za pośrednictwem sieci wirtualnej i konfiguruje magazyn kluczy pod kątem odrzucania żądań z publicznego Internetu. Gdy firma Contoso próbuje nawiązać połączenie z magazynem kluczy ze swojego środowiska, połączenie zostanie odrzucone, ponieważ żądania nie są prawidłowo kierowane. Aby zdiagnozować problem, firma Contoso korzysta z poniższych kroków rozwiązywania problemów.

Najpierw uruchamia polecenie Get-EnvironmentRegion , aby sprawdzić, które żądania podsieci są wysyłane do:

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

Zwrócony region wskazuje, którą sieć wirtualną należy zbadać. Jeśli na przykład polecenie zwraca region Europa Zachodnia, firma Contoso musi skoncentrować się na rozwiązywaniu problemów z siecią wirtualną Europa Zachodnia.

Następnie przedstawiciel firmy Contoso sprawdza, czy adres IP, zwracany po rozpoznaniu przez DNS w pełni kwalifikowanej nazwy domeny skarbca kluczy (FQDN), jest prywatnym adresem IP. Ponieważ firma ma środowiska w obu regionach, musi przetestować rozwiązywanie nazw DNS dla każdego regionu przy użyciu 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"

Jeśli rozwiązywanie DNS zwraca publiczny adres IP zamiast prywatnego adresu IP, prywatny punkt końcowy skarbca kluczy może nie być poprawnie skonfigurowany. Firma Contoso musi sprawdzić, czy:

1. Prywatny punkt końcowy istnieje dla Key Vault i jest powiązany z poprawną siecią wirtualną.
2. Istnieje prywatna strefa DNS dla usługi Key Vault (na przykład privatelink.vaultcore.azure.net), która jest połączona z siecią wirtualną.
3. Prywatna strefa DNS zawiera rekord A, który odwzorowuje nazwę hosta skarbca kluczy na prywatny adres IP prywatnego punktu końcowego.

Gdy firma Contoso uruchamia test rozpoznawania nazw DNS dla Europy Zachodniej, firma wykryje, że polecenie zwraca publiczny adres IP. Po przeprowadzeniu dochodzenia firma stwierdza, że prywatna strefa DNS magazynu kluczy nie była połączona z wirtualną siecią Zachodniej Europy. Gdy firma Contoso łączy prywatną strefę DNS z siecią wirtualną i ponownie uruchamia test, rozpoznawanie nazw DNS zwraca prawidłowy prywatny adres IP.

Gdy rozpoznawanie nazw DNS zwróci prawidłowy prywatny adres IP w obu regionach, następnym krokiem jest przetestowanie łączności sieciowej z magazynem kluczy przy użyciu 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"

Jeśli połączenie się nie powiedzie, reguły grupy zabezpieczeń sieciowych (NSG) lub ustawienia zapory mogą blokować ruch z delegowanej podsieci do przechowalni kluczy. Firma Contoso musi sprawdzić, czy:

1. Reguły NSG skojarzone z delegowaną podsiecią zezwalają na ruch wychodzący na porcie 443.
2. Zapora magazynu kluczy zezwala na połączenia przychodzące z zakresu adresów IP delegowanej podsieci.
3. Dowolna usługa Azure Firewall lub wirtualne urządzenie sieciowe w ścieżce ruchu zezwala na połączenie.

W takim przypadku firma Contoso stwierdza, że zapora magazynu kluczy nie została skonfigurowana tak, aby zezwalała na połączenia przychodzące z żadnego źródła prywatnego. Po zaktualizowaniu ustawień zapory, aby umożliwić połączenia z przypisanej podsieci, test łączności sieciowej kończy się pomyślnie. Dzięki temu środowisko Power Platform może skutecznie nawiązać połączenie z magazynem kluczy za pośrednictwem sieci wirtualnej.

Nawiązywanie połączenia z serwerem internetowym hostowanym w sieci lokalnej

Firma Contoso chce również, aby środowisko platformy Power Platform łączyło się z serwerem internetowym hostowanym w sieci lokalnej. Serwer internetowy jest dostępny za pośrednictwem wirtualnej sieci firmy przy użyciu połączenia ExpressRoute. Gdy firma Contoso próbuje nawiązać połączenie z serwerem internetowym ze środowiska platformy Power Platform, połączenie nie powiedzie się.

Mimo że rozpoznawanie nazw DNS zwraca prawidłowy adres IP i test łączności sieciowej zakończy się pomyślnie, firma Contoso nadal nie może uzyskać dostępu do serwera internetowego. Aby zdiagnozować ten problem, firma testuje uzgadnianie protokołu TLS przy użyciu polecenia Test-TLSHandshake:

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

Jeśli uzgadnianie protokołu TLS zakończy się niepowodzeniem, dane wyjściowe zawierają szczegółowe informacje o certyfikacie, zestawie szyfrowania i używanym protokole. Firma Contoso może używać tych informacji do identyfikowania problemów z konfiguracją certyfikatu lub protokołu TLS. Polecenie wykonuje początkową analizę zwróconych danych wyjściowych i alerty dotyczące niektórych podstawowych problemów. Firma Contoso może jednak przeanalizować pełne dane wyjściowe, aby dokładniej zbadać problem.

W takim przypadku firma Contoso wykrywa, że nie można ustanowić uzgadniania protokołu TLS, ponieważ certyfikat nie jest zaufany. Gdy firma zbada szczegóły certyfikatu w danych wyjściowych polecenia, określa, że serwer internetowy korzysta z certyfikatu z podpisem własnym. Platforma Power Platform wymaga publicznie zaufanych certyfikatów dla połączeń TLS. Po zaktualizowaniu serwera internetowego firmy Contoso do używania certyfikatu podpisanego przez publicznie zaufany urząd certyfikacji, negocjacja TLS zakończy się powodzeniem, co umożliwi środowisku Power Platform nawiązanie połączenia z serwerem internetowym.

Aby uzyskać więcej informacji na temat urzędów certyfikacji zaufanych przez usługi platformy Azure, zobacz Szczegóły urzędu certyfikacji platformy Azure.