Dela via

Felsöka integrering av virtuella nätverk med Azure App Service

  • Artikel

I den här artikeln beskrivs verktyg som du kan använda för att felsöka anslutningsproblem i Azure App Service som integreras med ett virtuellt nätverk.

Obs!

Integrering av virtuella nätverk stöds inte för Docker Compose-scenarier i App Service. Principer för åtkomstbegränsning ignoreras om det finns en privat slutpunkt.

Verifiera integrering av virtuellt nätverk

Om du vill felsöka anslutningsproblemen måste du först kontrollera om integreringen av det virtuella nätverket är korrekt konfigurerad och om den privata IP-adressen har tilldelats till alla instanser av App Service-planen.

Använd någon av följande metoder för att göra detta:

Kontrollera den privata IP-adressen i Kudu-felsökningskonsolen

Om du vill komma åt Kudu-konsolen väljer du apptjänsten i Azure Portal, går till Utvecklingsverktyg, väljer Avancerade verktyg och väljer sedan Gå. På sidan Kudu-tjänst väljer du Verktyg>Felsökningskonsol-CMD>.

Skärmbild som visar hur du öppnar Kudu-tjänstsidan i Azure Portal.

Du kan också gå till Kudu-felsökningskonsolen direkt via URL:en [sitename].scm.azurewebsites.net/DebugConsole.

Kör något av följande kommandon i felsökningskonsolen:

Windows OS-baserade appar

SET WEBSITE_PRIVATE_IP

Om den privata IP-adressen har tilldelats får du följande utdata:

WEBSITE_PRIVATE_IP=<IP address>

Linux OS-baserade appar

set| egrep --color 'WEBSITE_PRIVATE_IP'

Kontrollera den privata IP-adressen i Kudu-miljön

Gå till Kudu-miljön på [sitename].scm.azurewebsites.net/Env och sök WEBSITE_PRIVATE_IPefter .

När vi har fastställt att integreringen av det virtuella nätverket har konfigurerats kan vi fortsätta med anslutningstestet.

Felsöka utgående anslutningar i Windows Apps

I interna Windows-appar fungerar inte verktygen ping, nslookup och tracert via konsolen på grund av säkerhetsbegränsningar (de fungerar i anpassade Windows-containrar).

Gå till Kudu-konsolen direkt på [sitename].scm.azurewebsites.net/DebugConsole.

Om du vill testa DNS-funktioner kan du använda nameresolver.exe. Syntaxen är:

nameresolver.exe hostname [optional:DNS Server]

Du kan använda nameresolver för att kontrollera de värdnamn som appen är beroende av. På så sätt kan du testa om du har något felkonfigurerat med din DNS eller kanske inte har åtkomst till DNS-servern. Du kan se DEN DNS-server som din app använder i -konsolen genom att titta på miljövariablerna WEBSITE_DNS_SERVER och WEBSITE_DNS_ALT_SERVER.

Obs!

Verktyget nameresolver.exe fungerar för närvarande inte i anpassade Windows-containrar.

Om du vill testa TCP-anslutningen till en värd- och portkombination kan du använda tcpping. Syntaxen är.

tcpping.exe hostname [optional: port]

Tcpping-verktyget talar om för dig om du kan nå en specifik värd och port. Det kan bara visas om ett program lyssnar på kombinationen värd och port och det finns nätverksåtkomst från din app till den angivna värden och porten.

Felsöka utgående anslutningar i Linux-appar

Gå till Kudu direkt på [sitename].scm.azurewebsites.net. På sidan Kudu-tjänst väljer du Verktyg>Felsökningskonsol-CMD>.

Om du vill testa DNS-funktioner kan du använda kommandot nslookup. Syntaxen är:

nslookup hostname [optional:DNS Server]

Beroende på ovanstående resultat kan du kontrollera om något är felkonfigurerat på DNS-servern.

Obs!

Verktyget nameresolver.exe fungerar för närvarande inte i Linux-appar.

Om du vill testa anslutningen kan du använda curl-kommandot . Syntaxen är:

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

Felsöka åtkomst till virtuella nätverksbaserade resurser

Ett antal faktorer kan hindra din app från att nå en specifik värd och port. För det mesta är det något av följande:

  • En brandvägg är i vägen. Om du har en brandvägg i vägen når du TCP-tidsgränsen. TCP-tidsgränsen är i det här fallet 21 sekunder. Använd tcpping-verktyget för att testa anslutningen. TCP-timeouter kan orsakas av många saker utöver brandväggar, men börja där.
  • DNS är inte tillgängligt. DNS-tidsgränsen är tre sekunder per DNS-server. Om du har två DNS-servrar är tidsgränsen sex sekunder. Använd nameresolver för att se om DNS fungerar. Du kan inte använda nslookup eftersom det inte använder den DNS som ditt virtuella nätverk har konfigurerats med. Om det inte går att komma åt kan du ha en brandvägg eller NSG som blockerar åtkomsten till DNS, eller så kan den vara nere. Vissa DNS-arkitekturer som använder anpassade DNS-servrar kan vara komplexa och kan ibland drabbas av timeouter. För att avgöra om så är fallet kan miljövariabeln WEBSITE_DNS_ATTEMPTS anges. Mer information om DNS i App Services finns i Namnmatchning (DNS) i App Service.

Om dessa objekt inte svarar på dina problem letar du först efter saker som:

