Risolvere i problemi di integrazione della rete virtuale con Servizio app di Azure
Questo articolo descrive gli strumenti che è possibile usare per risolvere i problemi di connessione in Servizio app di Azure che si integrano con una rete virtuale.
Nota
L'integrazione della rete virtuale non è supportata per gli scenari Docker Compose in servizio app. I criteri di restrizione di accesso vengono ignorati se è presente un endpoint privato.
Verificare l'integrazione della rete virtuale
Per risolvere i problemi di connessione, è prima di tutto necessario verificare se l'integrazione della rete virtuale è configurata correttamente e se l'IP privato è assegnato a tutte le istanze del piano di servizio app.
A tale scopo, 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 Tools Debug ConsoleCMD (Cmdconsole> di debug degli strumenti>).
È anche possibile passare alla console di debug Kudu direttamente dall'URL [sitename].scm.azurewebsites.net/DebugConsole
.
Nella console di debug eseguire uno dei comandi seguenti:
App basate su sistema operativo Windows
SET WEBSITE_PRIVATE_IP
Se l'IP privato viene assegnato correttamente, si otterrà l'output seguente:
WEBSITE_PRIVATE_IP=<IP address>
App basate su 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 è stata 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 funzionano tramite la console a causa di vincoli di sicurezza (funzionano in contenitori Windows personalizzati).
Passare alla console Kudu direttamente all'indirizzo [sitename].scm.azurewebsites.net/DebugConsole
.
Per testare la funzionalità DNS, è possibile usare nameresolver.exe. La sintassi è:
nameresolver.exe hostname [optional:DNS Server]
Puoi usare nameresolver per controllare i nomi host da cui dipende l'app. In questo modo, è possibile testare se si ha qualcosa di non configurato correttamente con il DNS o se 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.
Nota
Lo strumento nameresolver.exe attualmente non funziona nei contenitori windows personalizzati.
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 un host e una porta specifici. Può mostrare l'esito positivo solo se c'è un'applicazione in ascolto nella combinazione host e porta ed è disponibile l'accesso di rete dall'app all'host e alla porta specificati.
Risolvere i problemi di connettività in uscita nelle app Linux
Passare a Kudu direttamente all'indirizzo [sitename].scm.azurewebsites.net
. Nella pagina del servizio Kudu selezionare Tools Debug ConsoleCMD (Cmdconsole> di debug degli strumenti>).
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 è presente un errore di configurazione.
Nota
Lo strumento nameresolver.exe attualmente non funziona nelle app Linux.
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 dalla rete virtuale
Diversi fattori possono impedire all'app di raggiungere un host e una porta specifici. Nella maggior parte dei casi, è uno dei seguenti:
- Un firewall è in mezzo. Se si dispone di un firewall, si raggiunge il timeout TCP. In questo caso, il timeout TCP è di 21 secondi. Usare lo strumento tcpping per testare la connettività. I timeout TCP possono essere causati da molti elementi oltre i firewall, ma iniziano da qui.
- DNS non è accessibile. Il timeout DNS è di tre secondi per 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 a DNS oppure che sia inattivo. Alcune architetture DNS che usano server DNS personalizzati possono essere complesse e possono occasionalmente verificarsi timeout. Per determinare se questo è il caso, è possibile impostare la variabile
WEBSITE_DNS_ATTEMPTS
di ambiente. Per altre informazioni su DNS in Servizi 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 a livello di area
- La destinazione è un indirizzo non RFC1918 e non è abilitata l'opzione Route All ?
- Esiste un gruppo di sicurezza di rete che blocca l'uscita dalla subnet di integrazione?
- Se si usa Azure ExpressRoute o una VPN, il gateway locale è configurato per instradare il traffico ad Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, controllare le route.
- Si dispone di autorizzazioni sufficienti per impostare la delega nella subnet di integrazione? Durante la configurazione di 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, sarà necessario un utente in grado di impostare gli attributi nella subnet di integrazione per delegare la subnet. Per delegare manualmente la subnet di integrazione, passare all'interfaccia utente della subnet Rete virtuale di Azure e impostare la delega per Microsoft.Web/serverFarms.
Il debug dei problemi di rete è una sfida perché non è possibile vedere cosa blocca l'accesso a una combinazione host:porta specifica. Alcune cause includono:
- È presente un firewall nell'host che impedisce l'accesso alla porta dell'applicazione dall'intervallo IP da punto a sito. L'attraversamento delle subnet richiede spesso l'accesso pubblico.
- L'host di destinazione è inattivo.
- L'applicazione è inattiva.
- L'indirizzo IP o il nome host non è corretto.
- L'applicazione è in ascolto su una porta diversa da quella prevista. È possibile associare l'ID processo alla porta di ascolto usando "netstat -aon" nell'host dell'endpoint.
- I gruppi di sicurezza di rete sono configurati in modo da impedire l'accesso all'host dell'applicazione e alla porta dall'intervallo IP da punto a sito.
Non si conosce l'indirizzo effettivamente usato dall'app. Potrebbe essere 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 una macchina virtuale nella rete virtuale e tentare di raggiungere l'host della risorsa:porta da questa posizione. Per verificare l'accesso 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 all'host e alla 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 nel 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.
Nota
Lo scenario dei problemi di connessione non supporta ancora le app linux o basate su contenitori.
Problemi di connessione: controllerà lo stato dell'integrazione della rete virtuale, incluso il controllo se l'IP privato è stato assegnato a tutte le istanze del piano di servizio app e alle 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 della subnet/rete virtuale : questo strumento di risoluzione dei problemi verificherà se la subnet dispone di blocchi e se sono presenti 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 l'analisi dei problemi. In app Azure Services le tracce di rete vengono tratte dal processo dell'applicazione. Per ottenere informazioni accurate, riprodurre il problema durante l'avvio della raccolta di traccia di rete.
Nota
Il traffico di rete virtuale non viene acquisito nelle tracce di rete.
Servizi app Windows
Per raccogliere tracce di rete per Servizi app Windows, seguire questa procedura:
- Nel portale di Azure passare all'app Web.
- Nel riquadro di spostamento a sinistra selezionare Diagnosticare e risolvere i problemi.
- Nella casella di ricerca digitare Collect Network Trace (Raccogli traccia di rete ) e selezionare Collect Network Trace (Raccogli traccia di rete) per avviare la raccolta di tracce di rete.
Per ottenere il file di traccia per ogni istanza che serve 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 .
Servizi app Linux
Per raccogliere tracce di rete per Servizi app Linux che non usano un contenitore personalizzato, seguire questa procedura:
Installare l'utilità
tcpdump
della riga di comando eseguendo i comandi seguenti:apt-get update apt install tcpdump
Connettersi al contenitore tramite SSH (Secure Shell Protocol).
Identificare l'interfaccia in esecuzione eseguendo il comando seguente,
eth0
ad esempio :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]
Avviare la raccolta di traccia 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 quali 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.