Pianificazione dell'indirizzamento IP

È importante che la tua organizzazione pianifichi l'indirizzamento IP in Azure. La pianificazione garantisce che lo spazio degli indirizzi IP non si sovrapponga a posizioni locali e aree di Azure.

considerazioni sulla progettazione di :

• La sovrapposizione degli spazi degli indirizzi IP tra le aree locali e di Azure crea importanti problemi di contesa.

• Il gateway VPN di Azure può connettere siti locali sovrapposti con spazi di indirizzi IP sovrapposti tramite la funzionalità NAT (Network Address Translation). Questa funzionalità è disponibile a livello generale nella rete WAN virtuale di Azure e nel gateway VPN di Azure autonomo.

  

• È possibile aggiungere spazio indirizzi dopo aver creato una rete virtuale. Questo processo non richiede un'interruzione se la rete virtuale è già connessa a un'altra rete virtuale tramite peering di rete virtuale. Ogni peering remoto richiede invece un'operazione di risincronizzazione eseguita dopo la modifica dello spazio di rete.

• Azure riserva cinque indirizzi IP all'interno di ogni subnet. Tenere conto di questi indirizzi quando si ridimensionano le reti virtuali e le subnet incluse.

• Alcuni servizi di Azure richiedono subnet dedicate. Questi servizi includono Firewall di Azure e gateway VPN di Azure.

• È possibile delegare le subnet a determinati servizi per creare istanze di un servizio all'interno della subnet.

Consigli per la progettazione:

• Pianificare in anticipo spazi di indirizzi IP non sovrapposti tra aree di Azure e posizioni locali.

• Usare gli indirizzi IP dell'allocazione degli indirizzi per Internet privato, noti come indirizzi RFC 1918.

• Non usare gli intervalli di indirizzi seguenti:

  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (trasmissione)
  • 127.0.0.0/8 (collegamento di ritorno)
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (DNS interno)

• Per gli ambienti con disponibilità limitata di indirizzi IP privati, è consigliabile usare IPv6. Le reti virtuali possono essere solo IPv4 o dual stack IPv4+IPv6.

  

• Non creare reti virtuali di grandi dimensioni, ad esempio /16. Garantisce che lo spazio degli indirizzi IP non venga sprecato. La subnet IPv4 più piccola supportata è /29e la più grande è /2 quando si usano definizioni di subnet CIDR (Classless Inter-Domain Routing). Le subnet IPv6 devono avere dimensioni identiche /64 .

• Non creare reti virtuali senza pianificare in anticipo lo spazio indirizzi richiesto.

• Non usare indirizzi IP pubblici per le reti virtuali, soprattutto se gli indirizzi IP pubblici non appartengono all'organizzazione.

• Tenere in considerazione i servizi che si intende usare, esistono alcuni servizi con indirizzi IP riservati, ad esempio il servizio Azure Kubernetes Service con la rete CNI.

• Usare reti virtuali spoke non instradabili per la zona di atterraggio e il servizio Azure Private Link per evitare l'esaurimento di IPv4.

Considerazioni su IPv6

Un numero crescente di organizzazioni sta adottando IPv6 negli ambienti. Questa adozione è guidata dall'esaurimento dello spazio IPv4 pubblico, dalla scarsità di IPv4 privata, soprattutto all'interno di reti su larga scala e dalla necessità di fornire connettività ai client solo IPv6. Non esiste un approccio universale per l'adozione di IPv6. Esistono tuttavia procedure consigliate che è possibile seguire quando si pianifica IPv6 e la si implementa nelle reti di Azure esistenti.

Microsoft Cloud Adoption Framework per Azure consente di comprendere le considerazioni da tenere in considerazione quando si creano sistemi nel cloud. Per informazioni sulle procedure consigliate per l'architettura per la progettazione di sistemi sostenibili, vedere Principi di progettazione della zona di destinazione di Azure. Per consigli approfonditi e procedure consigliate relative all'architettura cloud, incluse le distribuzioni dell'architettura di riferimento, i diagrammi e le guide, vedere la guida al Centro architetture per IPv6.

considerazioni sulla progettazione di :

• Fase dell'adozione di IPv6. In base alle esigenze aziendali, implementare IPv6 dove necessario. Tenere presente che IPv4 e IPv6 possono coesistere purché sia necessario.

• Negli scenari in cui le applicazioni si basano su servizi IaaS (Infrastructure as a Service) con supporto IPv6 completo, ad esempio macchine virtuali, è possibile usare end-to-end nativo IPv4 e IPv6. Questa configurazione evita complicazioni di conversione e fornisce la maggior parte delle informazioni al server e all'applicazione.

  È possibile distribuire Basic-SKU servizi di bilanciamento del carico di Azure con connessione Internet con un indirizzo IPv6. Questa configurazione consente la connettività IPv6 end-to-end nativa tra la rete Internet pubblica e le macchine virtuali di Azure tramite il servizio di bilanciamento del carico. Questo approccio facilita anche le connessioni end-to-end native tra le macchine virtuali e i client abilitati per IPv6 sulla rete Internet pubblica. Si noti che questo approccio richiede che ogni dispositivo nel percorso gestisca il traffico IPv6.

  L'approccio end-to-end nativo è più utile per la comunicazione da server a server diretto o da client a server. Non è utile per la maggior parte dei servizi Web e delle applicazioni, che in genere sono protetti da firewall, web application firewall o proxy inversi.

