Topologia di rete hub-spoke IPv6

Questo articolo descrive come eseguire la transizione di una topologia di rete hub-spoke IPv4 a IPv6. Presenta la topologia di rete hub-spoke come punto di partenza e descrive i passaggi che è possibile eseguire per implementare il supporto IPv6.

In una rete hub-and-spoke, la rete virtuale hub funge da punto centrale di connettività per le reti virtuali spoke. Le reti virtuali spoke si connettono all'hub e possono fornire l'isolamento per le risorse dell'applicazione. Per ulteriori informazioni, vedere Transizione a IPv6.

Architecture

Scaricare un file di Visio di questa architettura.

Workflow

1. Rete Internet pubblica e cross-premise: gli utenti o i servizi possono accedere alle risorse di Azure tramite La rete Internet pubblica. La rete cross-premise include macchine virtuali locali che si connettono in modo sicuro alla rete Azure. Il traffico IPv4 usa un gateway VPN o un Azure ExpressRoute. Il traffico IPv6 utilizza il peering privato IPv6 di ExpressRoute. Gateway VPN di Azure può trasportare il traffico IPv6 in altre configurazioni, ma non quando coesiste con un gateway ExpressRoute abilitato per IPv6, come in questo caso.

2. gestione rete virtuale di Azure: questo livello di gestione raggruppa e configura le reti virtuali nella topologia. Distribuisce le configurazioni di connettività, amministratore della sicurezza e routing tra gruppi di rete.

3. Rete virtuale hub: l'hub è il punto centrale della topologia di rete. La configurazione di rete supporta sia IPv4 che IPv6 (dual stack), ad eccezione dei componenti indicati nelle limitazioni del supporto IPv6.

   • Azure Bastion fornisce connettività RDP/SSH (Desktop remoto Protocol/ Secure Shell) dal portale di Azure alle macchine virtuali direttamente tramite Transport Layer Security (TLS).
   • Firewall di Azure controlla e filtra il traffico IPv4 tra l'hub e la rete Internet pubblica. Il supporto IPv6 a doppio stack è disponibile in anteprima e copre solo le regole di rete e il proxy DNS, quindi questa architettura mantiene l'ispezione solo IPv4 della subnet del firewall e indirizza l'ispezione IPv6 al pool di appliance virtuali di rete.
   • Un pool di appliance virtuali di rete con supporto per IPv6 è in esecuzione in una subnet hub dedicata dietro un bilanciatore del carico interno. Il pool controlla e filtra il traffico IPv6 tra gli spoke, la rete Internet pubblica e la rete cross-premise. Fornisce l'equivalente IPv6 del percorso di ispezione fornito Firewall di Azure per IPv4. Distribuisci almeno due istanze in modo che la perdita di una di esse non interrompa la connettività IPv6.
   • ExpressRoute connette la rete cross-premise all'hub e trasporta sia il traffico IPv4 che IPv6.
   • Gateway VPN connette anche la rete cross-premise all'hub e può fungere da percorso di failover IPv4 per il peering privato di ExpressRoute. La coesistenza da sola non garantisce il failover. Configurare la rete locale per preferire le route apprese tramite ExpressRoute, ad esempio impostando una preferenza BGP locale più elevata. Poiché Gateway VPN coesiste con un gateway ExpressRoute abilitato per IPv6 in questo hub, trasporta solo il traffico IPv4.
   • I servizi nella rete virtuale dell'hub inviano log e metriche (diagnostica) ad Monitoraggio di Azure ai fini del monitoraggio.

4. Reti virtuali spoke: Quattro spoke si connettono all'hub. Ogni spoke è una rete dual stack, che supporta sia IPv4 che IPv6.

   • Le route IPv6 definite dall'utente (UDR) definiscono route personalizzate per il traffico IPv6 proveniente dallo spoke.
   • Le reti virtuali spoke sono collegate tramite connessioni di peering o gruppi connessi. Le connessioni peering e i gruppi connessi sono connessioni non transitive e a bassa latenza tra reti virtuali. Le reti virtuali con peering o connesse possono scambiare traffico tramite il backbone di Azure.
   • Tutto il traffico IPv4 in uscita dalle reti virtuali spoke scorre attraverso l'hub. Una route IPv4 predefinita nella tabella di route di ogni subnet spoke invia il traffico a Firewall di Azure. Una rotta IPv6 predefinita separata instrada il traffico IPv6 in uscita al pool di NVA IPv6, perché questa architettura mantiene Firewall di Azure limitato a IPv4.
   • All'interno di ogni spoke sono presenti tre subnet designate come subnet di risorse, ognuna delle quali ospita una macchina virtuale.
   • Ogni macchina virtuale si connette a un servizio di bilanciamento del carico interno configurato per supportare gli intervalli di indirizzi IPv4 e IPv6. Il servizio di bilanciamento del carico distribuisce il traffico di rete in ingresso tra le macchine virtuali.

