Risolvere i problemi di connettività del gateway NAT di Azure

  • Articolo

Questo articolo fornisce indicazioni su come risolvere e risolvere i problemi comuni di connettività in uscita con il gateway NAT. Questo articolo fornisce anche procedure consigliate su come progettare applicazioni per l'uso efficiente delle connessioni in uscita.

Eliminazione della disponibilità del percorso dati nel gateway NAT con errori di connessione

Scenario

Si osserva un calo della disponibilità del percorso dati del gateway NAT, che coincide con gli errori di connessione.

Possibili cause

  • Esaurimento delle porte SNAT (Source Network Address Translation).

  • Limiti di connessione SNAT simultanei.

  • timeout di Connessione ion.

Risolvere i problemi relativi ai passaggi

  • Valutare l'integrità del gateway NAT controllando la metrica di disponibilità del percorso dati.

  • Controllare la metrica SNAT Connessione ion Count e dividere lo stato della connessione per tentativo e connessioni non riuscite. Più di zero connessioni non riuscite indicano l'esaurimento delle porte SNAT o il raggiungimento del limite di numero di connessioni SNAT del gateway NAT.

  • Verificare che la metrica del numero di connessioni sia entro i limiti verificando la metrica Totale SNAT Connessione ion Count. Il gateway NAT supporta 50.000 connessioni simultanee per ogni indirizzo IP a una destinazione univoca e fino a 2 milioni di connessioni in totale. Per altre informazioni, vedere Prestazioni del gateway NAT.

  • Controllare la metrica dei pacchetti eliminati per eventuali eliminazioni di pacchetti allineate a errori di connessione o volume di connessione elevato.

  • Modificare le impostazioni del timer di timeout di inattività TCP (Transmission Control Protocol) in base alle esigenze. Un timer di timeout di inattività impostato su un valore superiore a quello predefinito (4 minuti) sui flussi è più lungo e può creare una pressione aggiuntiva sull'inventario delle porte SNAT.

Possibili soluzioni per l'esaurimento delle porte SNAT o il raggiungimento dei limiti di connessione simultanei

  • Aggiungere indirizzi IP pubblici al gateway NAT fino a un totale di 16 per ridimensionare la connettività in uscita. Ogni indirizzo IP pubblico fornisce 64.512 porte SNAT e supporta fino a 50.000 connessioni simultanee per ogni endpoint di destinazione univoco per il gateway NAT.

  • Distribuire l'ambiente dell'applicazione tra più subnet e specificare una risorsa gateway NAT per ogni subnet.

  • Liberare l'inventario delle porte SNAT riducendo il timer di timeout di inattività TCP a un valore inferiore. Il timer di timeout di inattività TCP non può essere impostato in meno di 4 minuti.

  • Prendere in considerazione i modelli di polling asincrono per liberare risorse di connessione per altre operazioni.

  • Stabilire connessioni ai servizi PaaS di Azure tramite il backbone di Azure usando collegamento privato. Il collegamento privato libera le porte SNAT per le connessioni in uscita a Internet.

  • Se l'indagine è inconcludente, aprire un caso di supporto per risolvere ulteriormente i problemi.

Nota

È importante comprendere perché si verifica l'esaurimento delle porte SNAT. Assicurarsi di usare i modelli corretti per scenari scalabili e affidabili. L'aggiunta di più porte SNAT a uno scenario senza aver compreso la causa della domanda deve essere l'ultima eventualità. Se non si capisce perché lo scenario applica pressione sull'inventario delle porte SNAT, l'aggiunta di altre porte SNAT aggiungendo più indirizzi IP ritarderà solo lo stesso errore di esaurimento delle scalabilità dell'applicazione. È possibile che si stiano mascherando altre inefficienze e anti-pattern. Per altre informazioni, vedere Procedure consigliate per un uso efficiente delle connessioni in uscita.

Possibili soluzioni per i timeout di connessione TCP

Usare keepalives TCP o keep-alives del livello applicazione per aggiornare i flussi inattive e reimpostare il timer di timeout di inattività. Per esempi, vedere esempi di .NET.

I keep-alive TCP devono essere abilitati solo da un lato di una connessione per mantenere attiva una connessione da entrambi i lati. Quando un keepalive TCP viene inviato da un lato di una connessione, l'altro lato invia automaticamente un pacchetto di conferma (ACK). Il timer di timeout di inattività viene quindi reimpostato su entrambi i lati della connessione.

Nota

L'aumento del timeout di inattività TCP è un'ultima risorsa e potrebbe non risolvere la causa radice del problema. Un timeout lungo può introdurre ritardi e causare errori a bassa frequenza non necessari alla scadenza del timeout.