• Alcune distribuzioni e applicazioni complesse che usano una combinazione di servizi di terze parti, servizi PaaS (Platform as a Service) e soluzioni back-end potrebbero non supportare IPv6 nativo. In questi casi, è necessario usare NAT/NAT64 o una soluzione proxy IPv6 per abilitare la comunicazione tra IPv6 e IPv4.

• Quando la complessità dell'architettura dell'applicazione o altri fattori come i costi di formazione sono considerati significativi, potrebbe essere consigliabile continuare a usare un'infrastruttura nel backend solo IPv4 e distribuire un'appliance di rete virtuale (NVA) di terze parti con un gateway dual-stack IPv4/IPv6 per l'erogazione dei servizi.

  Una distribuzione tipica che usa un'appliance virtuale di rete potrebbe essere simile alla seguente:

  

Consigli per la progettazione:

Ecco un'analisi più attenta dell'aspetto di un'architettura tipica:

• Distribuire l'appliance virtuale di rete nei set di scalabilità di macchine virtuali con orchestrazione flessibile (VMSS Flex) per la resilienza ed esporle a Internet tramite Azure Load-Balancer, che ha un front-end con indirizzo IP pubblico.

  L'NVA accetta il traffico IPv4 e IPv6 e lo converte in traffico solo IPv4 per accedere all'applicazione nella subnet dell'applicazione. L'approccio riduce la complessità per il team dell'applicazione e riduce la superficie di attacco.

• Distribuire Frontdoor di Azure per fornire il routing globale per il traffico Web.

  Le funzionalità di Frontdoor di Azure includono il proxy di richieste client IPv6 e il traffico verso un back-end solo IPv4, come illustrato di seguito:

  

Queste sono le differenze principali tra l'approccio NVA e l'approccio Azure Front Door:

• Le appliance virtuali di rete sono gestite dal cliente, funzionano al livello 4 del modello OSI e possono essere distribuite nella stessa rete virtuale di Azure dell'applicazione, con un'interfaccia privata e pubblica.
• Frontdoor di Azure è un servizio PaaS di Azure globale e funziona al livello 7 (HTTP/HTTPS). Il back-end dell'applicazione è un servizio con connessione Internet che può essere bloccato per accettare solo il traffico proveniente da Frontdoor di Azure.

In ambienti complessi è possibile usare una combinazione di entrambi. Le NVAs sono utilizzate all'interno di una distribuzione regionale. Azure Front Door viene usato per instradare il traffico verso una o più distribuzioni regionali in diverse regioni di Azure o in altre posizioni accessibili da Internet. Per determinare la soluzione migliore, è consigliabile esaminare le funzionalità di Frontdoor di Azure e la documentazione del prodotto.

Blocchi CIDR della rete virtuale IPv6:

• È possibile associare un singolo blocco IPv6 Classless Inter-Domain Routing (CIDR) quando si crea una nuova rete virtuale in una distribuzione di Azure esistente nella sottoscrizione. Le dimensioni della subnet per IPv6 devono essere /64. L'uso di queste dimensioni garantisce una compatibilità futura se si decide di abilitare il routing della subnet a una rete locale. Alcuni router possono accettare solo route IPv6 /64.
• Se si dispone di una rete virtuale esistente che supporta solo IPv4 e le risorse nella subnet configurate per l'uso solo di IPv4, è possibile abilitare il supporto IPv6 per la rete virtuale e le risorse. La rete virtuale può funzionare in modalità dual stack, che consente alle risorse di comunicare tramite IPv4, IPv6 o entrambi. Le comunicazioni IPv4 e IPv6 sono indipendenti l'una dall'altra.
• Non è possibile disabilitare il supporto IPv4 per la rete virtuale e le subnet. IPv4 è il sistema di indirizzamento IP predefinito per le reti virtuali di Azure.
• Associare un blocco CIDR IPv6 alla rete virtuale e alla sottorete o utilizzare BYOIP IPv6. La notazione CIDR è un metodo che rappresenta un indirizzo IP e la relativa maschera di rete. I formati di questi indirizzi sono i seguenti:
  • Un singolo indirizzo IPv4 è a 32 bit, con quattro gruppi di fino a tre cifre decimali. Ad esempio: 10.0.1.0.
  • Un blocco CIDR IPv4 ha quattro gruppi di fino a tre cifre decimali, da 0 a 255, separati da punti e seguiti da una barra e da un numero compreso tra 0 e 32. Ad esempio: 10.0.0.0/16.
  • Un singolo indirizzo IPv6 è a 128 bit. Ha otto gruppi di quattro cifre esadecimali. Ad esempio: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Un blocco CIDR IPv6 ha quattro gruppi di fino a quattro cifre esadecimali, separate da due punti, seguite da due punti e quindi da una barra e da un numero compreso tra 1 e 128. Ad esempio: 2001:db8:1234:1a00::/64.