Components

• Rete virtuale di Azure è il livello di rete di base di Azure che consente la comunicazione sicura tra risorse di Azure, Internet e reti locali. In questa architettura costituisce la topologia hub-spoke, che supporta configurazioni dual stack (IPv4 e IPv6) per la connettività centralizzata e isolata.
• Un'interfaccia di rete virtuale è un'interfaccia logica che connette le risorse di Azure a una rete virtuale. In questa architettura, consente alle macchine virtuali di comunicare tramite IPv4 e IPv6. Una singola interfaccia diventa dual stack quando si aggiunge una configurazione IP IPv6 insieme alla configurazione IPv4 esistente.
• Un indirizzo IP pubblico fornisce connettività in ingresso alle risorse di Azure tramite Internet. In questa architettura supporta sia l'accesso IPv4 che IPv6 ai servizi ospitati nella rete virtuale.
• programma di traduzione è un servizio di gestione centralizzato per organizzare e configurare reti virtuali e la relativa connettività. In questa architettura gestisce gruppi di rete e connessioni tra l'hub e le reti spoke.
• Firewall di Azure è un servizio di sicurezza di rete che protegge le risorse di Azure controllando e filtrando il traffico. In questa architettura applica il controllo del traffico IPv4 tra l'hub e la rete Internet pubblica. Un'istanza gestita di Firewall di Azure si trova nella propria subnet, che questa architettura mantiene solo IPv4 perché il supporto dual-stack per IPv6 è attualmente in anteprima ed esclude le regole applicative, il DNAT, l'intelligence sulle minacce, l'IDPS, il Proxy esplicito e i gruppi IP.
• Un'appliance virtuale di rete è una macchina virtuale che esegue una funzione di rete, ad esempio un firewall o un router. In questa architettura, un pool di appliance virtuali di rete con supporto per IPv6 nell'hub controlla e filtra il traffico IPv6. Un servizio di bilanciamento del carico interno fa fronte al pool in modo che nessuna singola appliance diventi un singolo punto di errore per la connettività IPv6.
• Gateway VPN ed ExpressRoute sono servizi che forniscono connettività cross-premise sicura tra Azure e reti locali. Possono creare gateway di rete virtuale che connettono reti virtuali di Azure a dispositivi VPN (Virtual Private Network) o circuiti ExpressRoute, che abilitano la comunicazione crittografata o privata. In questa architettura ExpressRoute trasporta il traffico IPv6 cross-premise attraverso il peering privato IPv6 e Gateway VPN trasporta il traffico IPv4 solo perché i due gateway coesistono.
• Azure Load Balancer è un servizio di bilanciamento del carico di livello 4 che distribuisce il traffico di rete in ingresso tra più risorse back-end per garantire disponibilità elevata e scalabilità. In questa architettura, un bilanciatore del carico interno in ogni spoke bilancia il traffico IPv6 tra le macchine virtuali all'interno di quello spoke e un bilanciatore del carico interno nell'hub è posto davanti al pool IPv6 di NVA.
• Gateway NAT di Azure fornisce connettività Internet solo in uscita per una subnet. In questa architettura, un gateway NAT StandardV2 collegato alla subnet NVA fornisce al pool NVA IPv6 un percorso di uscita dedicato, perché il bilanciatore del carico interno posto davanti al pool non fornisce connettività in uscita.
• Una tabella di routing è un insieme di UDR che consentono un controllo personalizzato sul modo in cui il traffico viene instradato all'interno delle reti virtuali di Azure e tra di esse. In questa architettura, le route definite dall'utente instradano il traffico IPv6 attraverso le subnet hub-and-spoke per imporre i flussi di traffico e i criteri di sicurezza.
• Macchine virtuali di Azure è una soluzione IaaS (Infrastructure as a Service) che offre risorse di calcolo flessibili e scalabili. In questa architettura le macchine virtuali vengono distribuite in subnet spoke configurate usando interfacce di rete dual stack, che consentono il supporto per carichi di lavoro IPv4 e IPv6.
• Azure Bastion è una piattaforma gestita distribuita come servizio (PaaS) che fornisce accesso RDP sicuro e SSH alle macchine virtuali senza esporli alla rete Internet pubblica. In questa architettura, viene eseguita all'interno dell'hub e consente l'accesso remoto protetto tramite TLS alle macchine virtuali nelle reti virtuali spoke collegate tramite peering.
• Monitoraggio di Azure è una piattaforma osservabile che raccoglie, analizza e agisce sui dati di telemetria di Azure e ambienti ibridi. In questa architettura raccoglie diagnostica e metriche dai servizi hub per supportare il monitoraggio delle prestazioni e la visibilità operativa.