Possibili soluzioni per i timeout di connessione UDP (User Datagram Protocol)

I timer di timeout di inattività UDP sono impostati su 4 minuti e non sono configurabili. Abilitare i keep-up UDP per entrambe le direzioni in un flusso di connessione per mantenere connessioni lunghe. Quando un keepalive UDP è abilitato, è attivo solo per una direzione in una connessione. La connessione può comunque andare inattiva e verificarne il timeout dall'altra parte di una connessione. Per impedire il timeout di inattività di una connessione UDP, i keep-up UDP devono essere abilitati per entrambe le direzioni in un flusso di connessione.

I keep-alives del livello applicazione possono essere usati anche per aggiornare i flussi inattive e reimpostare il timeout di inattività. Controllare il lato server per verificare le opzioni disponibili per keep-alive specifici dell'applicazione.

Eliminazione della disponibilità del percorso dati nel gateway NAT, ma nessun errore di connessione

Scenario

La disponibilità del percorso dati del gateway NAT viene eliminata, ma non vengono osservate connessioni non riuscite.

Possibile causa

Calo temporaneo della disponibilità del percorso dati causato da disturbo nel percorso dati.

Passaggi per la risoluzione dei problemi

Se si nota un calo della disponibilità del percorso dati senza alcun effetto sulla connettività in uscita, il problema potrebbe essere dovuto al fatto che il gateway NAT rileva un rumore temporaneo nel percorso dati.

Configurare un avviso per eliminare la disponibilità del percorso dati o usare Azure Integrità risorse per generare avvisi sugli eventi di integrità del gateway NAT.

Nessuna connettività in uscita a Internet

Scenario

Non viene osservata alcuna connettività in uscita nel gateway NAT.

Possibili cause

  • Configurazione errata del gateway NAT.

  • Il traffico Internet viene reindirizzato dal gateway NAT e sottoposto a tunneling forzato a un'appliance virtuale o a una destinazione locale con una VPN o ExpressRoute.

  • Le regole del gruppo di sicurezza di rete sono configurate che bloccano il traffico Internet.

  • La disponibilità del percorso dati del gateway NAT è danneggiata.

  • Configurazione errata di Domain Name System (DNS).

Passaggi per la risoluzione dei problemi

  • Verificare che il gateway NAT sia configurato con almeno un indirizzo IP pubblico o un prefisso e collegato a una subnet. Il gateway NAT non è operativo fino a quando non viene collegato un indirizzo IP pubblico e una subnet. Per altre informazioni, vedere Nozioni di base sulla configurazione del gateway NAT.

  • Controllare la tabella di routing della subnet collegata al gateway NAT. Qualsiasi traffico 0.0.0.0/0 sottoposto a tunneling forzato a un'appliance virtuale di rete,ExpressRoute o Gateway VPN avrà la priorità sul gateway NAT. Per altre informazioni, vedere come Azure seleziona una route.

  • Controllare se sono presenti regole del gruppo di sicurezza di rete configurate per l'interfaccia di rete nella macchina virtuale che blocca l'accesso a Internet.

  • Controllare se la disponibilità del percorso dati del gateway NAT è in uno stato danneggiato. Fare riferimento alle indicazioni sulla risoluzione dei problemi di connessione se il gateway NAT si trova in uno stato danneggiato.

  • Controllare le impostazioni DNS se DNS non viene risolto correttamente.

Possibili soluzioni per la perdita di connettività in uscita

L'indirizzo IP pubblico del gateway NAT non viene usato per connettersi in uscita

Scenario

Il gateway NAT viene distribuito nella rete virtuale di Azure, ma vengono usati indirizzi IP imprevisti per le connessioni in uscita.

Possibili cause

  • Configurazione errata del gateway NAT.

  • Connessione attiva con un altro metodo di connettività in uscita di Azure, ad esempio Azure Load Balancer o indirizzi IP pubblici a livello di istanza nelle macchine virtuali. I flussi di connessione attivi continuano a usare l'indirizzo IP pubblico precedente assegnato al momento della connessione. Quando viene distribuito il gateway NAT, le nuove connessioni iniziano subito a usare il gateway NAT.

  • Gli indirizzi IP privati vengono usati per connettersi ai servizi di Azure tramite endpoint di servizio o collegamento privato.

  • Connessione agli account di archiviazione provengono dalla stessa area della macchina virtuale da cui si effettua una connessione.

  • Il traffico Internet viene reindirizzato dal gateway NAT e sottoposto a tunneling forzato a un'appliance virtuale di rete o a un firewall.

