Questo articolo descrive come ridurre al minimo il consumo di spazio indirizzi privato quando si creano reti di grandi dimensioni in Azure. Potrebbe essere necessario ridurre al minimo l'utilizzo dello spazio degli indirizzi se non vengono stabiliti criteri di allocazione appropriati e si esauriscono gli indirizzi IP privati da assegnare alle reti virtuali di Azure. Questo articolo presenta due metodi per la corretta gestione degli indirizzi IP in Azure.
Dettagli dello scenario
Le reti aziendali usano in genere spazi di indirizzi che si trovano negli intervalli di indirizzi IPv4 privati definiti in RFC 1918. Gli intervalli di indirizzi sono 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Negli ambienti locali, questi intervalli forniscono indirizzi IP sufficienti per soddisfare i requisiti delle reti persino più grandi. Di conseguenza, molte organizzazioni sviluppano procedure di gestione degli indirizzi che assegnano priorità a configurazioni di routing semplici e processi agile per l'allocazione IP. L'uso efficiente dello spazio indirizzi non è una priorità.
Nel cloud, le reti ibride di grandi dimensioni sono facili da compilare e alcuni modelli architetturali comuni, come i microservizi o la containerizzazione, potrebbero comportare un aumento dell'utilizzo degli indirizzi IP. È quindi importante modificare queste procedure di gestione degli indirizzi. In un ambiente cloud considerare gli indirizzi IPv4 privati come una risorsa limitata.
Intervalli di indirizzi IP di Azure Rete virtuale
Nelle reti virtuali di Azure è consigliabile usare i blocchi di indirizzi definiti da RFC 1918. Questi blocchi di indirizzi sono destinati a reti private per utilizzo generico e non sono indirizzabili su Internet pubblico.
È possibile usare altri intervalli, ma prima di usare tali intervalli nella rete virtuale, leggere la documentazione di Internet Assigned Numbers Authority (IANA) per comprendere le potenziali implicazioni per l'ambiente. È possibile usare gli intervalli seguenti:
- Spazio indirizzi condiviso definito da RFC 6598 per NAT (Network Address Translation) di livello operatore considerato come spazio indirizzi privato in Azure Rete virtuale. Il blocco di indirizzi è 100.64.0.0/10.
- Indirizzi IP pubblici e instradabili da Internet di cui l'organizzazione non è proprietaria. Questa procedura è sconsigliata perché le risorse nella rete virtuale non possono accedere agli endpoint Internet esposti sugli indirizzi IP pubblici.
- Blocchi di indirizzi speciali definiti da IANA, ad esempio 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 e 233.252.0.0/24.
Nota
L'intervallo di indirizzi IP della classe E 240.0.0.0/4 è bloccato da Windows dall'assegnazione a una scheda di interfaccia di rete e presenta problemi di compatibilità nel caso di Linux. Pertanto, anche se potrebbe essere possibile assegnare l'intervallo a livello di codice a una rete virtuale, non è consigliabile usarlo nelle reti virtuali di Azure.
Nota
Gli intervalli precedenti non forniscono una soluzione a lungo termine per le organizzazioni con problemi di esaurimento IPv4. In tal caso, è consigliabile ridurre al minimo il consumo di spazio indirizzi privato.
Non è possibile usare gli intervalli di indirizzi IP seguenti nelle reti virtuali di Azure:
- 224.0.0.0/4 (multicast)
- 255.255.255.255/32 (broadcast)
- 127.0.0.0/8 (loopback)
- 169.254.0.0/16 (locale rispetto al collegamento)
- 168.63.129.16/32 (DNS interno)
Allineamento della zona di destinazione di Azure
Le raccomandazioni contenute in questo articolo sono per scenari basati sull'architettura della zona di destinazione di Azure. Le linee guida presuppongono che:
- Ogni area ha una topologia hub-spoke.
- Le reti hub-spoke che si trovano in aree diverse sono connesse tra loro tramite peering di rete virtuale globale o connessioni allo stesso circuito o circuito Azure ExpressRoute.
- Le reti hub-spoke sono connesse ai siti locali tramite una combinazione di circuiti ExpressRoute e VPN da sito a sito.
Il diagramma seguente illustra un'architettura di esempio. Le raccomandazioni sono ugualmente applicabili alle reti basate su Azure rete WAN virtuale, che dispone anche di reti hub-spoke in ogni area.
Scaricare un file PowerPoint di questa architettura.
In uno scenario basato sull'architettura della zona di destinazione di Azure, le applicazioni vengono distribuite nella propria zona di destinazione. Ogni zona di destinazione contiene una rete virtuale spoke con peering a un hub a livello di area. Le reti virtuali spoke sono parte integrante della rete aziendale e vengono assegnate indirizzi IPv4 instradabili. Questi indirizzi sono univoci nell'intera rete aziendale. Pertanto, tutti i componenti dell'architettura distribuiti in Azure Rete virtuale usano gli indirizzi IPv4 nello spazio indirizzi della rete aziendale anche se solo alcuni componenti espongono endpoint che devono essere raggiungibili dall'intera rete aziendale. Questi componenti dell'architettura possono essere macchine virtuali, appliance virtuali di terze parti o appliance virtuali di rete (NVA) o servizi PaaS (Platform-as-a-Service) inseriti nella rete virtuale.
Per la parte restante di questo articolo, il componente front-end fa riferimento a un componente dell'applicazione raggiungibile dall'intera rete aziendale o dall'esterno della zona di destinazione del componente. Il componente back-end fa riferimento a un componente dell'applicazione che non espone gli endpoint nella rete aziendale e deve essere raggiungibile solo dall'interno della propria zona di destinazione. Ad esempio, un'applicazione Web che espone un endpoint è un componente front-end e un database che non espone un endpoint è un componente back-end.
Le sezioni seguenti descrivono due metodi per ridurre al minimo il consumo di spazio indirizzi privato quando si creano reti di grandi dimensioni in Azure.
Metodo 1: reti virtuali spoke della zona di destinazione non indirizzabili
RFC 1918 blocca gli indirizzi IP fuori dallo spazio indirizzi IPv4 a 32 bit e li rende non indirizzabili su Internet pubblico, in modo da poterli riutilizzare in più reti private per la comunicazione interna. Questo metodo si basa sullo stesso principio che si applica allo spazio indirizzi privato. Uno o più intervalli di indirizzi vengono ritagliati dall'intero spazio indirizzi privato usato dall'organizzazione e dichiarato non indirizzabile all'interno della rete aziendale dell'organizzazione. Gli intervalli di indirizzi vengono riutilizzati in più zone di destinazione. Di conseguenza, ogni zona di destinazione:
- Viene assegnato uno spazio indirizzi instradabile costituito da uno o più intervalli di indirizzi. L'organizzazione gestisce centralmente gli intervalli di indirizzi e li assegna in modo univoco a una zona di destinazione per la comunicazione con la rete aziendale. Gli indirizzi nello spazio instradabile vengono assegnati ai componenti front-end.
- Può usare lo spazio indirizzi non indirizzabile, ovvero gli intervalli di indirizzi dichiarati dall'organizzazione non instradabili nella rete aziendale. È possibile usare questi intervalli riservati per la comunicazione interna in tutte le zone di destinazione. Gli indirizzi nello spazio non indirizzabile vengono assegnati ai componenti back-end.
In una rete hub-spoke di Azure gestita dal cliente o basata su rete WAN virtuale, due o più reti virtuali spoke non possono avere spazi di indirizzi IP sovrapposti. I blocchi di indirizzi non indirizzabili non possono essere assegnati a uno spoke della zona di destinazione. Il peering di rete virtuale non è transitivo, quindi una rete virtuale spoke della zona di destinazione può eseguire il peering con una rete virtuale spoke di secondo livello con uno spazio indirizzi non indirizzabile. Il diagramma seguente illustra la topologia di rete virtuale doppia per le zone di destinazione.
Scaricare un file PowerPoint di questa architettura.
Ogni zona di destinazione dell'applicazione contiene due reti virtuali con peering. Una rete virtuale include indirizzi IP instradabili e ospita componenti front-end. L'altra rete virtuale include indirizzi IP non indirizzabili e ospita componenti back-end. Peer della zona di destinazione instradabile con l'hub regionale. Peer della zona di destinazione non instradabile con lo spoke della zona di destinazione instradabile. Il peering di rete virtuale non è transitivo, quindi i prefissi non indirizzabili non sono visibili all'hub di area o al resto della rete aziendale. Le reti virtuali instradabili non possono usare gli intervalli di indirizzi non indirizzabili. Alcune organizzazioni hanno uno spazio indirizzi frammentato già assegnato alle reti instradabili. Può essere difficile identificare blocchi di indirizzi di grandi dimensioni inutilizzati e dichiararli non indirizzabili. In tal caso, prendere in considerazione gli indirizzi inutilizzati che non sono inclusi nello spazio indirizzi RFC 1918. Il diagramma precedente fornisce un esempio di indirizzi NAT di livello carrier, ad esempio RFC 6598, in reti virtuali spoke nonroutable.
Migrazione di una singola zona di destinazione della rete virtuale
Il peering di rete virtuale offre connettività completa di livello 3 tra due reti virtuali con peering. I componenti dell'applicazione distribuiti nelle tradizionali zone di destinazione di rete virtuale singola che comunicano tra loro tramite IP possono essere spostati liberamente tra reti virtuali spoke instradabili e non instradabili in una zona di destinazione. Questa sezione descrive due modelli di migrazione tipici.
Le applicazioni seguenti vengono esposte tramite controller di recapito delle applicazioni di livello 7:
Scaricare un file PowerPoint di questa architettura.
Le applicazioni esposte tramite controller di recapito delle applicazioni di livello 7 possono essere spostate nello spoke non instradabile. Il controller di recapito dell'applicazione è l'unico componente front-end che deve risiedere nello spoke della zona di destinazione instradabile.
Le applicazioni seguenti vengono esposte tramite un servizio di bilanciamento del carico di Azure:
Scaricare un file PowerPoint di questa architettura.
Se un'applicazione espone gli endpoint tramite un servizio di bilanciamento del carico di Azure, le istanze di calcolo che fanno parte del pool back-end del servizio di bilanciamento del carico devono rimanere nella stessa rete virtuale. I servizi di bilanciamento del carico di Azure supportano solo le istanze back-end nella propria rete virtuale.
Dipendenze in uscita
I componenti back-end di un'applicazione non devono essere raggiungibili o ricevere connessioni in ingresso dalla rete aziendale, ma spesso hanno dipendenze in uscita. I componenti back-end potrebbero dover connettersi agli endpoint esterni alle zone di destinazione in istanze come la risoluzione DNS, i controller di dominio Dominio di Active Directory Services, l'accesso agli endpoint dell'applicazione esposti da altre zone di destinazione o l'accesso alle funzionalità di registrazione o backup.
Nota
La comunicazione da client a Dominio di Active Directory Services (ADDS) Domain Controller (DCS) tramite NAT è stata testata ed è supportata, la comunicazione da controller di dominio a controller di dominio non è stata testata e non è supportata come descritto più dettagliatamente in Descrizione dei limiti di supporto per Active Directory su NAT
Quando i servizi avviano connessioni in reti virtuali spoke nonroutable, è necessario implementare nat di origine (SNAT) per le connessioni dietro un indirizzo IP instradabile. Per implementare SNAT, distribuire un dispositivo compatibile con NAT nella rete virtuale spoke instradabile. Ogni zona di destinazione esegue un'appliance virtuale di rete NAT dedicata. Esistono due opzioni per l'implementazione di SNAT in una zona di destinazione: Firewall di Azure o appliance virtuali di rete di terze parti. In entrambi i casi, tutte le subnet nello spoke non indirizzabile devono essere associate a una tabella di route personalizzata. Come illustrato nel diagramma seguente, la tabella di route inoltra il traffico alle destinazioni esterne alla zona di destinazione al dispositivo SNAT. Il gateway NAT di Azure non supporta SNAT per il traffico destinato allo spazio indirizzi IP privato, ad esempio lo spazio RFC 1918.
Scaricare un file PowerPoint di questa architettura.
Implementare SNAT tramite Firewall di Azure
Firewall di Azure:
- Offre disponibilità elevata.
- Offre scalabilità nativa e tre SKU diversi. SNAT non è un'attività a elevato utilizzo di risorse, quindi considerare prima lo SKU di base. Per le zone di destinazione che richiedono volumi elevati di traffico in uscita dallo spazio indirizzi non indirizzabile, usare lo SKU standard.
- Esegue SNAT per il traffico dietro gli indirizzi IP privati di una delle relative istanze. Ogni istanza può usare tutte le porte non privilegiate.
Il diagramma seguente illustra il layout della zona di destinazione per implementare SNAT in una topologia di rete hub-spoke usando Firewall di Azure.
Scaricare un file PowerPoint di questa architettura.
È necessario associare tutte le subnet nello spoke nonroutable a una tabella di route personalizzata per inviare il traffico alle destinazioni esterne alla zona di destinazione a Firewall di Azure.
Il diagramma seguente illustra il layout della zona di destinazione per implementare SNAT in una rete hub-spoke basata su rete WAN virtuale usando Firewall di Azure.
Scaricare un file PowerPoint di questa architettura.
È necessario associare tutte le subnet nello spoke non instradabile o gli spoke non connessi a rete WAN virtuale, con una tabella di route personalizzata per inviare il traffico a destinazioni esterne alla zona di destinazione a Firewall di Azure.
Per entrambi i layout, per fornire risorse nell'accesso spoke non instradabile agli indirizzi IP instradabili all'esterno della propria zona di destinazione, è necessario distribuire Firewall di Azure con l'opzione Esegui SNAT impostata su Always in ogni area di destinazione spoke instradabile. È possibile trovare istruzioni su come configurare Firewall di Azure per implementare SNAT in tutte le connessioni ricevute nella documentazione pubblica. Lo screenshot seguente mostra la configurazione necessaria per l'uso di Firewall di Azure come dispositivo NAT per le connessioni avviate dalle risorse nelle reti virtuali spoke nonroutable.
Implementare SNAT tramite appliance virtuali di rete di terze parti
Le appliance virtuali di rete di terze parti con funzionalità NAT sono disponibili in Azure Marketplace. Offrono le caratteristiche seguenti:
- Controllo granulare su scalabilità orizzontale e scalabilità orizzontale.
- Controllo granulare del pool NAT.
- Criteri NAT personalizzati, ad esempio l'uso di indirizzi NAT diversi a seconda delle proprietà della connessione in ingresso, ad esempio l'indirizzo IP di origine o di destinazione.
Prendi in considerazione le seguenti raccomandazioni:
- Per la disponibilità elevata, distribuire cluster con almeno due appliance virtuali di rete. Usare un servizio di bilanciamento del carico di Azure per distribuire le connessioni in ingresso dalla rete virtuale spoke nonroutable alle appliance virtuali di rete. È necessaria una regola di bilanciamento del carico delle porte a disponibilità elevata perché il cluster implementa SNAT in tutte le connessioni che lasciano la zona di destinazione. Azure Load Balancer Standard supporta regole di bilanciamento del carico delle porte a disponibilità elevata.
- Lo stack SDN di Azure supporta appliance virtuali di rete a braccio singolo e dual-arm. Le appliance virtuali di rete a braccio singolo sono preferite perché riducono il consumo di spazio degli indirizzi nelle reti virtuali spoke instradabili.
Il diagramma seguente illustra il layout della zona di destinazione per implementare SNAT in una topologia di rete hub-spoke usando appliance virtuali di rete di terze parti.
Scaricare un file PowerPoint di questa architettura.
Il diagramma seguente illustra il layout della zona di destinazione per implementare SNAT in una topologia di rete hub-spoke basata su rete WAN virtuale tramite appliance virtuali di rete di terze parti.
Scaricare un file PowerPoint di questa architettura.
Per entrambi i layout di appliance virtuali di rete di terze parti, è necessario distribuire più istanze dietro un servizio di bilanciamento del carico di Azure per offrire disponibilità elevata. È necessario lo SKU Standard di Azure Load Balancer.
Metodo 2: collegamento privato di Azure servizi
collegamento privato fornisce l'accesso alle applicazioni distribuite in una rete virtuale non connessa alla rete virtuale. Nella rete virtuale sul lato server o sull'applicazione viene distribuito un servizio collegamento privato e associato a un endpoint applicazione esposto nell'indirizzo IP front-end di un servizio di bilanciamento del carico interno dello SKU Standard di Azure. Nella rete virtuale lato client viene distribuita una risorsa endpoint privato e associata al servizio collegamento privato. L'endpoint privato espone l'endpoint dell'applicazione nelle reti virtuali. collegamento privato fornisce la logica di tunneling e NAT per instradare il traffico tra il lato client e il lato server. Per altre informazioni, vedere Che cos'è Collegamento privato di Azure?.
collegamento privato non richiede una connessione di livello 3 tra la rete virtuale lato client e la rete virtuale lato server. Le due reti virtuali possono avere spazi di indirizzi IP sovrapposti. collegamento privato consente la distribuzione di applicazioni in reti virtuali dedicate isolate, tutte usando lo stesso spazio indirizzi non indirizzabile. Le applicazioni vengono esposte come servizi collegamento privato nella rete aziendale, che usa uno spazio indirizzi instradabile. Nel contesto dell'architettura della zona di destinazione di Azure, la topologia della zona di destinazione risultante ha:
- Una rete virtuale isolata che ospita l'intera applicazione e il servizio collegamento privato associato agli endpoint dell'applicazione. Il team dell'applicazione definisce lo spazio degli indirizzi della rete virtuale.
- Una rete virtuale spoke con uno spazio indirizzi instradabile che ospita l'endpoint privato associato al servizio collegamento privato. La rete virtuale spoke è con peering diretto con l'hub a livello di area.
Il diagramma seguente illustra la topologia della zona di destinazione abilitata per collegamento privato.
Scaricare un file PowerPoint di questa architettura.
Usare un servizio collegamento privato per le dipendenze in uscita
Quando si distribuiscono applicazioni in reti virtuali spoke isolate, usare un servizio collegamento privato per le dipendenze in uscita. Definire gli endpoint privati nella rete virtuale spoke isolata e associarli a un servizio collegamento privato nelle reti virtuali instradabili. Il diagramma seguente illustra l'approccio concettuale.
Scaricare un file PowerPoint di questa architettura.
Nelle implementazioni su larga scala reali, il metodo collegamento privato potrebbe non essere applicabile:
- Se le applicazioni distribuite nella rete virtuale isolata hanno più dipendenze in uscita. Quando si distribuisce un servizio collegamento privato e un endpoint privato per ognuna delle dipendenze in uscita, aumenta la complessità e le esigenze di gestione.
- Se la dipendenza in uscita include endpoint nella rete instradabile che non possono far parte di un pool back-end di Azure Load Balancer, collegamento privato non è applicabile.
Per superare queste due limitazioni, distribuire una soluzione proxy/NAT nello spoke instradabile e renderla accessibile dalla rete virtuale isolata usando collegamento privato.
Scaricare un file PowerPoint di questa architettura.
Usare un singolo endpoint privato o collegamento privato servizio per esporre una soluzione proxy/NAT distribuita nella rete instradabile. Le regole di conversione e conversione degli indirizzi vengono definite nelle appliance virtuali di rete. Queste regole consentono l'uso di un singolo endpoint privato nella rete virtuale isolata per accedere a più dipendenze nella rete instradabile.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autori principali:
- Federico Guerrini | Responsabile tecnico EMEA
- Sh Kaviraj | Cloud Solution Architect
- Jack Tracey | Senior Cloud Solution Architect
Altri collaboratori:
- Jodi Martis | Writer tecnico
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Distribuire Firewall di Azure in una rete virtuale
- Configurare SNAT in Firewall di Azure
- Indirizzi IP supportati in Azure Rete virtuale
- Collegamento privato di Azure
- Azure Load Balancer
- Peering di rete virtuale