Limitazioni del supporto IPv6

Diversi servizi comunemente visualizzati in una topologia hub-spoke non trasportano traffico IPv6 o lo trasportano solo in condizioni specifiche. Tenere conto di questi vincoli prima di pianificare lo spazio indirizzi e il routing.

Per l'elenco completo, vedi limitazioni di IPv6 per Rete virtuale di Azure e limitazioni di ExpressRoute IPv6.

Un servizio di bilanciamento del carico interno distribuisce solo il traffico in ingresso e non fornisce connettività in uscita. Le subnet nelle reti virtuali create con una versione dell'API corrente sono private per impostazione predefinita, quindi non hanno accesso in uscita predefinito. Ogni subnet che invia traffico IPv6 verso Internet richiede un metodo di uscita esplicito, inclusa la subnet NVA. Questa architettura associa un StandardV2 NAT gateway alla subnet NVA, che è l'unico SKU di gateway NAT che supporta IPv6.

Non combinare un gateway NAT StandardV2 con le regole in uscita di Azure Load Balancer sulla stessa subnet. Il gateway NAT interrompe le connessioni in uscita IPv6 che usano tali regole. Un gateway NAT StandardV2 fornisce anche la traduzione NAT64, in modo che i carichi di lavoro IPv6 possano raggiungere destinazioni esclusivamente IPv4, ma l'accesso tramite nome a tali destinazioni richiede una soluzione DNS64 di terze parti per sintetizzare i record AAAA.

Eseguire la transizione di una rete virtuale hub a IPv6

Per eseguire la transizione di una rete virtuale hub per supportare IPv6, è necessario aggiornare l'infrastruttura di rete in modo da supportare gli intervalli di indirizzi IPv6, in modo che la parte centrale e di controllo della rete possa gestire il traffico IPv6. Questo approccio garantisce che l'hub centrale possa instradare e gestire in modo efficiente il traffico tra vari segmenti di rete (spoke) usando IPv6. Per implementare IPv6 nella rete virtuale hub, seguire questa procedura:

Aggiungere lo spazio degli indirizzi IPv6 alla rete virtuale dell'hub e alle subnet dell'hub

È necessario aggiungere prima gli intervalli di indirizzi IPv6 alla rete virtuale hub e quindi alle relative subnet. Usare il blocco di indirizzi /56 per la rete virtuale e il blocco di indirizzi /64 per ogni subnet. La tabella seguente mostra un esempio di configurazione.

Non aggiungere spazio indirizzi IPv6 alla subnet Firewall di Azure. Questa architettura mantiene Firewall di Azure solo per IPv4 perché il supporto dual-stack è in anteprima e non copre le regole applicative né IDPS. Il gateway VPN coesiste con il gateway ExpressRoute abilitato per IPv6, quindi trasporta solo il traffico IPv4. Non instradare IPv6 attraverso di esso, anche se la sua subnet è dual-stack.

La subnet di Azure Bastion richiede uno spazio di indirizzi IPv6 solo se si usa un host Bastion dual-stack. Non è possibile convertire un host esistente solo IPv4, quindi distribuisci nuovamente Bastion con dual stack abilitato prima di fare affidamento su tale intervallo.