Come risolvere i problemi

  • Verificare che il gateway NAT abbia almeno un indirizzo IP pubblico o un prefisso associato e almeno una subnet.

  • Verificare se un metodo di connettività in uscita precedente, ad esempio un servizio di bilanciamento del carico pubblico, è ancora attivo dopo la distribuzione del gateway NAT.

  • Controllare se le connessioni effettuate ad altri servizi di Azure provengono da un indirizzo IP privato nella rete virtuale di Azure.

  • Controllare se sono stati abilitati collegamento privato o endpoint di servizio per la connessione ad altri servizi di Azure.

  • Assicurarsi che la macchina virtuale si trovi nella stessa area dell'archiviazione di Azure quando si effettua una connessione di archiviazione.

  • Verificare se l'indirizzo IP pubblico usato per le connessioni proviene da un altro servizio di Azure all'interno della rete virtuale di Azure, ad esempio un'appliance virtuale di rete.

Possibili soluzioni per l'indirizzo IP pubblico del gateway NAT non usato per connettersi in uscita

  • Collegare un indirizzo IP pubblico o un prefisso al gateway NAT. Assicurarsi che il gateway NAT sia collegato alle subnet dalla stessa rete virtuale. Verificare che il gateway NAT possa connettersi in uscita.

  • Testare e risolvere i problemi relativi alle macchine virtuali che mantengono gli indirizzi IP SNAT precedenti da un altro metodo di connettività in uscita tramite:

    • Assicurarsi di stabilire una nuova connessione e che le connessioni esistenti non vengano riutilizzate nel sistema operativo o che il browser stia memorizzando nella cache le connessioni. Quando si usa curl in PowerShell, ad esempio, specificare il parametro -DisableKeepalive per forzare una nuova connessione. Se si usa un browser, è anche possibile eseguire il pool delle connessioni.

    • Non è necessario riavviare una macchina virtuale in una subnet configurata per il gateway NAT. Se una macchina virtuale viene riavviata, tuttavia, lo stato della connessione viene eliminato. Quando lo stato della connessione viene scaricato, tutte le connessioni iniziano a usare l'indirizzo IP o gli indirizzi della risorsa del gateway NAT. Questo comportamento è un effetto collaterale del riavvio della macchina virtuale e non un indicatore che è necessario un riavvio.

    • Se si verificano ancora problemi, aprire un caso di supporto per altre operazioni di risoluzione dei problemi.

  • Le route personalizzate che indirizzano il traffico 0.0.0.0/0 a un'appliance virtuale di rete avranno la precedenza sul gateway NAT per il routing del traffico verso Internet. Per fare in modo che il gateway NAT instrada il traffico verso Internet anziché l'appliance virtuale di rete, rimuovere la route personalizzata per il traffico 0.0.0.0/0 verso l'appliance virtuale. Il traffico 0.0.0.0/0 riprende usando la route predefinita verso Internet e viene usato il gateway NAT.

Importante

Prima di apportare modifiche alle route del traffico, prendere in considerazione attentamente i requisiti di routing dell'architettura cloud.

  • I servizi distribuiti nella stessa area di un account di archiviazione di Azure usano indirizzi IP privati di Azure per la comunicazione. Non è possibile limitare l'accesso a servizi di Azure specifici in base all'intervallo di indirizzi IP in uscita pubblico. Per altre informazioni, vedere Restrizioni per le regole di rete IP.
  • collegamento privato e gli endpoint di servizio usano gli indirizzi IP privati delle istanze di macchine virtuali nella rete virtuale per connettersi ai servizi della piattaforma di Azure anziché all'indirizzo IP pubblico del gateway NAT. Usare collegamento privato per connettersi ad altri servizi di Azure tramite il backbone di Azure anziché tramite Internet con il gateway NAT.

Nota

collegamento privato è l'opzione consigliata sugli endpoint di servizio per l'accesso privato ai servizi ospitati in Azure.

errori di Connessione ion nella destinazione Internet pubblica

Scenario

Le connessioni gateway NAT alle destinazioni Internet hanno esito negativo o si verifica il timeout.

Possibili cause

  • Firewall o altri componenti di gestione del traffico nella destinazione.

  • Limitazione della velocità API imposta dal lato di destinazione.

  • Mitigazioni DDoSmetriche o modellazione del traffico del livello di trasporto.

  • L'endpoint di destinazione risponde con pacchetti frammentati.

