Questo articolo illustra le procedure consigliate per un gateway NAT di Azure. Le linee guida si basano sui cinque pilastri dell'eccellenza dell'architettura: Ottimizzazione dei costi, Eccellenza operativa, Efficienza delle prestazioni, Affidabilità e Sicurezza.
Si supponga di avere una conoscenza funzionante del gateway NAT di Azure e di avere una conoscenza approfondita delle rispettive funzionalità. Come aggiornamento, vedere il set completo della documentazione del gateway NAT di Azure.
NAT è l'acronimo di Network Address Translation. Vedere Introduzione a Network Address Translation.
Ottimizzazione dei costi
L'accesso ai servizi PaaS deve essere tramite collegamento privato di Azure o endpoint di servizio (inclusa l'archiviazione), per evitare l'uso di un gateway NAT. collegamento privato e gli endpoint di servizio non richiedono l'attraversamento del gateway NAT per accedere ai servizi PaaS. Questo approccio ridurrà l'addebito per GB di dati elaborati, confrontando i costi di un gateway NAT con collegamento privato o con gli endpoint di servizio. Esistono vantaggi aggiuntivi per la sicurezza per l'uso di collegamento privato o endpoint di servizio.
Efficienza prestazionale
Ogni risorsa gateway NAT offre fino a 50 Gbps di velocità effettiva. È possibile suddividere le distribuzioni in più subnet e quindi assegnare a ogni subnet o gruppo di subnet un gateway NAT per aumentare il numero di istanze.
Ogni indirizzo IP pubblico del gateway NAT offre fino a 64.512 porte SNAT. È possibile assegnare fino a 16 indirizzi IP a un gateway NAT. Gli indirizzi IP possono essere singoli indirizzi IP pubblici standard, il prefisso IP pubblico o entrambi. Per le connessioni che passano allo stesso endpoint di destinazione, il gateway NAT può supportare fino a 50.000 flussi simultanei rispettivamente per TCP e UDP, per ogni indirizzo IP in uscita assegnato. Per informazioni dettagliate, vedere la sezione seguente in Source Network Address Translation (SNAT). TCP è l'acronimo di Transmission Control Protocol e UDP è l'acronimo di User Datagram Protocol.
Esaurimento SNAT
- Le risorse del gateway NAT hanno un timeout di inattività TCP predefinito di 4 minuti che può essere configurato fino a 120 minuti. Se questa impostazione viene modificata in un valore superiore rispetto all'impostazione predefinita, il gateway NAT mantiene i flussi più a lungo e può causare un utilizzo eccessivo dell'inventario delle porte SNAT.
- Le richieste atomiche (una richiesta per connessione) sono una scelta di progettazione scarsa, perché limita la scalabilità, riduce le prestazioni e riduce l'affidabilità. Riutilizzare invece le connessioni HTTP/S per ridurre il numero di connessioni e le porte SNAT associate. Connessione riutilizzo migliorerà la scalabilità dell'applicazione. Le prestazioni dell'applicazione miglioreranno, a causa di una riduzione dei costi di handshake, overhead e operazioni di crittografia quando si usa TLS.
- Le ricerche DNS (Domain Name System) possono introdurre molti singoli flussi al volume, quando il client non memorizza nella cache il risultato dei resolver DNS. Usare la memorizzazione nella cache DNS per ridurre il volume dei flussi e ridurre il numero di porte SNAT. DNS è il sistema di denominazione che esegue il mapping dei nomi di dominio agli indirizzi IP per le risorse connesse a Internet o a una rete privata.
- I flussi UDP, ad esempio le ricerche DNS, usano le porte SNAT durante il timeout di inattività. Il timer di timeout di inattività UDP è fisso a 4 minuti e non può essere modificato.
- Usare i pool di connessioni per definire il volume di connessioni.
- Non abbandonare mai un flusso TCP e non fare affidamento sui timer TCP per pulire il flusso. Se non si consente a TCP di chiudere in modo esplicito la connessione, la connessione TCP rimane aperta. I sistemi intermedi e gli endpoint manterranno questa connessione in uso, che a sua volta rende la porta SNAT non disponibile per altre connessioni. Questo anti-pattern può attivare errori dell'applicazione e esaurimento SNAT.
- Non modificare i valori del timer correlati a tcp-close a livello di sistema operativo, senza conoscere con esperti le implicazioni. Mentre lo stack TCP verrà ripristinato, le prestazioni dell'applicazione possono essere influenzate negativamente quando gli endpoint di una connessione non corrispondono alle aspettative. La modifica dei valori timer è in genere un segno di un problema di progettazione sottostante. Se l'applicazione sottostante ha altri anti-pattern, l'esaurimento SNAT può essere amplificato anche se i valori del timer vengono modificati.
Esaminare le indicazioni seguenti per migliorare la scalabilità e l'affidabilità del servizio:
- Esplorare l'effetto della riduzione del timeout di inattività TCP a valori inferiori. Un timeout di inattività predefinito di 4 minuti può liberare l'inventario delle porte SNAT in precedenza.
- Prendere in considerazione i modelli di polling asincroni per le operazioni a esecuzione prolungata per liberare le risorse di connessione per altre operazioni.
- I flussi di lunga durata, ad esempio le connessioni TCP riutilizzate, devono usare keep-alives TCP o keep-layer dell'applicazione per evitare il timeout dei sistemi intermedi. È consigliabile aumentare solo il timeout di inattività come ultima risorsa e potrebbe non risolvere la causa radice. Un timeout lungo può causare errori a bassa frequenza, quando scade il timeout e può introdurre un ritardo e errori non necessari. I keep-alive TCP possono essere abilitati da un lato della connessione per mantenere attiva una connessione da entrambi i lati.
- Per i flussi di lunga durata con il traffico UDP, è possibile abilitare i keep-end UDP per mantenere attive le connessioni. Tenere presente che i keep-up UDP abilitati su un lato della connessione mantengono attiva solo la connessione da un lato. I keep-up UDP devono essere abilitati su entrambi i lati di una connessione per mantenere attiva una connessione.
- È consigliabile usare i criteri di ripetizione dei tentativi per evitare tentativi o picchi aggressivi durante errori temporanei o ripristini da errori. Un antipattern, denominato connessioni atomiche, è quando si crea una nuova connessione TCP per ogni operazione HTTP. Le connessioni atomiche impediranno all'applicazione di ridimensionarsi correttamente e dispendiose le risorse. Concatenare sempre più operazioni nella stessa connessione. L'applicazione otterrà un vantaggio in termini di velocità delle transazioni e costi delle risorse. Quando l'applicazione usa la crittografia del livello di trasporto (ad esempio, TLS), esiste un costo significativo associato all'elaborazione di nuove connessioni. Per altri modelli di procedure consigliate, vedere Modelli di progettazione cloud di Azure.
Eccellenza operativa
Anche se il gateway NAT può essere usato con servizio Azure Kubernetes (servizio Azure Kubernetes), non è gestito come parte del servizio Azure Kubernetes. Se si assegna un gateway NAT alla subnet CNI (Container Networking Interface), si abiliterà i pod del servizio Azure Kubernetes in uscita tramite il gateway NAT.
Quando si usano più gateway NAT tra zone o aree, mantenere gestibile l'ambiente IP in uscita usando prefissi IP pubblici di Azure o prefissi BYOIP. Non è possibile assegnare al gateway NAT una dimensione del prefisso IP maggiore di 16 indirizzi IP (/28 dimensioni del prefisso).
Usare gli avvisi di Monitoraggio di Azure per monitorare e avvisare l'utilizzo delle porte SNAT, i pacchetti elaborati o eliminati e la quantità di dati trasmessi. Usare i log dei flussi del gruppo di sicurezza di rete per monitorare il flusso del traffico in uscita dalle istanze di macchine virtuali in una subnet configurata dal gateway NAT.
Quando una subnet è configurata con un gateway NAT, il gateway NAT sostituirà tutte le altre connessioni in uscita a Internet pubblico per tutte le macchine virtuali in tale subnet. Il gateway NAT avrà la precedenza su un servizio di bilanciamento del carico con o senza regole in uscita e sugli indirizzi IP pubblici assegnati direttamente alle macchine virtuali. Azure tiene traccia della direzione di un flusso e il routing asimmetrico non si verificherà. Il traffico originato in ingresso verrà convertito correttamente, ad esempio un indirizzo IP front-end del servizio di bilanciamento del carico, che verrà convertito separatamente dal traffico originato in uscita tramite un gateway NAT. Questa separazione consente ai servizi in ingresso e in uscita di coesistere senza problemi.
Il gateway NAT è consigliato come impostazione predefinita per abilitare la connettività in uscita per le reti virtuali. Il gateway NAT è più efficiente e meno operativo rispetto ad altre tecniche di connettività in uscita in Azure. I gateway NAT allocano porte SNAT su richiesta e usano un algoritmo più efficiente per evitare conflitti di riutilizzo delle porte SNAT. Non fare affidamento sulla connettività in uscita predefinita (un anti-modello) per l'ambiente. Al contrario, definirlo in modo esplicito con le risorse del gateway NAT.
Affidabilità
Le risorse del gateway NAT sono a disponibilità elevata in una zona di disponibilità e si estendono su più domini di errore. Il gateway NAT può essere distribuito in "nessuna zona" in cui Azure seleziona automaticamente una zona per posizionare il gateway NAT. Il gateway NAT può anche essere isolato in una zona specifica da un utente.
Non è possibile fornire l'isolamento della zona di disponibilità, a meno che ogni subnet non disponga solo di risorse all'interno di una zona specifica. Distribuire invece una subnet per ognuna delle zone di disponibilità in cui vengono distribuite le macchine virtuali, allineare le macchine virtuali di zona con i gateway NAT di zona corrispondenti e creare stack di zona separati. Ad esempio, una macchina virtuale nella zona di disponibilità 1 si trova in una subnet con altre risorse che si trovano anche nella zona di disponibilità 1. Un gateway NAT è configurato nella zona di disponibilità 1 per gestire tale subnet. Vedere il diagramma seguente.
Le reti virtuali e le subnet si estendono su tutte le zone di disponibilità in un'area. Non è quindi necessario suddividerle in base alle zone di disponibilità per supportare le risorse di zona.
Sicurezza
Con il gateway NAT, le singole macchine virtuali (o altre risorse di calcolo) non necessitano di indirizzi IP pubblici e possono rimanere completamente private. Le risorse senza un indirizzo IP pubblico possono comunque raggiungere origini esterne all'esterno della rete virtuale. È possibile associare un prefisso IP pubblico per assicurarsi che venga usato un set contiguo di indirizzi IP per la connettività in uscita. Le regole del firewall di destinazione possono essere configurate in base a questo elenco di indirizzi IP prevedibili.
Un approccio comune consiste nel progettare uno scenario di appliance virtuale di rete (NVA) solo in uscita con firewall di terze parti o con server proxy. Quando un gateway NAT viene distribuito in una subnet con un set di scalabilità di macchine virtuali di rete, tali appliance virtuali di rete useranno gli indirizzi del gateway NAT per la connettività in uscita, anziché l'IP di un servizio di bilanciamento del carico o i singoli indirizzi IP. Per usare questo scenario con Firewall di Azure, vedere Integrare Firewall di Azure con Azure Load Balancer Standard.
Microsoft Defender per il cloud possibile monitorare qualsiasi connettività in uscita sospetta tramite un gateway NAT. Si tratta di una funzionalità di avviso in Microsoft Defender per il cloud.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Ethan Haslett | Senior Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Microsoft Well-Architected Framework
- Esercitazione: Creare un gateway NAT usando il portale di Azure