Gli indirizzi IPv6 nella tabella sono esempi. Sostituire 2001:db8:1234:: con il blocco di indirizzi IPv6 dell'organizzazione. Pianificare e documentare attentamente le allocazioni di indirizzi IPv6 per evitare sovrapposizioni e garantire un uso efficiente dello spazio indirizzi. Per aggiungere lo spazio indirizzi IPv6 alla rete virtuale hub, vedere Aggiungere IPv6 a una rete virtuale, che fornisce istruzioni per l'uso del portale di Azure, di PowerShell e del interfaccia della riga di comando di Azure.

Distribuisci il pool NVA IPv6 per l'alta disponibilità

L'appliance virtuale di rete IPv6 (NVA) gestisce tutti i flussi IPv6 ispezionati in questa architettura, quindi una singola appliance diventa un singolo punto di guasto per la connettività Internet IPv6 e tra sedi. Distribuire un pool di appliance anziché una macchina virtuale.

• Distribuire almeno due istanze dell'appliance virtuale di rete e distribuirle tra le zone di disponibilità nelle aree che supportano le zone.
• Anteporre al pool un servizio di bilanciamento del carico Standard interno con una configurazione front-end a doppio stack. Configurare una regola delle porte a disponibilità elevata impostando il protocollo su Tutti e la porta su 0 in modo che il servizio di bilanciamento del carico inoltra tutti i flussi di protocollo su tutte le porte alle istanze, incluso ICMP. ICMP è importante per IPv6 perché l'individuazione Adiacente e l'individuazione MTU del percorso dipendono da ICMPv6. Per altre informazioni, vedere Creare un servizio di bilanciamento del carico interno a doppio stack.
• Indirizzare ogni UDR IPv6 all'indirizzo IPv6 front-end del bilanciatore del carico anziché a una singola appliance. Gli esempi in questo articolo utilizzano 2001:db8:1234:0004::4 nella subnet NVA come indirizzo front-end.
• Applica un gruppo di sicurezza di rete alla subnet NVA. In una configurazione dual-stack, i probe di integrità del bilanciatore del carico non funzionano con IPv6 a meno che non sia attivo un gruppo di sicurezza di rete, quindi il bilanciatore del carico non può rilevare un'appliance non funzionante correttamente.
• Associare un gateway NAT StandardV2 alla subnet NVA. Il servizio di bilanciamento del carico interno non fornisce connettività in uscita, quindi le appliance necessitano di un metodo di uscita esplicito per raggiungere Internet.
• Confermare che il fornitore NVA convalidi e supporti il progetto. Attenersi alle indicazioni del fornitore in merito alla topologia attivo/attivo rispetto ad attivo/passivo e verificare se l'appliance richiede la traduzione degli indirizzi di rete di origine (SNAT) per mantenere il traffico simmetrico.

Per informazioni sui modelli di progettazione disponibili, sui relativi tempi di convergenza e sui compromessi in termini di simmetria del traffico, vedere Distribuire appliance virtuali di rete ad alta disponibilità.

Configurare le route definite dall'utente (UDR) per ogni subnet dell'hub

Le UDR sono route che si configurano manualmente per sovrascrivere le route di sistema predefinite di Azure. In Azure, le UDR sono essenziali per controllare il flusso del traffico di rete in una rete virtuale. È possibile usare le route definite dall'utente (UDR) per indirizzare il traffico da una subnet verso appliance, gateway o destinazioni specifiche all'interno di Azure oppure verso reti on-premises. Quando si aggiunge il supporto IPv6 alla rete virtuale hub, è necessario:

• Aggiungere route IPv6. Le route IPv4 esistenti non si applicano al traffico IPv6, perché ogni route ha un singolo prefisso di indirizzo di destinazione. Creare route separate che specificano i prefissi di destinazione IPv6 e gli hop successivi necessari.
• Associare la tabella di routing alle subnet Dopo aver definito le route, associare la tabella di route alle subnet pertinenti all'interno della rete virtuale. Questa associazione determina quali subnet usano le route definite.

Le route vengono definite per i prefissi di destinazione, non per le singole risorse. Si associa una tabella di route a una subnet e ogni risorsa in tale subnet segue le route in tale tabella. Per altre informazioni, vedere Panoramica della route definita dall'utente.

