Risolvere i problemi di integrazione della rete virtuale con il Servizio app di Azure

Questo articolo descrive gli strumenti che è possibile usare per risolvere i problemi di connessione nel servizio app Azure che si integrano con una rete virtuale.

Verificare l'integrazione della rete virtuale

Per risolvere i problemi di connessione, è prima necessario verificare se l'integrazione della rete virtuale è configurata correttamente e se l'INDIRIZZO IP privato viene assegnato a tutte le istanze del piano di servizio app.

Per farlo, usare uno dei metodi seguenti:

Controllare l'INDIRIZZO IP privato nella console di debug Kudu

Per accedere alla console Kudu, selezionare il servizio app nel portale di Azure, passare a Strumenti di sviluppo, selezionare Strumenti avanzati e quindi selezionare Vai. Nella pagina del servizio Kudu selezionare Strumenti>console di debug CMD.>

È anche possibile passare alla console di debug Kudu direttamente dall'URL [sitename].scm.azurewebsites.net/DebugConsole.

Nella console debug eseguire uno dei comandi seguenti:

App basate sul sistema operativo Windows

SET WEBSITE_PRIVATE_IP

Se l'indirizzo IP privato viene assegnato correttamente, si otterrà l'output seguente:

WEBSITE_PRIVATE_IP=<IP address>

App basate sul sistema operativo Linux

set| egrep --color 'WEBSITE_PRIVATE_IP'

Controllare l'indirizzo IP privato nell'ambiente Kudu

Passare all'ambiente Kudu all'indirizzo [sitename].scm.azurewebsites.net/Env e cercare WEBSITE_PRIVATE_IP.

Dopo aver stabilito che l'integrazione della rete virtuale è configurata correttamente, è possibile procedere con il test di connettività.

Risolvere i problemi di connettività in uscita nelle app di Windows

Nelle app di Windows native, gli strumenti ping, nslookup e tracert non funzioneranno tramite la console a causa di vincoli di sicurezza (funzionano in contenitori Windows personalizzati).

Passare direttamente alla console Kudu all'indirizzo [sitename].scm.azurewebsites.net/DebugConsole.

Per testare la funzionalità DNS, è possibile usare nameresolver.exe. La sintassi è:

nameresolver.exe hostname [optional:DNS Server]

È possibile usare nameresolver per controllare i nomi host da cui dipende l'app. In questo modo, è possibile verificare se si dispone di elementi non configurati correttamente con il DNS o forse non si ha accesso al server DNS. È possibile visualizzare il server DNS usato dall'app nella console esaminando le variabili di ambiente WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Per testare la connettività TCP a una combinazione di host e porta, è possibile usare tcpping. La sintassi è .

tcpping.exe hostname [optional: port]

L'utilità tcpping indica se è possibile raggiungere una porta e un host specifici. Può visualizzare l'esito positivo solo se è presente un'applicazione in ascolto nella combinazione di host e porta e l'accesso alla rete dall'app all'host e alla porta specificati.

Risolvere i problemi di connettività in uscita nelle app Linux

Passare direttamente a Kudu all'indirizzo [sitename].scm.azurewebsites.net. Nella pagina del servizio Kudu selezionare Strumenti>console di debug CMD.>

Per testare la funzionalità DNS, è possibile usare il comando nslookup. La sintassi è:

nslookup hostname [optional:DNS Server]

A seconda dei risultati precedenti, è possibile verificare se nel server DNS si è verificato un errore.

Per testare la connettività, è possibile usare il comando Curl . La sintassi è:

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

Eseguire il debug dell'accesso alle risorse ospitate nella rete virtuale

Un certo numero di fattori può impedire all'app di raggiungere un host e una porta specifici. Nella maggior parte dei casi, è uno dei seguenti:

• L'ostacolo è rappresentato da un firewall. Se è presente un firewall, si verifica il timeout TCP. che in questo caso è di 21 secondi. Usare lo strumento tcpping per testare la connettività. Il timeout TCP può essere dovuto anche ad altri motivi, ma è consigliabile iniziare dal firewall.
• Il DNS non è accessibile. Il timeout DNS è di tre secondi per ogni server DNS. Se si dispone di due server DNS, il timeout è di sei secondi. Usare nameresolver per verificare se il DNS funziona. Non è possibile usare nslookup perché non usa il DNS con cui è configurata la rete virtuale. Se non è accessibile, è possibile che un firewall o un gruppo di sicurezza di rete blocchi l'accesso al DNS o che sia inattivo. Alcune architetture DNS che usano server DNS personalizzati possono essere complesse e possono verificarsi occasionalmente timeout. Per determinare se questo è il caso, è possibile impostare la variabile WEBSITE_DNS_ATTEMPTS di ambiente. Per altre informazioni sul DNS in servizio app, vedere Risoluzione dei nomi (DNS) in servizio app.

Se questi elementi non rispondono ai problemi, cercare prima di tutto elementi come:

Integrazione della rete virtuale regionale

