Condividi tramite

Pianificare l'indirizzamento IP

  • Articolo

È importante che l'organizzazione pianifichi l'indirizzamento IP in Azure. La pianificazione garantisce che lo spazio indirizzi IP non si sovrapponga tra i percorsi locali e le aree di Azure.

Considerazioni sulla progettazione:

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

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

    {Diagramma che mostra il funzionamento di NAT con Gateway VPN.}

  • È 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 il peering di reti virtuali. 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. Quando si ridimensionano le reti virtuali e si includono subnet, è necessario includere tali indirizzi.

  • 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.

Raccomandazioni sulla progettazione:

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

  • Usare gli indirizzi IP dall'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 (broadcast)
    • 127.0.0.0/8 (loopback)
    • 169.254.0.0/16 (locale rispetto al collegamento)
    • 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.

    Diagramma che mostra lo stack doppio IPv4 e IPv6.

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

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

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

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

  • Usare reti virtuali spoke della zona di destinazione non instradabili e collegamento privato di Azure servizio per evitare l'esaurimento 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:

  • 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 servizi di bilanciamento del carico di Azure con connessione Internet basic-SKU 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 training sono considerati significativi, è consigliabile continuare a usare l'infrastruttura solo IPv4 nel back-end e distribuire un gateway IPv4/IPv6 a doppio stack di terze parti per la distribuzione di servizi.

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

    Diagramma che mostra un gateway IPv4/IPv6 dual stack che fornisce l'accesso a un back-end solo IPv4.

Raccomandazioni sulla progettazione:

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

Diagramma che mostra un servizio di bilanciamento del carico IPv4/IPv6 che fornisce l'accesso a un back-end solo IPv4.

  • Distribuire l'appliance virtuale di rete in 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 di indirizzi IP pubblici.

    Le appliance virtuali di rete accettano il traffico IPv4 e IPv6 e lo traducono 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:

    Diagramma che mostra Frontdoor di Azure che fornisce l'accesso a un back-end solo IPv4.

Queste sono le differenze principali tra l'approccio dell'appliance virtuale di rete e l'approccio frontdoor di Azure:

  • 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 appliance virtuali di rete vengono usate all'interno di una distribuzione a livello di area. Frontdoor di Azure viene usato per instradare il traffico a una o più distribuzioni a livello di area in aree di Azure diverse o in altre posizioni con connessione 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 CIDR (Classless Inter-Domain Routing) IPv6 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 subnet o all'IPv6 BYOIP. 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 a 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 il traffico IPv6 può passare 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 Gestione indirizzi IP (Gestione indirizzi IP)

L'uso di uno strumento di Gestione indirizzi IP consente di pianificare gli 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 le raccomandazioni essenziali quando si adotta uno strumento Gestione indirizzi IP.

Considerazioni sulla progettazione:

Sono disponibili numerosi strumenti Gestione indirizzi IP da considerare, a seconda dei requisiti e delle dimensioni dell'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.

  • Prendere in considerazione questi fattori quando si valuta quale strumento Gestione indirizzi IP implementare:

    • Funzionalità minime richieste dall'organizzazione
    • Costo totale di proprietà (TCO), incluse le licenze e la manutenzione in corso
    • Audit trail, registrazione e controlli 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

  • Valutare uno strumento open source Gestione indirizzi IP come Azure Gestione indirizzi IP. Azure Gestione indirizzi IP è 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 Gestione indirizzi IP. L'obiettivo di implementare uno strumento 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.

Raccomandazioni sulla 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 il ridimensionamento della T-shirt per semplificare la descrizione delle esigenze dei team delle applicazioni:
      • Small - /24 256 indirizzi IP
      • Medio - /22 1.024 indirizzi IP
      • Large - /20 4.096 indirizzi IP

  • Lo strumento 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 problemi di Gestione indirizzi IP nel processo di vendita di abbonamenti, 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 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 rimozione delle autorizzazioni per i carichi di lavoro deve includere la rimozione di spazi di indirizzi IP non più usati, che in seguito possono essere riutilizzati per i nuovi carichi di lavoro futuri, promuovendo un utilizzo efficiente delle risorse.