Nell'architettura di esempio, la rete virtuale hub ha rotte IPv6 per la subnet del gateway e per la subnet dell'appliance virtuale di rete. La subnet Firewall di Azure non ha rotte IPv6 perché supporta solo IPv4, e la subnet Azure Bastion non ha alcuna tabella di routing perché Azure Bastion non supporta le route definite dall'utente in AzureBastionSubnet. L'indirizzo 2001:db8:1234:0004::4 hop successivo è l'indirizzo front-end IPv6 del servizio di bilanciamento del carico interno che precede il pool di appliance virtuali di rete, non l'indirizzo di una singola appliance. La tabella seguente mostra esempi di UDR IPv6.

Ripetere il percorso di ispezione per ogni prefisso spoke che si desidera far ispezionare al pool NVA. Non disabilitare la propagazione della route BGP in GatewaySubnet, perché il gateway non funzionerà. Mantieni abilitata la propagazione nelle subnet NVA e spoke, in modo che i prefissi IPv6 on-premises appresi tramite BGP rimangano disponibili per il traffico ispezionato.

Non creare rotte che utilizzano il tipo di hop successivo Virtual network gateway. Azure supporta tale tipo di hop successivo solo quando il gateway della rete virtuale è un gateway VPN. Quando un gateway VPN e un gateway ExpressRoute vengono distribuiti nella stessa rete virtuale, Azure considera il gateway ExpressRoute come gateway della rete virtuale, in modo che il tipo di hop successivo non venga applicato in questa architettura.

Quando configuri le UDR, devi allinearle ai criteri di rete dell'organizzazione e all'architettura della distribuzione Azure.

Modificare il circuito ExpressRoute (se applicabile)

Per abilitare IPv6 nel circuito ExpressRoute, è necessario:

• Abilita il peering privato IPv6. Abilitare il peering privato IPv6 per il circuito ExpressRoute. Questa configurazione abilita il traffico IPv6 tra la rete locale e la rete virtuale hub.
• Allocare lo spazio di indirizzi IPv6. Specificare una coppia di subnet IPv6 /126 di cui si è proprietari per i collegamenti ExpressRoute primario e secondario.
• Verificare la propagazione della rotta. Il gateway apprende i prefissi IPv6 locali tramite BGP indipendentemente da qualsiasi impostazione della tabella di route. La propagazione delle rotte controlla se Azure inserisce i prefissi appresi nella tabella di instradamento di una subnet, quindi è opportuno mantenerla abilitata nella subnet dell'NVA e nelle subnet spoke che richiedono connettività tra sedi locali.

Queste configurazioni estendono la connettività IPv6 ai servizi di Azure tramite un circuito ExpressRoute, in modo da poter instradare simultaneamente funzionalità dual stack. Per modificare ExpressRoute, vedere Aggiungere il supporto IPv6 per il peering privato, che fornisce istruzioni per l'uso del portale di Azure, di PowerShell e del interfaccia della riga di comando di Azure.

Controllare i requisiti di rete e del gateway seguenti:

• Aggiungere lo spazio di indirizzi IPv6 alla rete virtuale e alla subnet del gateway prima di creare il gateway di rete virtuale ExpressRoute.
• Il peering privato IPv6 supporta i gateway di rete virtuale ExpressRoute appena creati di qualsiasi SKU che usa un indirizzo IP pubblico statico standard.
• I gateway esistenti supportano IPv6 solo se sono a ridondanza di zona.
• Il peering privato IPv6 non è supportato in rete WAN virtuale e un gateway dual-stack non può connettersi a un circuito in cui nel peering privato è abilitato solo IPv4.
• È anche necessario configurare IPv6 nelle apparecchiature locali dei clienti locali.

Eseguire la transizione delle reti virtuali spoke a IPv6

Le reti virtuali spoke sono collegate all'hub centrale. Quando si abilita IPv6 nelle reti virtuali spoke, ogni rete spoke può comunicare tramite il protocollo IPv6 e la rete ottiene una progettazione IPv6 più coerente nella topologia. Per abilitare IPv6 nelle reti virtuali spoke, seguire questa procedura:

Aggiungere lo spazio di indirizzi IPv6 alle reti virtuali spoke e alle subnet spoke

Come per la rete virtuale hub, è necessario aggiungere intervalli di indirizzi IPv6 a ogni rete virtuale spoke e quindi alle relative subnet. Usare il blocco di indirizzi /56 per le reti virtuali e il blocco di indirizzi /64 per ogni subnet. La tabella seguente fornisce un esempio di intervalli di indirizzi IPv6 per le reti virtuali spoke e le relative subnet.

