Rozwiązywanie problemów z integracją sieci wirtualnej z usługą Azure App Service

W tym artykule opisano narzędzia, których można użyć do rozwiązywania problemów z połączeniem w Azure App Service, które integrują się z siecią wirtualną.

Uwaga

Integracja sieci wirtualnej nie jest obsługiwana w scenariuszach tworzenia platformy Docker w App Service. Zasady ograniczeń dostępu są ignorowane, jeśli istnieje prywatny punkt końcowy.

Weryfikowanie integracji sieci wirtualnej

Aby rozwiązać problemy z połączeniem, należy najpierw sprawdzić, czy integracja sieci wirtualnej jest poprawnie skonfigurowana i czy prywatny adres IP jest przypisany do wszystkich wystąpień planu App Service.

Aby to zrobić, użyj jednej z następujących metod:

Sprawdzanie prywatnego adresu IP w konsoli debugowania Kudu

Aby uzyskać dostęp do konsoli Kudu, wybierz usługę aplikacji w Azure Portal, przejdź do obszaru Narzędzia programistyczne, wybierz pozycję Narzędzia zaawansowane, a następnie wybierz pozycję Przejdź. Na stronie usługi Kudu wybierz pozycję Narzędzia>Debugowanie konsoli>CMD.

Możesz również przejść do konsoli debugowania Kudu bezpośrednio za pomocą adresu URL [sitename].scm.azurewebsites.net/DebugConsole.

W konsoli debugowania uruchom jedno z następujących poleceń:

Aplikacje oparte na systemie operacyjnym Windows

SET WEBSITE_PRIVATE_IP

Jeśli prywatny adres IP zostanie pomyślnie przypisany, otrzymasz następujące dane wyjściowe:

WEBSITE_PRIVATE_IP=<IP address>

Aplikacje oparte na systemie operacyjnym Linux

set| egrep --color 'WEBSITE_PRIVATE_IP'

Sprawdzanie prywatnego adresu IP w środowisku Kudu

Przejdź do środowiska Kudu pod adresem [sitename].scm.azurewebsites.net/Env i wyszukaj WEBSITE_PRIVATE_IPciąg .

Po pomyślnym skonfigurowaniu integracji sieci wirtualnej możemy przystąpić do testu łączności.

Rozwiązywanie problemów z łącznością wychodzącą w usłudze Windows Apps

W natywnych aplikacjach systemu Windows narzędzia ping, nslookup i tracert nie będą działać przez konsolę z powodu ograniczeń zabezpieczeń (działają w niestandardowych kontenerach systemu Windows).

Przejdź do konsoli Kudu bezpośrednio pod adresem [sitename].scm.azurewebsites.net/DebugConsole.

Aby przetestować funkcje DNS, możesz użyć nameresolver.exe. Składnia to:

nameresolver.exe hostname [optional:DNS Server]

Możesz użyć elementu nameresolver , aby sprawdzić nazwy hostów, od których zależy aplikacja. W ten sposób możesz sprawdzić, czy masz coś nieprawidłowo skonfigurowanego z systemem DNS lub być może nie masz dostępu do serwera DNS. Serwer DNS używany przez aplikację w konsoli programu można wyświetlić, przeglądając zmienne środowiskowe WEBSITE_DNS_SERVER i WEBSITE_DNS_ALT_SERVER.

Uwaga

Narzędzie nameresolver.exe obecnie nie działa w niestandardowych kontenerach systemu Windows.

Aby przetestować łączność TCP z połączeniem hosta i portu, można użyć protokołu tcpping. Składnia to.

tcpping.exe hostname [optional: port]

Narzędzie tcpping informuje, czy można uzyskać dostęp do określonego hosta i portu. Powodzenie może być widoczne tylko wtedy, gdy aplikacja nasłuchuje kombinacji hosta i portu, a aplikacja ma dostęp do sieci do określonego hosta i portu.

Rozwiązywanie problemów z łącznością wychodzącą w usłudze Linux Apps

Przejdź do usługi Kudu bezpośrednio pod adresem [sitename].scm.azurewebsites.net. Na stronie usługi Kudu wybierz pozycję Narzędzia>Debugowanie konsoli>CMD.

Aby przetestować funkcjonalność DNS, możesz użyć polecenia nslookup. Składnia to:

nslookup hostname [optional:DNS Server]

W zależności od powyższych wyników możesz sprawdzić, czy na serwerze DNS wystąpił błąd konfiguracji.

Uwaga

Narzędzie nameresolver.exe obecnie nie działa w aplikacjach systemu Linux.