• Aggiornare le tabelle di route per instradare il traffico IPv6. Per il traffico pubblico, creare una route che instrada tutto il traffico IPv6 dalla subnet al gateway VPN o a un gateway Azure ExpressRoute.
• Aggiornare le regole del gruppo di sicurezza per includere le regole per gli indirizzi IPv6. In questo modo si consente al traffico IPv6 di transitare da e verso le istanze. Se sono presenti regole del gruppo di sicurezza di rete per controllare il flusso del traffico da e verso la subnet, è necessario includere regole per il traffico IPv6.
• Se il tipo di istanza non supporta IPv6, usare dual stack o distribuire un'appliance virtuale di rete, come descritto in precedenza, che traduce da IPv4 a IPv6.

Strumenti di Gestione indirizzi IP

L'uso di uno strumento di Gestione indirizzi IP può essere utile per la pianificazione degli indirizzi IP in Azure, perché offre una gestione centralizzata e visibilità, impedendo sovrapposizioni e conflitti negli spazi degli indirizzi IP. Questa sezione illustra le considerazioni e i consigli essenziali quando si adotta uno strumento di Gestione indirizzi IP.

considerazioni sulla progettazione di :

Numerosi strumenti IPAM sono disponibili per la vostra valutazione, a seconda delle vostre esigenze e delle dimensioni della vostra organizzazione. Le opzioni si estendono dalla disponibilità di un inventario di base basato su Excel a una soluzione open source guidata dalla community o prodotti aziendali completi con funzionalità e supporto avanzati.

• Considerare questi fattori quando si valuta lo strumento di Gestione indirizzi IP da implementare:

  • Funzionalità minime richieste dall'organizzazione
  • Costo totale di proprietà (TCO), incluse le licenze e la manutenzione in corso
  • Tracciabilità degli audit, registrazione e controllo degli accessi in base al ruolo
  • Autenticazione e autorizzazione tramite Microsoft Entra ID
  • Accessibile tramite API
  • Integrazioni con altri strumenti e sistemi di gestione della rete
  • Supporto della community attiva o livello di supporto del provider di software

• Prendi in considerazione uno strumento IPAM open source come Azure IPAM. Una soluzione IPAM di Azure è una soluzione leggera basata sulla piattaforma Azure. Individua automaticamente l'utilizzo degli indirizzi IP all'interno del tenant di Azure e consente di gestirlo tutto da un'interfaccia utente centralizzata o tramite un'API RESTful.

• Prendere in considerazione il modello operativo delle organizzazioni e la proprietà dello strumento di Gestione indirizzi IP. L'obiettivo di implementare uno strumento di Gestione indirizzi IP è semplificare il processo di richiesta di nuovi spazi di indirizzi IP per i team delle applicazioni senza dipendenze e colli di bottiglia.

• Una parte importante della funzionalità dello strumento di Gestione indirizzi IP consiste nell'inventariare l'utilizzo dello spazio degli indirizzi IP e organizzarlo logicamente.

Consigli per la progettazione:

• Il processo di prenotazione di spazi di indirizzi IP non sovrapposti deve supportare la richiesta di dimensioni diverse in base alle esigenze delle singole zone di destinazione dell'applicazione.

  • Ad esempio, è possibile adottare le dimensioni delle T-shirt per semplificare la descrizione delle esigenze dei team di applicazione.
    • Small - /24 - 256 indirizzi IP
    • Medio - /22 1.024 indirizzi IP
    • Large - /20 - 4,096 indirizzi IP

• Lo strumento di Gestione indirizzi IP deve avere un'API per riservare spazi di indirizzi IP non sovrapposti per supportare un approccio IaC (Infrastructure as Code). Questa funzionalità è fondamentale anche per l'integrazione senza soluzione di continuità di IPAM nel processo di vendita delle sottoscrizioni, riducendo così il rischio di errori e la necessità di intervento manuale.

  • Un esempio di approccio IaC è Bicep con la funzionalità dello script di distribuzione o le origini dati Terraform per recuperare in modo dinamico i dati dall'API di Gestione indirizzi IP.

• Creare una disposizione sistematica per gli spazi degli indirizzi IP strutturandoli in base alle aree di Azure e agli archetipi di carico di lavoro, garantendo un inventario di rete pulito e tracciabile.

• Il processo di disattivazione dei carichi di lavoro deve includere la rimozione di spazi di indirizzi IP non più utilizzati, che in seguito possono essere riutilizzati per nuovi carichi di lavoro, promuovendo un utilizzo efficiente delle risorse.