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 usłudze aplikacja systemu Azure, które integrują się z siecią wirtualną.
Uwaga 16.
Integracja sieci wirtualnej nie jest obsługiwana w scenariuszach narzędzia Docker Compose w usłudze 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 usługi App Service.
W tym celu użyj jednej z następujących metod:
Sprawdź prywatny adres IP w konsoli debugowania Kudu
Aby uzyskać dostęp do konsoli Kudu, wybierz usługę app service w witrynie Azure Portal, przejdź do pozycji Narzędzia programistyczne, wybierz pozycję Narzędzia zaawansowane, a następnie wybierz pozycję Przejdź. Na stronie usługi Kudu wybierz pozycję Narzędzia>Konsola>debugowania CMD.
Możesz również przejść do konsoli debugowania Kudu bezpośrednio pod adresem 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, uzyskasz 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 ciąg WEBSITE_PRIVATE_IP
.
Po ustaleniu, że integracja sieci wirtualnej została pomyślnie skonfigurowana, możemy przejść do testu łączności.
Rozwiązywanie problemów z łącznością wychodzącą w aplikacjach systemu Windows
W natywnych aplikacjach systemu Windows narzędzia ping, nslookup i tracert nie będą działać za pośrednictwem konsoli 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żna użyć nameresolver.exe. Składnia jest następująca:
nameresolver.exe hostname [optional:DNS Server]
Możesz użyć metody nameresolver , aby sprawdzić nazwy hostów, od których zależy aplikacja. W ten sposób można sprawdzić, czy w systemie DNS nie skonfigurowano niczego błędnie lub 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 16.
Narzędzie nameresolver.exe obecnie nie działa w niestandardowych kontenerach systemu Windows.
Aby przetestować łączność TCP z hostem i kombinacją portów, można użyć 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. Może ona pokazać powodzenie tylko wtedy, gdy aplikacja nasłuchuje na hoście i połączeniu portów, a dostęp sieciowy z aplikacji do określonego hosta i portu.
Rozwiązywanie problemów z łącznością wychodzącą w aplikacjach systemu Linux
Przejdź do usługi Kudu bezpośrednio pod adresem [sitename].scm.azurewebsites.net
. Na stronie usługi Kudu wybierz pozycję Narzędzia>Konsola>debugowania CMD.
Aby przetestować funkcje DNS, możesz użyć polecenia nslookup. Składnia jest następująca:
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 16.
Narzędzie nameresolver.exe obecnie nie działa w aplikacjach systemu Linux.
Aby przetestować łączność, możesz użyć polecenia Curl . Składnia jest następująca:
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 jedna z następujących czynności:
- Zapora jest w ten sposób. Jeśli masz zaporę w taki sposób, przekroczono limit czasu protokołu TCP. Limit czasu protokołu TCP wynosi 21 sekund w tym przypadku. Użyj narzędzia tcpping, aby przetestować łączność. Przekroczenia limitu czasu protokołu TCP mogą być spowodowane przez wiele elementów poza zaporami, ale zacznij 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 nazwyresolver, aby sprawdzić, czy system DNS działa. Nie można użyć polecenia nslookup, ponieważ nie używa on systemu DNS, z którym skonfigurowano sieć wirtualną. Jeśli jest niedostępna, być może 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 występują przekroczenia limitu czasu. Aby określić, czy tak jest, można ustawić zmienną środowiskową
WEBSITE_DNS_ATTEMPTS
. Aby uzyskać więcej informacji na temat systemu DNS w usłudze App Services, zobacz Rozpoznawanie nazw (DNS) w usłudze App Service.
Jeśli te elementy nie odpowiadają na problemy, najpierw poszukaj takich elementów jak:
Regionalna integracja sieci wirtualnej
- Czy miejsce docelowe jest adresem nienależące do RFC1918 i nie masz włączonej opcji Route All ?
- Czy sieciowa grupa zabezpieczeń blokuje ruch wychodzący z podsieci integracji?
- Jeśli korzystasz z usługi Azure ExpressRoute lub sieci VPN, czy brama lokalna jest skonfigurowana do kierowania ruchu z powrotem na platformę Azure? Jeśli możesz uzyskać dostęp 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 konfiguracji integracji regionalnej sieci wirtualnej podsieć integracji jest delegowana do domeny Microsoft.Web/serverFarms. Interfejs użytkownika integracji sieci wirtualnej deleguje podsieć do aplikacji Microsoft.Web/serverFarms automatycznie. Jeśli Twoje konto nie ma wystarczających uprawnień sieciowych do ustawiania delegowania, musisz mieć osobę, która może ustawić atrybuty w podsieci integracji, aby delegować podsieć. Aby ręcznie delegować podsieć integracji, przejdź do interfejsu użytkownika podsieci usługi Azure Virtual Network i ustaw delegowanie dla aplikacji Microsoft.Web/serverFarms.
Debugowanie problemów z siecią jest wyzwaniem, ponieważ nie można zobaczyć, co blokuje dostęp do konkretnej kombinacji host:port. Niektóre przyczyny to:
- Masz zaporę na hoście, która uniemożliwia dostęp do portu aplikacji z zakresu adresów IP punkt-lokacja. Przekraczanie podsieci często wymaga dostępu publicznego.
- Host docelowy nie działa.
- Aplikacja nie działa.
- Wystąpił nieprawidłowy adres IP lub nazwa 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ą konfigurowane w taki sposób, aby uniemożliwiły dostęp do hosta aplikacji i portu z zakresu adresów IP punkt-lokacja.
Nie wiesz, jakiego adresu używa aplikacja. Może to być dowolny adres w podsieci integracji lub zakres adresów punkt-lokacja, więc musisz zezwolić na dostęp z całego zakresu adresów.
Więcej kroków debugowania obejmuje:
- Połącz się z maszyną wirtualną w sieci wirtualnej i spróbuj nawiązać połączenie z hostem zasobu:portem. Aby przetestować dostęp do protokołu TCP, użyj polecenia programu PowerShell Test-NetConnection. Składnia jest następująca:
Test-NetConnection hostname [optional: -Port]
- Utwórz aplikację na maszynie wirtualnej i przetestuj dostęp do tego hosta i portu z konsoli aplikacji przy użyciu protokołu tcpping.
Narzędzie do rozwiązywania problemów z siecią
Narzędzie do rozwiązywania problemów z siecią umożliwia również rozwiązywanie problemów z połączeniem aplikacji w usłudze App Service. Aby otworzyć narzędzie do rozwiązywania problemów z siecią, przejdź do usługi app service w witrynie Azure Portal. Wybierz pozycję Diagnostyka i rozwiąż problem, a następnie wyszukaj narzędzie do rozwiązywania problemów z siecią.
Uwaga 16.
Scenariusz problemów z połączeniem nie obsługuje jeszcze aplikacji opartych na systemie Linux ani kontenerach.
Problemy z połączeniem — sprawdza stan integracji sieci wirtualnej, w tym sprawdza, czy prywatny adres IP został przypisany do wszystkich wystąpień planu usługi 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 względem określonego punktu końcowego, z którym chcesz przetestować łączność.
Problemy z konfiguracją — to narzędzie do rozwiązywania problemów sprawdzi, czy podsieć jest prawidłowa w przypadku 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 skojarzeń usługi, które mogą blokować usunięcie sieci wirtualnej/podsieci.
Zbieranie śladów sieci
Zbieranie śladów sieci może być przydatne podczas analizowania problemów. W usługach aplikacja systemu Azure dane śledzenia sieci są pobierane z procesu aplikacji. Aby uzyskać dokładne informacje, odtwórz problem podczas uruchamiania kolekcji śledzenia sieci.
Uwaga 16.
Ruch sieci wirtualnej nie jest przechwytywany w śladach sieci.
Windows App Services
Aby zebrać dane śledzenia sieci dla usługi Windows App Services, wykonaj następujące kroki:
- W witrynie Azure Portal przejdź do aplikacji internetowej.
- W obszarze nawigacji po lewej stronie wybierz pozycję Diagnozowanie i rozwiązywanie problemów.
- W polu wyszukiwania wpisz Collect Network Trace (Zbierz ślad sieci) i wybierz pozycję Collect Network Trace (Zbierz ślad sieci), aby rozpocząć zbieranie śladów sieci.
Aby uzyskać 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 zbierać dane śledzenia sieci dla usług App Services systemu Linux, które nie korzystają z niestandardowego kontenera, wykonaj następujące kroki:
tcpdump
Zainstaluj narzędzie wiersza polecenia, uruchamiając następujące polecenia:apt-get update apt install tcpdump
Nawiąż połączenie z kontenerem za pośrednictwem protokołu Secure Shell Protocol (SSH).
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]
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 na temat platformy Azure.