Problemen met integratie van virtuele netwerken met Azure App Service oplossen
In dit artikel worden hulpprogramma's beschreven die u kunt gebruiken om verbindingsproblemen in Azure-app Service op te lossen die zijn geïntegreerd met een virtueel netwerk.
Notitie
Integratie van virtuele netwerken wordt niet ondersteund voor Docker Compose-scenario's in App Service. Toegangsbeperkingsbeleid wordt genegeerd als er een privé-eindpunt aanwezig is.
Integratie van virtueel netwerk controleren
Als u de verbindingsproblemen wilt oplossen, moet u eerst controleren of de integratie van het virtuele netwerk juist is geconfigureerd en of het privé-IP-adres is toegewezen aan alle exemplaren van het App Service-plan.
Gebruik hiervoor een van de volgende methoden:
Controleer het privé-IP-adres in de Kudu-foutopsporingsconsole
Als u toegang wilt krijgen tot de Kudu-console, selecteert u de app-service in Azure Portal, gaat u naar Ontwikkelhulpprogramma's, selecteert u Geavanceerde hulpprogramma's en selecteert u Vervolgens Go. Selecteer op de kudu-servicepagina hulpprogramma's>voor foutopsporingsconsole>CMD.
U kunt ook rechtstreeks via de URL [sitename].scm.azurewebsites.net/DebugConsole
naar de Kudu-console voor foutopsporing gaan.
Voer in de console Voor foutopsporing een van de volgende opdrachten uit:
Windows-apps op basis van het besturingssysteem
SET WEBSITE_PRIVATE_IP
Als het privé-IP-adres is toegewezen, krijgt u de volgende uitvoer:
WEBSITE_PRIVATE_IP=<IP address>
Linux-apps op basis van het besturingssysteem
set| egrep --color 'WEBSITE_PRIVATE_IP'
Controleer het privé-IP-adres in de Kudu-omgeving
Ga naar de Kudu-omgeving op [sitename].scm.azurewebsites.net/Env
en zoek naar WEBSITE_PRIVATE_IP
.
Zodra we hebben vastgesteld dat de integratie van het virtuele netwerk is geconfigureerd, kunnen we doorgaan met de connectiviteitstest.
Problemen met uitgaande connectiviteit in Windows-apps oplossen
In systeemeigen Windows-apps werken de hulpprogramma's ping, nslookup en tracert niet via de console vanwege beveiligingsbeperkingen (ze werken in aangepaste Windows-containers).
Ga rechtstreeks naar de Kudu-console.[sitename].scm.azurewebsites.net/DebugConsole
Als u de DNS-functionaliteit wilt testen, kunt u nameresolver.exe gebruiken. De syntaxis is:
nameresolver.exe hostname [optional:DNS Server]
U kunt nameresolver gebruiken om de hostnamen te controleren waarop uw app afhankelijk is. Op deze manier kunt u testen of er iets mis is geconfigureerd met uw DNS of mogelijk geen toegang hebt tot uw DNS-server. U kunt de DNS-server zien die uw app in de console gebruikt door de omgevingsvariabelen te bekijken WEBSITE_DNS_SERVER en WEBSITE_DNS_ALT_SERVER.
Notitie
Het hulpprogramma nameresolver.exe werkt momenteel niet in aangepaste Windows-containers.
Als u TCP-connectiviteit met een combinatie van host en poort wilt testen, kunt u tcpping gebruiken. De syntaxis is.
tcpping.exe hostname [optional: port]
Het tcpping-hulpprogramma geeft aan of u een specifieke host en poort kunt bereiken. Het kan alleen slagen als er een toepassing luistert op de combinatie van de host en poort en er is netwerktoegang van uw app naar de opgegeven host en poort.
Problemen met uitgaande connectiviteit in Linux-apps oplossen
Ga rechtstreeks naar Kudu.[sitename].scm.azurewebsites.net
Selecteer op de kudu-servicepagina hulpprogramma's>voor foutopsporingsconsole>CMD.
Als u de DNS-functionaliteit wilt testen, kunt u de opdracht nslookup gebruiken. De syntaxis is:
nslookup hostname [optional:DNS Server]
Afhankelijk van de bovenstaande resultaten kunt u controleren of er iets onjuist is geconfigureerd op uw DNS-server.
Notitie
Het hulpprogramma nameresolver.exe werkt momenteel niet in Linux-apps.
Als u de connectiviteit wilt testen, kunt u de curl-opdracht gebruiken. De syntaxis is:
curl -v https://hostname
curl hostname:[port]
Fouten opsporen in toegang tot door een virtueel netwerk gehoste resources
Een aantal factoren kan voorkomen dat uw app een specifieke host en poort bereikt. Meestal is dit een van de volgende:
- Een firewall is in de weg. Als u een firewall hebt, raakt u de TCP-time-out. De TCP-time-out is in dit geval 21 seconden. Gebruik het tcpping-hulpprogramma om de connectiviteit te testen. TCP-time-outs kunnen worden veroorzaakt door veel dingen buiten firewalls, maar begin daar.
- DNS is niet toegankelijk. De DNS-time-out is drie seconden per DNS-server. Als u twee DNS-servers hebt, is de time-out zes seconden. Gebruik nameresolver om te zien of de DNS werkt. U kunt nslookup niet gebruiken omdat hiermee niet de DNS wordt gebruikt waarmee uw virtuele netwerk is geconfigureerd. Als u niet toegankelijk bent, kunt u een firewall of NSG hebben die de toegang tot DNS blokkeert, of kan deze offline zijn. Sommige DNS-architecturen die gebruikmaken van aangepaste DNS-servers kunnen complex zijn en kunnen af en toe time-outs ervaren. Om te bepalen of dit het geval is, kan de omgevingsvariabele
WEBSITE_DNS_ATTEMPTS
worden ingesteld. Zie Naamomzetting (DNS) in App Service voor meer informatie over DNS in App Services.
Als deze items uw problemen niet beantwoorden, zoekt u eerst naar zaken zoals:
Integratie van regionaal virtueel netwerk
- Is uw bestemming een niet-RFC1918 adres en hebt u Route All niet ingeschakeld?
- Is er een NSG die uitgaand verkeer van uw integratiesubnet blokkeert?
- Als u azure ExpressRoute of een VPN gebruikt, is uw on-premises gateway geconfigureerd voor het routeren van verkeer naar Azure? Als u eindpunten in uw virtuele netwerk kunt bereiken, maar niet on-premises, controleert u uw routes.
- Hebt u voldoende machtigingen om delegatie in te stellen voor het integratiesubnet? Tijdens de configuratie van regionale virtuele netwerkintegratie wordt uw integratiesubnet gedelegeerd aan Microsoft.Web/serverFarms. De gebruikersinterface voor VNet-integratie delegeert het subnet automatisch naar Microsoft.Web/serverFarms. Als uw account niet over voldoende netwerkmachtigingen beschikt om delegatie in te stellen, hebt u iemand nodig die kenmerken in uw integratiesubnet kan instellen om het subnet te delegeren. Als u het integratiesubnet handmatig wilt delegeren, gaat u naar de gebruikersinterface van het azure Virtual Network-subnet en stelt u de delegatie in voor Microsoft.Web/serverFarms.
Netwerkproblemen opsporen is een uitdaging omdat u niet kunt zien wat de toegang tot een specifieke combinatie van host:poort blokkeert. Enkele oorzaken zijn:
- U hebt een firewall op uw host die de toegang tot de toepassingspoort van uw punt-naar-site-IP-bereik voorkomt. Voor het kruisen van subnetten is vaak openbare toegang vereist.
- Uw doelhost is offline.
- Uw toepassing is niet beschikbaar.
- U had het verkeerde IP- of hostnaam.
- Uw toepassing luistert op een andere poort dan u had verwacht. U kunt uw proces-id vergelijken met de luisterpoort met behulp van 'netstat -aon' op de eindpunthost.
- Uw netwerkbeveiligingsgroepen worden zodanig geconfigureerd dat ze de toegang tot uw toepassingshost en -poort van uw punt-naar-site-IP-bereik voorkomen.
U weet niet welk adres uw app daadwerkelijk gebruikt. Dit kan elk adres in het integratiesubnet of punt-naar-site-adresbereik zijn, dus u moet toegang vanuit het hele adresbereik toestaan.
Meer stappen voor foutopsporing zijn:
- Maak verbinding met een virtuele machine in uw virtuele netwerk en probeer uw resourcehost te bereiken: poort vanaf daar. Gebruik de PowerShell-opdracht Test-NetConnection om te testen op TCP-toegang. De syntaxis is:
Test-NetConnection hostname [optional: -Port]
- Open een toepassing op een VIRTUELE machine en test de toegang tot die host en poort vanuit de console vanuit uw app met behulp van tcpping.
Probleemoplossing voor netwerken
U kunt ook de probleemoplosser voor netwerken gebruiken om de verbindingsproblemen voor de apps in App Service op te lossen. Als u de probleemoplosser voor netwerken wilt openen, gaat u naar de app-service in Azure Portal. Selecteer Diagnostische gegevens en los het probleem op en zoek vervolgens naar de probleemoplosser voor netwerken.
Notitie
Het scenario met verbindingsproblemen biedt nog geen ondersteuning voor Linux- of container-apps.
Verbindingsproblemen : hiermee wordt de status van de integratie van het virtuele netwerk gecontroleerd, inclusief het controleren of het privé-IP-adres is toegewezen aan alle exemplaren van het App Service-plan en de DNS-instellingen. Als een aangepaste DNS niet is geconfigureerd, wordt standaard Azure DNS toegepast. U kunt ook tests uitvoeren op een specifiek eindpunt waarmee u de connectiviteit wilt testen.
Configuratieproblemen : deze probleemoplosser controleert of uw subnet geldig is voor integratie van virtuele netwerken.
Probleem met verwijderen van subnet/VNet: deze probleemoplosser controleert of uw subnet vergrendelingen heeft en of er ongebruikte servicekoppelingen zijn die de verwijdering van het VNet/subnet mogelijk blokkeren.
Netwerktraceringen verzamelen
Het verzamelen van netwerktraceringen kan handig zijn bij het analyseren van problemen. In Azure-app Services worden netwerktraceringen uit het toepassingsproces gehaald. Om nauwkeurige informatie te verkrijgen, reproduceert u het probleem tijdens het starten van de netwerktraceringsverzameling.
Notitie
Het verkeer van het virtuele netwerk wordt niet vastgelegd in netwerktraceringen.
Windows App Services
Volg deze stappen om netwerktraceringen voor Windows App Services te verzamelen:
- Navigeer in Azure Portal naar uw web-app.
- Selecteer in het linkernavigatievenster Diagnose en Los problemen op.
- Typ Netwerktracering verzamelen in het zoekvak en selecteer Netwerktracering verzamelen om de verzameling netwerktracering te starten.
Als u het traceringsbestand wilt ophalen voor elk exemplaar dat een web-app bedient, gaat u in uw browser naar de Kudu-console voor de web-app (https://<sitename>.scm.azurewebsites.net
). Download het traceringsbestand uit de map C:\home\LogFiles\networktrace of D:\home\LogFiles\networktrace .
Linux App Services
Als u netwerktraceringen wilt verzamelen voor Linux App Services die geen aangepaste container gebruiken, voert u de volgende stappen uit:
Installeer het
tcpdump
opdrachtregelprogramma door de volgende opdrachten uit te voeren:apt-get update apt install tcpdump
Maak verbinding met de container via SSH (Secure Shell Protocol).
Identificeer de interface die actief is door de volgende opdracht uit te voeren (bijvoorbeeld
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]
Start de verzameling netwerktracering door de volgende opdracht uit te voeren:
root@<hostname>:/home# tcpdump -i eth0 -w networktrace.pcap
Vervang door
eth0
de naam van de werkelijke interface.
Als u het traceringsbestand wilt downloaden, maakt u verbinding met de web-app via methoden zoals Kudu, FTP of een Kudu-API-aanvraag. Hier volgt een voorbeeld van een aanvraag voor het activeren van het downloaden van het bestand:
https://<sitename>.scm.azurewebsites.net/api/vfs/<path to the trace file in the /home directory>/filename
Disclaimerinformatie van derden
De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.
Contacteer ons voor hulp
Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.