• La destinazione è un indirizzo non RFC1918 e non è abilitato Route All?
• Esiste un gruppo di sicurezza di rete che blocca l'uscita dalla subnet di integrazione?
• Se si passa attraverso Azure ExpressRoute o una VPN, il gateway locale è configurato per instradare il traffico di backup ad Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, controllare le route.
• Sono disponibili autorizzazioni sufficienti per impostare la delega nella subnet di integrazione? Durante la configurazione dell'integrazione della rete virtuale a livello di area, la subnet di integrazione viene delegata a Microsoft.Web/serverFarms. L'interfaccia utente di integrazione della rete virtuale delega automaticamente la subnet a Microsoft.Web/serverFarms. Se l'account non dispone di autorizzazioni di rete sufficienti per impostare la delega, è necessario un utente che possa impostare gli attributi nella subnet di integrazione per delegare la subnet. Per delegare manualmente la subnet di integrazione, passare all'interfaccia utente della subnet di Rete virtuale di Azure e impostare la delega per Microsoft.Web/serverFarms.

Il debug dei problemi di rete è un problema perché non è possibile vedere cosa blocca l'accesso a una combinazione host:porta specifica. Alcune cause includono:

• È presente un firewall sull'host che impedisce l'accesso alla porta dell'applicazione dall'intervallo IP da punto a sito. Il passaggio tra subnet spesso richiede l'accesso pubblico.
• L'host di destinazione è inattivo.
• L'applicazione è inattiva.
• L'IP o il nome host è errato.
• L'applicazione è in ascolto su una porta diversa da quella prevista. È possibile associare l'ID di processo alla porta di ascolto mediante "netstat -aon" nell'host dell'endpoint.
• I gruppi di sicurezza di rete sono configurati in modo da impedire l'accesso all'host e alla porta dell'applicazione dall'intervallo IP da punto a sito.

Non si sa quale indirizzo viene effettivamente usato dall'app. Può trattarsi di qualsiasi indirizzo nella subnet di integrazione o nell'intervallo di indirizzi da punto a sito, quindi è necessario consentire l'accesso dall'intero intervallo di indirizzi.

Altri passaggi di debug includono:

• Connettersi a un'altra macchina virtuale nella rete virtuale e provare a raggiungere l'host:porta della risorsa da quel punto. Per verificare l'accesso al protocollo TCP usare il comando di PowerShell test-netconnection. La sintassi è:

Test-NetConnection hostname [optional: -Port]

• Visualizzare un'applicazione in una macchina virtuale e testare l'accesso a tale host e porta dalla console dall'app usando tcpping.

Strumento di risoluzione dei problemi di rete

È anche possibile usare lo strumento di risoluzione dei problemi di rete per risolvere i problemi di connessione per le app nella servizio app. Per aprire lo strumento di risoluzione dei problemi di rete, passare al servizio app nel portale di Azure. Selezionare Diagnostica e risolvere il problema e quindi cercare Risoluzione dei problemi di rete.

Problemi di connessione: controlla lo stato dell'integrazione della rete virtuale, inclusa la verifica dell'assegnazione dell'INDIRIZZO IP privato a tutte le istanze del piano di servizio app e delle impostazioni DNS. Se non è configurato un DNS personalizzato, verrà applicato il DNS di Azure predefinito. È anche possibile eseguire test su un endpoint specifico a cui si vuole testare la connettività.

Problemi di configurazione: questo strumento di risoluzione dei problemi verificherà se la subnet è valida per l'integrazione della rete virtuale.

Problema di eliminazione di subnet/rete virtuale: questo strumento di risoluzione dei problemi verificherà se la subnet ha blocchi e se contiene collegamenti di associazione del servizio inutilizzati che potrebbero bloccare l'eliminazione della rete virtuale/subnet.

Raccogliere tracce di rete

La raccolta di tracce di rete può essere utile per analizzare i problemi. In app Azure Services le tracce di rete vengono ricavate dal processo dell'applicazione. Per ottenere informazioni accurate, riprodurre il problema durante l'avvio della raccolta di traccia di rete.

Windows servizio app s

Per raccogliere tracce di rete per windows servizio app, seguire questa procedura:

1. Nella portale di Azure passare all'app Web.
2. Nel riquadro di spostamento a sinistra selezionare Diagnostica e risolvi problemi.
3. Nella casella di ricerca digitare Raccogli traccia di rete e selezionare Raccogli traccia di rete per avviare la raccolta di tracce di rete.

Per ottenere il file di traccia per ogni istanza che gestisce un'app Web, nel browser passare alla console Kudu per l'app Web (https://<sitename>.scm.azurewebsites.net). Scaricare il file di traccia dalla cartella C:\home\LogFiles\networktrace o D:\home\LogFiles\networktrace .

Servizio app Linux

Per raccogliere tracce di rete per i servizio app Linux che non usano un contenitore personalizzato, seguire questa procedura:

1. Installare l'utilità della tcpdump riga di comando eseguendo i comandi seguenti:

   apt-get update
   apt install tcpdump
   

2. Connettersi al contenitore tramite Secure Shell Protocol (SSH).

3. Identificare l'interfaccia operativa eseguendo il comando seguente , ad esempio 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. Avviare la raccolta di tracce di rete eseguendo il comando seguente:

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

   Sostituire eth0 con il nome dell'interfaccia effettiva.

Per scaricare il file di traccia, connettersi all'app Web tramite metodi come Kudu, FTP o una richiesta API Kudu. Ecco un esempio di richiesta per attivare il download del file:

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

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.