Per la configurazione, modificare gli indirizzi IPv6 in base alle esigenze e all'allocazione dell'organizzazione.

Modificare le risorse della rete virtuale spoke

Ogni rete virtuale spoke contiene più macchine virtuali e un servizio di bilanciamento del carico interno. Il servizio di bilanciamento del carico interno consente di instradare il traffico IPv4 e IPv6 alle macchine virtuali. È necessario modificare le macchine virtuali e i servizi di bilanciamento del carico interni in modo che supportino IPv6.

Per ogni macchina virtuale, aggiungere una configurazione IP IPv6 all'interfaccia di rete già presente nella macchina virtuale. Non creare un'interfaccia IPv6 separata. L'interfaccia mantiene la configurazione IPv4 e diventa dual stack, che ogni interfaccia di rete richiede perché Azure non supporta le interfacce solo IPv6. Per altre informazioni, vedere Aggiungere una configurazione IPv6 a una macchina virtuale.

Se non è presente un servizio di bilanciamento del carico interno in ogni rete virtuale spoke, creare un servizio di bilanciamento del carico interno a doppio stack. Per altre informazioni, vedere Creare un servizio di bilanciamento del carico interno a doppio stack. Se è presente un servizio di bilanciamento del carico interno, è possibile usare PowerShell o il interfaccia della riga di comando di Azure per aggiungere il supporto IPv6.

Configurare le UDR per ogni subnet spoke

Per configurare gli UDR, usare la stessa configurazione sia per le reti virtuali spoke sia per le reti virtuali hub. Quando si aggiunge il supporto IPv6 a una rete virtuale spoke, è necessario:

• Aggiungere route IPv6. Le route IPv4 esistenti non si applicano al traffico IPv6, perché ogni route ha un singolo prefisso di indirizzo di destinazione. Creare route separate che specificano i prefissi di destinazione IPv6 e gli hop successivi necessari.
• Associare la tabella di routing alle subnet Dopo aver definito le route, associare la tabella di route alle subnet pertinenti all'interno della rete virtuale. Questa associazione determina quali subnet usano le route definite.

La tabella seguente mostra esempi di route definite dall'utente (UDR) IPv6 per ogni subnet in una rete virtuale spoke. Il traffico IPv6 diretto a Internet viene inviato al pool di NVA IPv6 nell'hub anziché ad Firewall di Azure, che questa architettura mantiene limitato a IPv4. Come nell'hub, l'indirizzo hop successivo è l'indirizzo front-end IPv6 del servizio di bilanciamento del carico, non l'indirizzo di una singola appliance.

Gli spoke apprendono i prefissi IPv6 dell'ambiente locale dal gateway ExpressRoute tramite BGP quando si abilita Usa il gateway o il Route Server della rete virtuale remota sul peering. Aggiungere una route definita dall'utente per l'ambiente locale solo quando si desidera sovrascrivere tali route apprese, ad esempio quando si invia il traffico all'NVA per l'ispezione. Come per l'hub, non usare il tipo di hop successivo Virtual network gateway per raggiungere le reti locali tramite ExpressRoute.

Per la configurazione in uso, è necessario allineare gli UDR ai criteri di rete dell'organizzazione e all'architettura della distribuzione Azure.

Contributors

Microsoft gestisce questo articolo. I collaboratori seguenti hanno originariamente scritto l'articolo.

Autore principale:

• Werner Rall | Senior Cloud Solutions Architect

Altri contributori:

• Sherri Babylon | Responsabile senior del programma tecnico
• Dawn Bedard | Responsabile principale del programma tecnico
• Brandon Stephenson | Ingegnere Senior del Cliente

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Creare una macchina virtuale con una rete dual stack IPv6
• Gestire gli intervalli di indirizzi IP
• Cloud Adoption Framework: Pianificare l'indirizzamento IP
• IPv6 per la rete virtuale di Azure
• Aggiungere il supporto IPv6 per il peering privato di ExpressRoute
• Panoramica di DNS di Azure e del DNS inverso
• SKU di Gateway NAT di Azure

Risorse correlate

• Transizione a IPv6
• Opzioni di connessione della rete virtuale e comunicazione spoke-to-spoke
• Firewall e gateway applicativo per le reti virtuali
• Distribuire i servizi di dominio Active Directory in una rete virtuale Azure