Aby przetestować łączność, możesz użyć polecenia Curl . Składnia to:

curl -v https://hostname
curl hostname:[port]

Debugowanie dostępu do zasobów hostowanych w sieci wirtualnej

Wiele czynników może uniemożliwić aplikacji dotarcie do określonego hosta i portu. W większości przypadków jest to jeden z następujących elementów:

• Zapora jest w drodze. Jeśli masz zaporę w drodze, zostanie osiągnięty limit czasu TCP. W tym przypadku limit czasu protokołu TCP wynosi 21 sekund. Użyj narzędzia tcpping , aby przetestować łączność. Przekroczenia limitu czasu protokołu TCP mogą być spowodowane wieloma elementami poza zaporami, ale zaczynają się tam.
• System DNS nie jest dostępny. Limit czasu DNS wynosi trzy sekundy na serwer DNS. Jeśli masz dwa serwery DNS, limit czasu wynosi sześć sekund. Użyj elementu nameresolver, aby sprawdzić, czy system DNS działa. Nie można użyć narzędzia nslookup, ponieważ nie używa on systemu DNS, z którego skonfigurowano sieć wirtualną. Jeśli jest niedostępny, zapora lub sieciowa grupa zabezpieczeń blokuje dostęp do systemu DNS lub może być wyłączona. Niektóre architektury DNS korzystające z niestandardowych serwerów DNS mogą być złożone i czasami mogą wystąpić przekroczenia limitu czasu. Aby ustalić, czy tak jest, można ustawić zmienną WEBSITE_DNS_ATTEMPTS środowiskową. Aby uzyskać więcej informacji na temat systemu DNS w usłudze App Services, zobacz Rozpoznawanie nazw (DNS) w App Service.

Jeśli te elementy nie odpowiadają na twoje problemy, poszukaj najpierw następujących elementów:

Integracja regionalnej sieci wirtualnej

• Czy miejsce docelowe jest adresem innym niż RFC1918 i nie masz włączonej opcji Route All ?
• Czy sieciowa grupa zabezpieczeń blokuje ruch wychodzący z podsieci integracji?
• Czy brama lokalna jest skonfigurowana do kierowania ruchu z powrotem do platformy Azure, jeśli przechodzisz przez usługę Azure ExpressRoute lub sieć VPN? Jeśli możesz dotrzeć do punktów końcowych w sieci wirtualnej, ale nie lokalnie, sprawdź trasy.
• Czy masz wystarczające uprawnienia, aby ustawić delegowanie w podsieci integracji? Podczas regionalnej konfiguracji integracji sieci wirtualnej podsieć integracji jest delegowana do witryny Microsoft.Web/serverFarms. Interfejs użytkownika integracji sieci wirtualnej automatycznie deleguje podsieć do witryny Microsoft.Web/serverFarms. Jeśli Twoje konto nie ma wystarczających uprawnień sieciowych do ustawienia delegowania, do delegowania podsieci będzie potrzebna osoba, która może ustawić atrybuty w podsieci integracji. Aby ręcznie delegować podsieć integracji, przejdź do interfejsu użytkownika podsieci usługi Azure Virtual Network i ustaw delegowanie dla witryny Microsoft.Web/serverFarms.

Debugowanie problemów z siecią jest wyzwaniem, ponieważ nie widać, co blokuje dostęp do określonej kombinacji host:port. Niektóre przyczyny to:

• Na hoście znajduje się zapora, która uniemożliwia dostęp do portu aplikacji z zakresu adresów IP typu punkt-lokacja. Przekraczanie podsieci często wymaga publicznego dostępu.
• Host docelowy nie działa.
• Aplikacja nie działa.
• Miałeś nieprawidłowy adres IP lub nazwę hosta.
• Aplikacja nasłuchuje na innym porcie niż oczekiwano. Identyfikator procesu można dopasować do portu nasłuchiwania przy użyciu polecenia "netstat -aon" na hoście punktu końcowego.
• Sieciowe grupy zabezpieczeń są skonfigurowane w taki sposób, aby uniemożliwiały dostęp do hosta aplikacji i portu z zakresu adresów IP typu punkt-lokacja.

Nie wiesz, jakiego adresu aplikacja faktycznie używa. Może to być dowolny adres w podsieci integracji lub w zakresie adresów punkt-lokacja, więc musisz zezwolić na dostęp z całego zakresu adresów.

Więcej kroków debugowania to:

• Połącz się z maszyną wirtualną w sieci wirtualnej i spróbuj nawiązać połączenie z hostem zasobu:portem. Aby przetestować dostęp TCP, użyj polecenia programu PowerShell Test-NetConnection. Składnia to:

Test-NetConnection hostname [optional: -Port]

• Uruchom aplikację na maszynie wirtualnej i przetestuj dostęp do tego hosta i portu z poziomu konsoli aplikacji przy użyciu protokołu tcpping.

Narzędzie do rozwiązywania problemów z siecią

Możesz również użyć narzędzia do rozwiązywania problemów z siecią, aby rozwiązać problemy z połączeniem dla aplikacji w App Service. Aby otworzyć narzędzie do rozwiązywania problemów z siecią, przejdź do usługi app service w Azure Portal. Wybierz pozycję Diagnostyka i rozwiąż problem, a następnie wyszukaj narzędzie do rozwiązywania problemów z siecią.

Uwaga

Scenariusz problemów z połączeniem nie obsługuje jeszcze aplikacji opartych na systemie Linux ani kontenerze.

Problemy z połączeniem — sprawdza stan integracji sieci wirtualnej, w tym sprawdza, czy prywatny adres IP został przypisany do wszystkich wystąpień planu App Service i ustawień DNS. Jeśli niestandardowy system DNS nie jest skonfigurowany, zostanie zastosowana domyślna usługa Azure DNS. Można również uruchamiać testy dla określonego punktu końcowego, z który chcesz przetestować łączność.

Problemy z konfiguracją — to narzędzie do rozwiązywania problemów sprawdzi, czy podsieć jest prawidłowa dla integracji z siecią wirtualną.

Problem z usuwaniem podsieci/sieci wirtualnej — to narzędzie do rozwiązywania problemów sprawdzi, czy podsieć ma jakiekolwiek blokady i czy ma nieużywane łącza skojarzenia usługi, które mogą blokować usunięcie sieci wirtualnej/podsieci.

Zbieranie śladów sieci

Zbieranie śladów sieci może być pomocne w analizowaniu problemów. W usłudze aplikacja systemu Azure Services dane śledzenia sieci są pobierane z procesu aplikacji. Aby uzyskać dokładne informacje, odtwórz problem podczas uruchamiania kolekcji śledzenia sieci.

Uwaga

Ruch sieci wirtualnej nie jest przechwytywany w śladach sieci.

Windows App Services

Aby zebrać ślady sieci dla usług Windows App Services, wykonaj następujące kroki:

1. W Azure Portal przejdź do aplikacji internetowej.
2. W obszarze nawigacji po lewej stronie wybierz pozycję Diagnozuj i rozwiąż problemy.
3. W polu wyszukiwania wpisz Collect Network Trace (Zbierz ślad sieci ) i wybierz pozycję Collect Network Trace (Zbierz ślad sieci ), aby uruchomić zbieranie śledzenia sieci.

Aby pobrać plik śledzenia dla każdego wystąpienia obsługującego aplikację internetową, w przeglądarce przejdź do konsoli Kudu dla aplikacji internetowej (https://<sitename>.scm.azurewebsites.net). Pobierz plik śledzenia z folderu C:\home\LogFiles\networktrace lub D:\home\LogFiles\networktrace .

Linux App Services

Aby zebrać ślady sieci dla usług App Services systemu Linux, które nie używają kontenera niestandardowego, wykonaj następujące kroki:

1. Zainstaluj narzędzie wiersza polecenia, tcpdump uruchamiając następujące polecenia:

   apt-get update
   apt install tcpdump
   

2. Połącz się z kontenerem za pośrednictwem protokołu SSH (Secure Shell Protocol).

3. Zidentyfikuj interfejs, który jest uruchomiony, uruchamiając następujące polecenie (na przykład eth0):

   root@<hostname>:/home# tcpdump -D
   
   1.eth0 [Up, Running, Connected]
   2.any (Pseudo-device that captures on all interfaces) [Up, Running]
   3.lo [Up, Running, Loopback]
   4.bluetooth-monitor (Bluetooth Linux Monitor) [Wireless]
   5.nflog (Linux netfilter log (NFLOG) interface) [none]
   6.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
   7.dbus-system (D-Bus system bus) [none]
   8.dbus-session (D-Bus session bus) [none]
   

4. Uruchom kolekcję śledzenia sieci, uruchamiając następujące polecenie:

   root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap
   

   Zastąp eth0 ciąg nazwą rzeczywistego interfejsu.

Aby pobrać plik śledzenia, połącz się z aplikacją internetową za pomocą metod, takich jak Kudu, FTP lub żądanie interfejsu API Kudu. Oto przykład żądania wyzwalania pobierania pliku:

https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename

Zastrzeżenie dotyczące innych firm

Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.