Come risolvere i problemi

  • Verificare la connettività a un endpoint nella stessa area o altrove per un confronto.

  • Eseguire l'acquisizione di pacchetti dai lati di origine e destinazione.

  • Esaminare il numero di pacchetti nell'origine e nella destinazione (se disponibile) per determinare il numero di tentativi di connessione effettuati.

  • Esaminare i pacchetti eliminati per verificare il numero di pacchetti eliminati dal gateway NAT.

  • Analizzare i pacchetti. I pacchetti TCP con pacchetti di protocollo IP frammentati indicano la frammentazione IP. Il gateway NAT non supporta la frammentazione IP e pertanto le connessioni con pacchetti frammentati hanno esito negativo.

  • Assicurarsi che l'indirizzo IP pubblico del gateway NAT sia elencato come consentito nelle destinazioni partner con firewall o altri componenti di gestione del traffico.

Possibili soluzioni per gli errori di connessione nella destinazione Internet

  • Verificare che l'indirizzo IP pubblico del gateway NAT sia elencato come consentito nella destinazione.

  • Se si creano test di volumi elevati o della frequenza delle transazioni, verificare se la riduzione della frequenza comporta una riduzione degli errori.

  • Se la riduzione della frequenza delle connessioni riduce l'occorrenza di errori, verificare se la destinazione ha raggiunto i limiti di frequenza API o altri vincoli.

errori di Connessione ion nel server FTP per la modalità attiva o passiva

Scenario

Vengono visualizzati errori di connessione in un server FTP quando si usa il gateway NAT con modalità FTP attiva o passiva.

Possibili cause

  • La modalità FTP attiva è abilitata.

  • La modalità FTP passiva è abilitata e il gateway NAT usa più di un indirizzo IP pubblico.

Possibile soluzione per la modalità FTP attiva

FTP usa due canali separati tra un client e un server, il comando e i canali dati. Ogni canale comunica su connessioni TCP separate, una per l'invio dei comandi e l'altra per il trasferimento dei dati.

In modalità FTP attiva, il client stabilisce il canale di comando e il server stabilisce il canale dati.

Il gateway NAT non è compatibile con la modalità FTP attiva. Ftp attivo usa un comando PORT dal client FTP che indica al server FTP l'indirizzo IP e la porta da usare nel canale dati per la connessione al client. Il comando PORT usa l'indirizzo privato del client, che non può essere modificato. Il traffico sul lato client è SNATed dal gateway NAT per la comunicazione basata su Internet in modo che il comando PORT non sia valido dal server FTP.

Una soluzione alternativa alla modalità FTP attiva consiste nell'usare invece la modalità FTP passiva. Tuttavia, per usare il gateway NAT in modalità FTP passiva, è necessario tenere presenti alcune considerazioni .

Possibile soluzione per la modalità FTP passiva

In modalità FTP passiva, il client stabilisce le connessioni sia sui canali di comando che di dati. Il client richiede che il server risponda su una porta invece di tentare di stabilire una connessione al client.

FTP passivo in uscita non funziona per il gateway NAT con più indirizzi IP pubblici, a seconda della configurazione del server FTP. Quando un gateway NAT con più indirizzi IP pubblici invia il traffico in uscita, seleziona in modo casuale uno dei relativi indirizzi IP pubblici per l'indirizzo IP di origine. FTP ha esito negativo quando i canali di dati e di controllo usano indirizzi IP di origine diversi, a seconda della configurazione del server FTP.

Per evitare possibili errori di connessione FTP passiva, seguire questa procedura:

  1. Verificare che il gateway NAT sia collegato a un singolo indirizzo IP pubblico anziché a più indirizzi IP o a un prefisso.

  2. Assicurarsi che l'intervallo di porte passivo dal gateway NAT sia autorizzato a passare tutti i firewall nell'endpoint di destinazione.

Nota

La riduzione della quantità di indirizzi IP pubblici nel gateway NAT riduce l'inventario delle porte SNAT disponibile per l'esecuzione di connessioni in uscita e può aumentare il rischio di esaurimento delle porte SNAT. Prendere in considerazione le esigenze di connettività SNAT prima di rimuovere gli indirizzi IP pubblici dal gateway NAT. Non è consigliabile modificare le impostazioni del server FTP per accettare il traffico del controllo e del piano dati da indirizzi IP di origine diversi.

Le connessioni in uscita sulla porta 25 sono bloccate

Scenario

Impossibile connettersi in uscita con il gateway NAT sulla porta 25 per il traffico SMTP (Simple Mail Transfer Protocol).

Causa