Regional integrering av virtuellt nätverk

  • Är målet en icke-RFC1918 adress och du har inte Route All aktiverat?
  • Finns det en NSG som blockerar utgående trafik från ditt integrationsundernät?
  • Är din lokala gateway konfigurerad för att dirigera trafik tillbaka till Azure om du använder Azure ExpressRoute eller ett VPN? Om du kan nå slutpunkter i ditt virtuella nätverk men inte lokalt kontrollerar du vägarna.
  • Har du tillräcklig behörighet för att ange delegering i integrationsundernätet? Under konfigurationen av regional integrering av virtuella nätverk delegeras ditt integrationsundernät till Microsoft.Web/serverFarms. Användargränssnittet för VNet-integrering delegerar undernätet till Microsoft.Web/serverFarms automatiskt. Om ditt konto inte har tillräcklig nätverksbehörighet för att ange delegering behöver du någon som kan ange attribut för ditt integrationsundernät för att delegera undernätet. Om du vill delegera integrationsundernätet manuellt går du till användargränssnittet för Azure Virtual Network undernät och anger delegeringen för Microsoft.Web/serverFarms.

Att felsöka nätverksproblem är en utmaning eftersom du inte kan se vad som blockerar åtkomsten till en specifik kombination av värd:port. Några orsaker är:

  • Du har en brandvägg på värden som förhindrar åtkomst till programporten från ditt punkt-till-plats-IP-intervall. Att korsa undernät kräver ofta offentlig åtkomst.
  • Målvärden är nere.
  • Programmet är inte tillgängligt.
  • Du hade fel IP-adress eller värdnamn.
  • Programmet lyssnar på en annan port än vad du förväntade dig. Du kan matcha ditt process-ID med lyssningsporten med hjälp av "netstat -aon" på slutpunktsvärden.
  • Dina nätverkssäkerhetsgrupper konfigureras på ett sådant sätt att de förhindrar åtkomst till programvärden och porten från ditt punkt-till-plats-IP-intervall.

Du vet inte vilken adress din app faktiskt använder. Det kan vara vilken adress som helst i integrationsundernätet eller punkt-till-plats-adressintervallet, så du måste tillåta åtkomst från hela adressintervallet.

Fler felsökningssteg är:

  • Anslut till en virtuell dator i det virtuella nätverket och försök att nå resursvärden:porten därifrån. Om du vill testa för TCP-åtkomst använder du PowerShell-kommandot Test-NetConnection. Syntaxen är:
Test-NetConnection hostname [optional: -Port]
  • Ta upp ett program på en virtuell dator och testa åtkomsten till den värden och porten från konsolen från din app med hjälp av tcpping.

Felsökare för nätverk

Du kan också använda felsökaren Nätverk för att felsöka anslutningsproblemen för apparna i App Service. Öppna felsökaren för nätverk genom att gå till apptjänsten i Azure Portal. Välj Diagnostik och lösa problem och sök sedan efter nätverksfelsökare.

Skärmbild som visar hur du öppnar felsökaren för nätverk i Azure Portal.

Obs!

Scenariot med anslutningsproblem stöder inte Linux- eller Containerbaserade appar ännu.

Anslutningsproblem – Den kontrollerar statusen för integreringen av det virtuella nätverket, inklusive kontrollerar om den privata IP-adressen har tilldelats till alla instanser av App Service-planen och DNS-inställningarna. Om en anpassad DNS inte har konfigurerats tillämpas Standard-Azure DNS. Du kan också köra tester mot en specifik slutpunkt som du vill testa anslutningen till.

Skärmbild som visar körningsfelsökaren för anslutningsproblem.

Konfigurationsproblem – Den här felsökaren kontrollerar om ditt undernät är giltigt för integrering av virtuella nätverk.

Skärmbild som visar hur du kör felsökaren för konfigurationsproblem i Azure Portal.

Problem med borttagning av undernät/VNet – Den här felsökaren kontrollerar om ditt undernät har några lås och om det har några oanvända tjänstassocieringslänkar som kan blockera borttagningen av det virtuella nätverket/undernätet.

Skärmbild som visar hur du kör felsökaren för problem med borttagning av undernät eller virtuella nätverk.

Samla in nätverksspårningar

Att samla in nätverksspårningar kan vara till hjälp vid analys av problem. I Azure App Services hämtas nätverksspårningar från programprocessen. Återskapa problemet när du startar nätverksspårningssamlingen för att få korrekt information.

Obs!

Den virtuella nätverkstrafiken registreras inte i nätverksspårningar.

Windows App Services

Följ dessa steg för att samla in nätverksspårningar för Windows App Services:

  1. I Azure Portal navigerar du till webbappen.
  2. I det vänstra navigeringsfältet väljer du Diagnostisera och lösa problem.
  3. I sökrutan skriver du Samla in nätverksspårning och väljer Samla in nätverksspårning för att starta nätverksspårningssamlingen.

Skärmbild som visar hur du registrerar en nätverksspårning.

Om du vill hämta spårningsfilen för varje instans som betjänar en webbapp går du till Kudu-konsolen för webbappen (https://<sitename>.scm.azurewebsites.net) i webbläsaren. Ladda ned spårningsfilen från mappen C:\home\LogFiles\networktrace eller D:\home\LogFiles\networktrace .

Linux App Services

Följ dessa steg för att samla in nätverksspårningar för Linux App Services som inte använder en anpassad container:

  1. tcpdump Installera kommandoradsverktyget genom att köra följande kommandon:

    apt-get update
apt install tcpdump

  2. Anslut till containern via Secure Shell Protocol (SSH).

  3. Identifiera det gränssnitt som är igång genom att köra följande kommando (till exempel 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. Starta nätverksspårningssamlingen genom att köra följande kommando:

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

    Ersätt eth0 med namnet på det faktiska gränssnittet.

Om du vill ladda ned spårningsfilen ansluter du till webbappen via metoder som Kudu, FTP eller en Kudu API-begäran. Här är ett exempel på begäran för att utlösa filnedladdningen:

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

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.