La piattaforma Azure blocca le connessioni SMTP in uscita sulla porta TCP 25 per le macchine virtuali distribuite. Questo blocco consiste nel garantire una migliore sicurezza per i partner e i clienti Microsoft, proteggere la piattaforma Azure di Microsoft e conformarsi agli standard del settore.

Usare un servizio di inoltro SMTP autenticato per inviare messaggi di posta elettronica dalle macchine virtuali di Azure o dal servizio app Azure. Per altre informazioni, vedere Risolvere i problemi di connettività SMTP in uscita.

Altre informazioni sul materiale sussidiario sulla risoluzione dei problemi

Acquisizioni di rete aggiuntive

Se l'indagine non restituisce risultati, aprire un caso di supporto per un'ulteriore risoluzione dei problemi e raccogliere le informazioni seguenti per una risoluzione più rapida. Scegliere una singola macchina virtuale nella subnet configurata del gateway NAT ed eseguire i test seguenti:

  • Testare la risposta della porta probe usando ps ping una delle macchine virtuali back-end all'interno della rete virtuale e registrare i risultati (ad esempio: ps ping 10.0.0.4:3389).

  • Se non viene ricevuta alcuna risposta in questi test ping, eseguire una traccia simultanea netsh nella macchina virtuale back-end e la macchina virtuale di test della rete virtuale durante l'esecuzione di PsPing quindi arrestare la netsh traccia.

Procedure consigliate per la connettività in uscita

Azure monitora e gestisce la propria infrastruttura con molta attenzione. Tuttavia, gli errori temporanei possono comunque verificarsi dalle applicazioni distribuite e non esiste alcuna garanzia di trasmissioni senza perdita di dati. Il gateway NAT è l'opzione preferita per stabilire connettività in uscita altamente affidabile e resiliente dalle distribuzioni di Azure. Per ottimizzare l'efficienza della connessione dell'applicazione, vedere le indicazioni più avanti nell'articolo.

Utilizzare un pool di connessioni

Quando si esegue il pool delle connessioni, si evita di aprire nuove connessioni di rete per le chiamate allo stesso indirizzo e alla stessa porta. È possibile implementare uno schema di pool di connessioni nell'applicazione in cui le richieste vengono distribuite internamente in un set fisso di connessioni e riutilizzate quando possibile. Questa configurazione vincola il numero di porte SNAT in uso e crea un ambiente prevedibile. Connessione pooling consente di ridurre la latenza e l'utilizzo delle risorse e di migliorare le prestazioni delle applicazioni.

Per altre informazioni sul pool di connessioni HTTP, vedere Connessioni HTTP del pool con HttpClientFactory.

Riutilizzare le connessioni

Invece di generare connessioni TCP singole e atomice per ogni richiesta, configurare l'applicazione per riutilizzare le connessioni. Connessione riutilizzo comporta transazioni TCP più efficienti ed è particolarmente rilevante per i protocolli come HTTP/1.1, dove il riutilizzo della connessione è l'impostazione predefinita. Questo riutilizzo si applica ad altri protocolli che usano HTTP come trasporto, ad esempio REST.

Usare una logica di ripetizione dei tentativi meno aggressiva

Quando le porte SNAT vengono esaurite o si verificano errori dell'applicazione, tentativi aggressivi o di forza bruta senza ritardi e logica di back-off causano esaurimento o persistenza. È possibile ridurre la domanda di porte SNAT usando una logica di ripetizione dei tentativi meno aggressiva.

A seconda del timeout di inattività configurato, se i tentativi sono troppo aggressivi, le connessioni non hanno tempo sufficiente per chiudere e rilasciare porte SNAT per il riutilizzo.

Per altre indicazioni ed esempi, vedere Modello di ripetizione dei tentativi.

Usare keep-alive per reimpostare il timeout di inattività per le connessioni uscita

Per altre informazioni sui keepalives, vedere Timeout di inattività TCP.

Quando possibile, è consigliabile usare collegamento privato per connettersi direttamente dalle reti virtuali ai servizi della piattaforma Azure per ridurre la domanda sulle porte SNAT. La riduzione della domanda sulle porte SNAT può contribuire a ridurre il rischio di esaurimento delle porte SNAT.

Per creare un collegamento privato, vedere le guide introduttive seguenti per iniziare:

Passaggi successivi

Cerchiamo sempre di migliorare l'esperienza dei nostri clienti. Se si verificano problemi del gateway NAT non risolti o risolti da questo articolo, inviare commenti e suggerimenti tramite GitHub nella parte inferiore di questa pagina.

Per altre informazioni sul gateway NAT, vedere: