Routing del traffico di rete virtuale di Azure

Questo articolo illustra il funzionamento del routing del traffico di rete virtuale di Azure tra Azure, locale e risorse Internet. Azure crea automaticamente una tabella di route per ogni subnet all'interno di una rete virtuale di Azure e aggiunge le route predefinite di sistema alla tabella. Comprendere il routing del traffico consente di ottimizzare la connettività e risolvere i problemi di rete nell'ambiente Azure. Per altre informazioni sulle reti virtuali e sulle subnet, vedere la panoramica della rete virtuale. È possibile eseguire l'override di alcune route di sistema di Azure con route personalizzate e aggiungere altre route personalizzate alle tabelle di route. Azure instrada il traffico in uscita da una subnet in base alle route della tabella di route di una subnet.

Route di sistema

Azure crea automaticamente route di sistema e assegna le route a ogni subnet in una rete virtuale. Non è possibile creare route di sistema e non è possibile rimuovere le route di sistema, ma è possibile eseguire l'override di alcune route di sistema con route personalizzate. Azure crea route di sistema predefinite per ogni subnet e aggiunge altre route predefinite facoltative a subnet specifiche, oppure a ogni subnet, quando svengono usate funzionalità specifiche di Azure.

Route di sistema predefinite

Ogni route include un prefisso di indirizzo e un tipo di hop successivo. Azure utilizza la rotta con il prefisso di indirizzo corrispondente quando il traffico esce da una subnet verso un indirizzo IP. Altre informazioni su come Azure seleziona una route quando più route contengono prefissi identici o sovrapposti. Quando si crea una rete virtuale, Azure crea automaticamente le route di sistema predefinite seguenti per ogni subnet della rete virtuale:

I tipi di hop successivi elencati nella tabella precedente rappresentano il modo in cui Azure instrada il traffico destinato al prefisso degli indirizzi elencato. Ecco le spiegazioni per i tipi di hop successivo:

• Rete virtuale: instrada il traffico tra gli intervalli di indirizzi all'interno dello spazio di indirizzi di una rete virtuale. Azure crea una route con un prefisso degli indirizzi che corrisponde a ogni intervallo di indirizzi definito nello spazio di indirizzi di una rete virtuale. Se per lo spazio di indirizzi della rete virtuale sono stati definiti più intervalli di indirizzi, Azure crea una route per ogni intervallo di indirizzi. Per impostazione predefinita, Azure instrada il traffico tra subnet. Non è necessario definire tabelle di route o gateway per consentire ad Azure di instradare il traffico tra subnet. Azure non crea route predefinite per gli intervalli di indirizzi della subnet. Ogni intervallo di indirizzi della subnet si trova all'interno di un intervallo di indirizzi dello spazio di indirizzi di una rete virtuale.

• Internet: instrada verso Internet il traffico specificato dal prefisso degli indirizzi. La route di sistema predefinita specifica il prefisso degli indirizzi 0.0.0.0/0. Se non si esegue l'override delle route predefinite di Azure, Azure instrada il traffico per qualsiasi indirizzo non specificato da un intervallo di indirizzi all'interno di una rete virtuale a Internet. Esiste un'eccezione a questo routing. Se l'indirizzo di destinazione è per un servizio di Azure, Azure instrada il traffico direttamente al servizio tramite la rete backbone di Azure invece di instradare il traffico a Internet. Il traffico tra i servizi di Azure non attraversa Internet. Non importa in quale area di Azure esiste la rete virtuale o in quale area di Azure viene distribuita un'istanza del servizio di Azure. È possibile eseguire l'override della route di sistema predefinita di Azure per il prefisso di indirizzo 0.0.0.0/0 con una route personalizzata.

• Nessuno: il traffico indirizzato al tipo di hop successivo Nessuno viene eliminato e non instradato all'esterno della subnet. Azure crea automaticamente route predefinite per i prefissi degli indirizzi seguenti:

  • 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16: riservato per l'uso privato in RFC 1918.
  • 100.64.0.0/10: riservato in RFC 6598.

  Se si assegnano gli intervalli di indirizzi precedenti nello spazio degli indirizzi di una rete virtuale, Azure modifica automaticamente il tipo di hop successivo della route da Nessuno a Rete virtuale. Se si assegna un intervallo di indirizzi allo spazio degli indirizzi di una rete virtuale che include (ma non è uguale a) uno dei quattro prefissi degli indirizzi riservati, Azure rimuove la route per il prefisso e aggiunge una route per il prefisso degli indirizzi aggiunto, con Rete virtuale come tipo di hop successivo.

Route predefinite facoltative

Azure crea route di sistema più predefinite per diverse funzionalità di Azure, ma solo se si abilitano le funzionalità. A seconda della funzionalità, Azure crea route predefinite facoltative per subnet specifiche all'interno della rete virtuale o per tutte le subnet all'interno di una rete virtuale. La tabella seguente elenca le altre route di sistema e i tipi di hop successivi che Azure potrebbe aggiungere quando si abilitano funzionalità diverse.

• Peering di rete virtuale: quando si crea un peering di rete virtuale tra due reti virtuali, il sistema aggiunge una route per ogni intervallo di indirizzi all'interno dello spazio degli indirizzi di ogni rete virtuale coinvolta nel peering. Vedere altre informazioni sul peering di rete virtuale.
• Gateway di rete virtuale: vengono aggiunte una o più route con Gateway di rete virtuale elencato come tipo di hop successivo quando si aggiunge un gateway di rete virtuale a una rete virtuale. Anche l'origine è Gateway di rete virtuale, perché il gateway aggiunge le route alla subnet. Se il gateway di rete locale scambia route BGP con un gateway di rete virtuale, il sistema aggiunge una route per ogni route. Queste route vengono propagate dal gateway di rete locale. È consigliabile riepilogare le route locali all'intervallo di indirizzi più grande possibile, in modo da propagare il minor numero di route a un gateway di rete virtuale di Azure. Il numero di route che possono essere propagate a un gateway di rete virtuale di Azure è limitato. Per altre informazioni, consultare limiti di Azure.
• VirtualNetworkServiceEndpoint: Azure include indirizzi IP pubblici di determinati servizi alla tabella di route quando si abilita un endpoint di servizio. Azure include queste route solo alle subnet con endpoint di servizio abilitati. Azure aggiorna automaticamente questi indirizzi nella tabella di route quando gli indirizzi IP del servizio cambiano. Altre informazioni sugli endpoint del servizio di rete virtuale e sui servizi supportati.

  Note

  Il peering di rete virtuale e i tipi di hop VirtualNetworkServiceEndpoint successivo vengono aggiunti solo alle tabelle di route delle subnet all'interno delle reti virtuali create tramite il modello di distribuzione Azure Resource Manager. I tipi di hop successivi non vengono aggiunti alle tabelle di route associate a subnet di reti virtuali create tramite il modello di distribuzione classica. Vedere altre informazioni sui modelli di distribuzione di Azure.

Route personalizzate

È possibile creare route personalizzate creando route definite dall'utente o scambiando route BGP tra il gateway di rete locale e un gateway di rete virtuale di Azure.

Route definite dall'utente

Per personalizzare le route del traffico, non è consigliabile modificare le route predefinite. È necessario creare route personalizzate o definite dall'utente (statiche) che eseguono l'override delle route di sistema predefinite di Azure. In Azure, si crea una tabella di route e quindi la si associa a zero o più subnet della rete virtuale. A ogni subnet può essere associata una o nessuna tabella di route. Per informazioni sul numero massimo di route che è possibile aggiungere a una tabella di route e sul numero massimo di tabelle UDR che è possibile creare per ogni sottoscrizione di Azure, vedere Limiti di Azure.

Per impostazione predefinita, una tabella di route può contenere fino a 400 route definite dall'utente. Con la configurazione del routing di Gestione rete virtuale di Azure, questo numero può espandersi a 1.000 route definite dall'utente per ogni tabella di route. Questo limite aumentato supporta configurazioni di routing più avanzate. Un esempio è indirizzare il traffico dai data center locali attraverso un firewall a ogni rete virtuale spoke in una topologia hub-spoke quando si dispone di un numero maggiore di reti virtuali spoke.

Quando si crea una tabella di route e la si associa a una subnet, le route della tabella vengono combinate con le route predefinite della subnet. Se sono presenti assegnazioni di route in conflitto, le route definite dall'utente sostituiscono le route predefinite.

È possibile specificare i tipi di hop successivi seguenti quando si crea una route definita dall'utente:

• Appliance virtuale: un'appliance virtuale è una macchina virtuale che esegue generalmente un'applicazione di rete, ad esempio un firewall. Per informazioni su varie appliance virtuali di rete preconfigurate che è possibile distribuire in una rete virtuale, vedere Azure Marketplace. Quando si crea una route con il tipo hop appliance virtuale, si specifica anche un indirizzo IP hop successivo. L'indirizzo IP può essere:

  • L'indirizzo IP privato di un'interfaccia di rete collegata a una macchina virtuale. Per un'interfaccia di rete collegata a una macchina virtuale che inoltra il traffico di rete a un indirizzo diverso dal proprio è necessario abilitare l'opzione di inoltro IP di Azure. L'impostazione disabilita il controllo dell'origine e della destinazione per un'interfaccia di rete da parte di Azure. Vedere altre informazioni su come abilitare l'inoltro IP per un'interfaccia di rete. Abilitare l'inoltro IP è un'impostazione di Azure.

    Potrebbe essere necessario abilitare l'inoltro IP all'interno del sistema operativo della macchina virtuale per consentire all'appliance di inoltrare il traffico tra indirizzi IP privati assegnati alle interfacce di rete di Azure. Se l'appliance deve instradare il traffico a un indirizzo IP pubblico, deve eseguire il proxy del traffico o eseguire NAT (Network Address Translation) dall'indirizzo IP privato dell'origine al proprio indirizzo IP privato. Azure esegue quindi NAT a un indirizzo IP pubblico prima di inviare il traffico a Internet. Per determinare le impostazioni necessarie nella macchina virtuale, vedere la documentazione del sistema operativo o dell'applicazione di rete. Per informazioni sulle connessioni in uscita, vedere Informazioni sulle connessioni in uscita in Azure.

    Note

    Distribuire un'appliance virtuale in una subnet diversa dalle risorse instradate attraverso l'appliance stessa. La distribuzione dell'appliance virtuale nella stessa subnet e quindi l'applicazione di una tabella di route alla subnet che instrada il traffico attraverso l'appliance virtuale può comportare cicli di routing in cui il traffico non esce mai dalla subnet.

    Un indirizzo IP privato dell'hop successivo deve avere connettività diretta senza dover instradare attraverso un gateway Azure ExpressRoute o tramite la rete WAN virtuale di Azure. L'impostazione dell'hop successivo su un indirizzo IP senza connettività diretta comporta una configurazione definita dall'utente non valida.

  • L'indirizzo IP privato di un servizio di bilanciamento del carico interno di Azure. Un servizio di bilanciamento del carico viene spesso usato nell'ambito di una strategia di disponibilità elevata per le appliance virtuali di rete.

  È possibile definire una route con 0.0.0.0/0 come prefisso dell'indirizzo e un tipo di hop successivo dell'appliance virtuale. Questa configurazione consente all'appliance di controllare il traffico e determinare se inoltrare o eliminare il traffico. Se si intende creare una route definita dall'utente contenente il prefisso dell'indirizzo 0.0.0.0/0, leggere prima il prefisso dell'indirizzo 0.0.0.0/0.

• Gateway di rete virtuale: le route definite dall'utente con tipo hop successivo Gateway di rete virtuale consentono di instradare il traffico al gateway di una rete virtuale. Una rete virtuale ha un singolo gateway impostato automaticamente dalla piattaforma sottostante definita dal software, basata sulla tua distribuzione. Le rotte definite dall'utente con un gateway di rete virtuale come hop successivo sono supportate solo se il gateway della rete virtuale è un gateway VPN (e non ExpressRoute, RouteServer o router hub della rete WAN virtuale).

  • Per le reti virtuali con un gateway VPN, un gateway ExpressRoute e/o un server di route:

    • Se RouteServer viene distribuito in una rete virtuale, RouteServer viene impostato come gateway della rete virtuale.
    • Se il gateway VPN e il gateway ExpressRoute vengono distribuiti nella stessa rete virtuale (senza RouteServer), il gateway ExpressRoute viene impostato come gateway della rete virtuale.
    • Se un gateway VPN o un gateway ExpressRoute è l'unico gateway nella rete virtuale (senza RouteServer), il gateway distribuito è il gateway della rete virtuale.

  • Per le reti virtuali interconnesse con un'altra rete virtuale dotata di gateway o Route Server e l'impostazione "Usa il gateway o il Route Server della rete virtuale remota" è abilitata:

    • Se il RouteServer viene distribuito nella rete virtuale con peering, il RouteServer remoto viene impostato come gateway della rete virtuale.
    • Se il gateway VPN e il gateway ExpressRoute vengono distribuiti nella rete virtuale con peering (senza RouteServer), il gateway ExpressRoute remoto viene impostato come gateway della rete virtuale.
    • Se un gateway VPN o un gateway ExpressRoute è l'unico gateway nella rete virtuale con peering (senza RouteServer), il gateway remoto viene impostato come gateway della rete virtuale.

  • Per le reti virtuali connesse a un hub della rete WAN virtuale:

    • Il gateway della rete virtuale è sempre impostato sul router dell'hub della rete WAN virtuale.

    Nell'ambiente locale può essere presente un dispositivo che ispeziona il traffico e determina se inoltrarlo o eliminarlo. Se si intende creare una route definita dall'utente per il prefisso dell'indirizzo 0.0.0.0/0, leggere prima il prefisso dell'indirizzo 0.0.0.0/0. Anziché configurare una route definita dall'utente per il prefisso di indirizzo 0.0.0.0/0, è possibile annunciare una route con il prefisso 0.0.0.0/0 tramite BGP se il BGP per un gateway di rete virtuale VPN è abilitato.

• Nessuno: specificare quando si vuole eliminare il traffico verso un prefisso degli indirizzi, invece di inoltrarlo a una destinazione. Azure potrebbe visualizzare Nessuno per alcune delle route di sistema facoltative se non è configurata una funzionalità. Ad esempio, se si noterà che l'indirizzo IP dell'hop successivo mostraNessuno e il tipo hop successivo mostra il gateway di rete virtuale o l'appliance virtuale, potrebbe essere dovuto al fatto che il dispositivo non è in esecuzione o non è completamente configurato. Azure crea route predefinite di sistema per i prefissi degli indirizzi riservati con tipo hop successivo Nessuno.

• Rete virtuale: specificare l’opzione Rete virtuale quando si intende eseguire l'override del routing predefinito in una rete virtuale. Per un esempio del motivo per cui è possibile creare una route con il tipo di hop di rete virtuale, vedere Esempio di routing.

• Internet: specificare l'opzione Internet quando si desidera instradare in modo esplicito il traffico destinato a un prefisso di indirizzo a Internet. In alternativa, usarlo se si vuole che il traffico destinato ai servizi di Azure con indirizzi IP pubblici venga mantenuto all'interno della rete backbone di Azure.

Non è possibile specificare il peering di rete virtuale o VirtualNetworkServiceEndpoint come tipo hop successivo nelle route definite dall'utente. Azure crea route con peering di rete virtuale o tipi di hop successivi VirtualNetworkServiceEndpoint solo quando si configura un peering di rete virtuale o un endpoint di servizio.

Tag di servizio per le route definite dall'utente

È ora possibile specificare un tag di servizio come prefisso dell'indirizzo per una route definita dall'utente anziché un intervallo IP esplicito. Un tag del servizio rappresenta un gruppo di prefissi di indirizzi IP di un determinato servizio di Azure. I prefissi di indirizzo inclusi nel tag di servizio sono gestiti da Microsoft, che lo aggiorna automaticamente in caso di modifica degli indirizzi. Questo supporto riduce al minimo la complessità degli aggiornamenti frequenti alle route definite dall'utente e riduce il numero di route che è necessario creare. Attualmente è possibile creare 25 o meno route con tag di servizio in ogni tabella di route. Con questa versione, è supportato anche l'uso dei tag di servizio negli scenari di routing per i contenitori.

Corrispondenza esatta

Il sistema assegna la preferenza alla route con il prefisso esplicito quando è presente una corrispondenza esatta del prefisso tra una route con un prefisso IP esplicito e una route con un tag di servizio. Quando più route con tag di servizio hanno prefissi IP corrispondenti, le route vengono valutate nell'ordine seguente:

1. Tag regionali (ad esempio, Storage.EastUS o AppService.AustraliaCentral)

2. Tag di primo livello (ad esempio, Storage o AppService)

3. tag regionali AzureCloud (ad esempio, AzureCloud.canadacentral o AzureCloud.eastasia)

4. Tag AzureCloud

Per usare questa funzionalità, specificare un nome di tag del servizio per il parametro del prefisso dell'indirizzo nei comandi della tabella di route. Ad esempio, in PowerShell è possibile creare una nuova route per indirizzare il traffico inviato a un prefisso IP di Archiviazione di Azure a un'appliance virtuale usando questo comando:

$param = @{
    Name = 'StorageRoute'
    AddressPrefix = 'Storage'
    NextHopType = 'VirtualAppliance'
    NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

Lo stesso comando per l'interfaccia della riga di comando di Azure è:

az network route-table route create \
    --resource-group MyResourceGroup \
    --route-table-name MyRouteTable \
    --name StorageRoute \
    --address-prefix Storage \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

Tipi di hop successivi tra gli strumenti di Azure

Il nome visualizzato e a cui viene fatto riferimento per i tipi di hop successivo è diverso tra il portale di Azure e gli strumenti da riga di comando e i modelli di distribuzione classica e Resource Manager. La tabella seguente elenca i nomi usati per fare riferimento a ogni tipo di hop successivo nei diversi strumenti e modelli di distribuzione.

Protocollo BGP (Border Gateway Protocol)

Un gateway di rete locale può scambiare route con un gateway di rete virtuale di Azure usando BGP. L'uso di BGP con un gateway di rete virtuale di Azure dipende dal tipo selezionato al momento della creazione del gateway stesso:

• ExpressRoute: è necessario usare BGP per annunciare le route locali al router perimetrale nel data center Microsoft. Non è possibile creare route definite dall'utente per forzare il traffico verso il gateway di rete virtuale ExpressRoute se si distribuisce un gateway di rete virtuale distribuito come tipo ExpressRoute. È possibile usare le route definite dall'utente per forzare il traffico dalla route rapida, ad esempio un'appliance virtuale di rete.
• VPN: facoltativamente, è possibile usare BGP. Per altre informazioni, vedere BGP con connessioni VPN da sito a sito.

Quando si scambiano route con Azure usando BGP, viene aggiunta una route separata alla tabella di route di tutte le subnet in una rete virtuale per ogni prefisso annunciato. La route viene aggiunta con Gateway di rete virtuale come origine e tipo di hop successivo.

È possibile disabilitare la propagazione della route di ExpressRoute e del gateway VPN di Azure in una subnet usando una proprietà in una tabella di route. Quando si disabilita la propagazione della route, il sistema non aggiunge route alla tabella di route di tutte le subnet con la propagazione della route del gateway di rete virtuale disabilitata. Questo processo si applica sia alle route statiche che alle route BGP. La connettività con le connessioni VPN viene ottenuta usando route personalizzate con un tipo hop successivo del gateway di rete virtuale. Per altre informazioni, vedere Disabilitare la propagazione della route del gateway di rete virtuale.

Come Azure seleziona le route per il routing del traffico

Quando il traffico in uscita viene inviato da una subnet, Azure seleziona una route in base all'indirizzo IP di destinazione usando l'algoritmo di corrispondenza del prefisso più lungo. Ad esempio, una tabella di route ha due route. Una route specifica il prefisso di indirizzo 10.0.0.0/24 e l'altra route specifica il prefisso di indirizzo 10.0.0.0/16.

Azure indirizza il traffico destinato alla versione 10.0.0.5 al tipo di hop successivo specificato nella route con il prefisso di indirizzo 10.0.0.0/24. Questo processo si verifica perché 10.0.0.0/24 è un prefisso più lungo di 10.0.0.0/16, anche se 10.0.0.5 rientra in entrambi i prefissi di indirizzo.

Azure indirizza il traffico destinato a 10.0.1.5 al tipo di hop successivo specificato nella route con il prefisso di indirizzo 10.0.0.0/16. Questo processo si verifica perché 10.0.1.5 non è incluso nel prefisso di indirizzo 10.0.0.0/24, che rende la route con il prefisso di indirizzo 10.0.0.0/16 con il prefisso di corrispondenza più lungo.

Se più route contengono lo stesso prefisso degli indirizzi, Azure seleziona il tipo di route in base alla priorità seguente:

1. Route definita dall'utente

2. Route BGP

3. Route di sistema

Una tabella di route contiene ad esempio le route seguenti:

Quando il traffico è destinato a un indirizzo IP all'esterno dei prefissi di indirizzi di qualsiasi altra route nella tabella di route, Azure seleziona la route con l'origine Utente. Azure fa questa scelta perché le route definite dall'utente sono una priorità più alta rispetto alle route predefinite del sistema.

Per una tabella di routing completa con spiegazioni delle route nella tabella, vedere Esempio di routing.

Prefisso degli indirizzi 0.0.0.0/0

Una route con il prefisso di indirizzo 0.0.0.0/0 fornisce istruzioni ad Azure. Azure usa queste istruzioni per instradare il traffico destinato a un indirizzo IP che non è incluso nel prefisso degli indirizzi di qualsiasi altra route presente nella tabella di route della subnet. Quando si crea una subnet, Azure crea una route predefinita per il prefisso degli indirizzi 0.0.0.0/0, con tipo di hop successivo Internet. Se non si esegue l'override di questa route, Azure instrada a Internet tutto il traffico destinato agli indirizzi IP non inclusi nel prefisso degli indirizzi di qualsiasi altra route.

L'eccezione è data dal traffico verso gli indirizzi IP pubblici dei servizi di Azure, che rimane nella rete backbone di Azure e non viene instradato a Internet. Quando si esegue l'override di questa route con una route personalizzata, viene indirizzato il traffico destinato agli indirizzi che non rientrano nei prefissi di qualsiasi altra route nella tabella di route. La destinazione dipende dal fatto che si specifichi un'appliance virtuale di rete o un gateway di rete virtuale nella route personalizzata.

Quando si esegue l'override del prefisso degli indirizzi 0.0.0.0/0, il traffico in uscita dalla subnet passa attraverso il gateway di rete virtuale o l'appliance virtuale. Le modifiche seguenti si verificano anche con il routing predefinito di Azure:

• Azure invia tutto il traffico al tipo di hop successivo specificato nella route, incluso il traffico destinato agli indirizzi IP pubblici dei servizi di Azure.

  Quando il tipo di hop successivo per la route con il prefisso di indirizzo 0.0.0.0/0 è Internet, il traffico dalla subnet destinata agli indirizzi IP pubblici dei servizi di Azure non lascia mai la rete backbone di Azure, indipendentemente dall'area di Azure in cui è presente la rete virtuale o la risorsa del servizio di Azure.

  Quando si crea una route definita dall'utente o BGP con un gateway di rete virtuale o un tipo hop successivo dell'appliance virtuale, tutto il traffico viene inviato al tipo di hop successivo specificato nella route. Incluso il traffico inviato agli indirizzi IP pubblici dei servizi di Azure per i quali gli endpoint di servizio non sono abilitati.

  Quando si abilita un endpoint di servizio per un servizio, Azure crea una route con prefissi di indirizzo per il servizio. Il traffico verso il servizio non viene instradato al tipo di hop successivo in una route con il prefisso di indirizzo 0.0.0.0/0. I prefissi di indirizzo per il servizio sono più lunghi di 0.0.0.0/0.

• Non è più possibile accedere direttamente alle risorse nella subnet da Internet. È possibile accedere indirettamente alle risorse della subnet da Internet. Il dispositivo specificato dal tipo di hop successivo per una route con il prefisso di indirizzo 0.0.0.0/0 deve elaborare il traffico in ingresso. Dopo aver attraversato il dispositivo, il traffico raggiunge la risorsa nella rete virtuale. Se la route contiene i valori seguenti per il tipo di hop successivo:

  • Appliance virtuale: l'appliance deve:

    • Essere accessibile da Internet.
    • Avere un indirizzo IP pubblico assegnato.
    • Non avere associata una regola del gruppo di sicurezza di rete che impedisca la comunicazione con il dispositivo.
    • Non negare la comunicazione.
    • Poter convertire l'indirizzo di rete, inoltrare il traffico alla risorsa di destinazione nella subnet e restituire il traffico a Internet.

  • Gateway di rete virtuale: se il gateway è un gateway di rete virtuale ExpressRoute, un dispositivo connesso a Internet in locale può convertire l'indirizzo di rete e inoltrare il traffico alla risorsa di destinazione nella subnet tramite peering privato di ExpressRoute.

Se la rete virtuale è connessa a un gateway VPN di Azure, non associare una tabella di route alla subnet del gateway che include una route con una destinazione 0.0.0.0/0. Ciò potrebbe impedire il corretto funzionamento del gateway. Per altre informazioni, vedere Perché alcune porte sono aperte nel gateway VPN?

Per informazioni dettagliate sull'implementazione quando si usano gateway di rete virtuale tra Internet e Azure, vedere Rete perimetrale tra Azure e il data center locale.

Esempio di routing

Per illustrare i concetti di questo articolo, le sezioni seguenti descrivono:

• Uno scenario con requisiti.
• Route personalizzate necessarie per soddisfare i requisiti.
• Tabella di route esistente per una subnet che include le route predefinite e personalizzate necessarie per soddisfare i requisiti.

Requisiti

1. Implementare due reti virtuali nella stessa area di Azure e consentire alle risorse di comunicare tra le reti virtuali.

2. Consentire a una rete locale di comunicare in modo sicuro con entrambe le reti virtuali tramite un tunnel VPN su Internet. In alternativa, è possibile usare una connessione ExpressRoute, ma questo esempio usa una connessione VPN.

3. Per una sola subnet in una sola rete virtuale:

   • Instradare tutto il traffico in uscita dalla subnet tramite un'appliance virtuale di rete per l'ispezione e la registrazione. Escludere il traffico verso Archiviazione di Azure e all'interno della subnet da questo routing.
   • Non esaminare il traffico tra indirizzi IP privati all'interno della subnet. Consentire il flusso del traffico direttamente tra tutte le risorse.
   • Eliminare tutto il traffico in uscita destinato all'altra rete virtuale.
   • Consentire al traffico in uscita verso Archiviazione di Azure di raggiungere direttamente l'archivio, senza forzarlo attraverso un'appliance virtuale di rete.

4. Consentire tutto il traffico tra tutte le altre subnet e reti virtuali.

Implementazione

Il diagramma seguente illustra un'implementazione tramite il modello di distribuzione di Resource Manager che soddisfa i requisiti precedenti.

Le frecce indicano il flusso del traffico.

Tabelle di route

Di seguito sono riportate le tabelle di route per l'esempio di routing precedente.

Subnet1

La tabella di route per Subnet1 nel diagramma precedente contiene le route seguenti:

Ecco una spiegazione di ogni ID di route:

• ID1: Azure ha aggiunto automaticamente questa route a tutte le subnet di Virtual-network-1 perché 10.0.0.0/16 è l'unico intervallo di indirizzi definito nello spazio degli indirizzi per la rete virtuale. Se non si crea la route definita dall'utente nell'ID 2 della route, il traffico inviato a un indirizzo compreso tra 10.0.0.1 e 10.0.255.254 viene instradato all'interno della rete virtuale. Questo processo si verifica perché il prefisso è più lungo di 0.0.0.0/0 e non rientra nei prefissi degli indirizzi di altre route.

  Azure ha modificato automaticamente lo stato da Attivo a Non valido, quando è stato aggiunto ID2, una route definita dall'utente. Ha lo stesso prefisso della route predefinita e le route definite dall'utente sostituiscono le route predefinite. Lo stato di questa route è ancora Attivo per Subnet2 perché la tabella di route definita dall'utente, ID2, non è associata a Subnet2.

• ID2: Azure ha aggiunto questa route quando è stata associata una route definita dall'utente per il prefisso degli indirizzi 10.0.0.0/16 alla subnet Subnet1 nella rete virtuale Virtual-network-1. La route definita dall'utente specifica 10.0.100.4 come indirizzo IP dell'appliance virtuale perché l'indirizzo è l'indirizzo IP privato assegnato alla macchina virtuale dell'appliance virtuale. La tabella di route in cui questa route esiste non è associata a Subnet2, quindi la route non viene visualizzata nella tabella di route per Subnet2.

  Questa route sostituisce la route predefinita per il prefisso 10.0.0.0/16 (ID1), che instradava automaticamente il traffico indirizzato a 10.0.0.1 e 10.0.255.254 nella rete virtuale tramite il tipo di hop successivo Rete virtuale. Questa route esiste per soddisfare il requisito 3, ovvero forzare tutto il traffico in uscita attraverso un'appliance virtuale.

• ID3: Azure ha aggiunto questa route quando è stata associata una route definita dall'utente per il prefisso degli indirizzi 10.0.0.0/24 alla subnet Subnet1. Il traffico destinato agli indirizzi compresi tra 10.0.0.1 e 10.0.0.254 rimane all'interno della subnet. Il traffico non viene instradato all'appliance virtuale specificata nella regola precedente (ID2) perché ha un prefisso più lungo rispetto alla route ID2.

  Questa route non era associata a Subnet2, quindi non appare nella tabella di route per Subnet2. Questa route sostituisce la route ID2 per il traffico all'interno di Subnet1. Questa route esiste per soddisfare il requisito 3.

• ID4: Azure ha aggiunto automaticamente le route negli ID 4 e 5 per tutte le subnet all'interno di Virtual-network-1, quando la rete virtuale è stata sottoposta a peering con Virtual-network-2. Virtual-network-2 ha due intervalli di indirizzi nello spazio indirizzi: 10.1.0.0/16 e 10.2.0.0/16, quindi Azure ha aggiunto una route per ogni intervallo. Se non si creano le route definite dall'utente negli ID di route 6 e 7, il traffico inviato a qualsiasi indirizzo compreso tra 10.1.0.1-10.1.255.254 e 10.2.0.1-10.2.255.254 viene instradato alla rete virtuale con peering. Questo processo si verifica perché il prefisso è più lungo di 0.0.0.0/0 e non rientra nei prefissi degli indirizzi di altre route.

  Quando sono state aggiunte le route negli ID 6 e 7, Azure ha modificato automaticamente lo stato da Attivo a Non valido. Questo processo si verifica perché hanno gli stessi prefissi delle route negli ID 4 e 5, e le route definite dall'utente eseguono l'override delle route predefinite. Lo stato delle route negli ID 4 e 5 è ancora Attivo per Subnet2 perché la tabella di route in cui le route definite dall'utente negli ID 6 e 7 non sono associate a Subnet2. È stato creato un peering di rete virtuale per soddisfare il requisito 1.

• ID5: stessa spiegazione di ID4.

• ID6: Azure ha aggiunto questa route e la route in ID7 quando le route definite dall'utente per i prefissi degli indirizzi 10.1.0.0/16 e 10.2.0.0/16 sono state associate alla subnet Subnet1. Azure elimina il traffico destinato agli indirizzi compresi tra 10.1.0.1-10.1.255.254 e 10.2.0.1-10.2.255.254, anziché essere instradati alla rete virtuale con peering, perché le route definite dall'utente eseguono l'override delle route predefinite. Queste route non sono associate a Subnet2, quindi non appaiono nella tabella di route per Subnet2. Le route sostituiscono le route ID4 e ID5 per il traffico in uscita da Subnet1. Le route ID6 e ID7 esistono per soddisfare il requisito 3 per eliminare il traffico destinato all'altra rete virtuale.

• ID7: stessa spiegazione di ID6.

• ID8: Azure ha aggiunto automaticamente questa route per tutte le subnet di Virtual-network-1 quando è stato creato un gateway di rete virtuale di tipo VPN nella rete virtuale. Azure ha aggiunto l'indirizzo IP pubblico del gateway di rete virtuale alla tabella di route. Il traffico inviato a qualsiasi indirizzo compreso tra 10.10.0.1 e 10.10.255.254 viene indirizzato al gateway di rete virtuale. Il prefisso è più lungo di 0.0.0.0/0 e non rientra nei prefissi degli indirizzi delle altre route. È stato creato un gateway di rete virtuale per soddisfare il requisito 2.

• ID9: Azure ha aggiunto questa route quando è stata aggiunta una route definita dall'utente per il prefisso di indirizzo 10.10.0.0/16 alla tabella di route associata a Subnet1. Questa route sostituisce ID8. La route invia tutto il traffico destinato alla rete locale a un'appliance virtuale di rete per l'ispezione, anziché instradare il traffico direttamente in locale. Questa route è stata creata per soddisfare il requisito 3.

• ID10: Azure ha aggiunto automaticamente questa route alla subnet quando è stato abilitato un endpoint di servizio per un servizio di Azure per la subnet. Azure indirizza il traffico proveniente dalla subnet a un indirizzo IP pubblico del servizio, tramite la rete dell'infrastruttura di Azure. Il prefisso è più lungo di 0.0.0.0/0 e non rientra nei prefissi degli indirizzi delle altre route. Un endpoint di servizio è stato creato per soddisfare il requisito 3, per consentire al traffico destinato ad Archiviazione di Azure di raggiungere direttamente Archiviazione di Azure.

• ID11: Azure ha aggiunto automaticamente questa route alla tabella di route di tutte le subnet all'interno di Virtual-network-1 e Virtual-network-2. Il prefisso dell'indirizzo 0.0.0.0/0 è il prefisso più breve. Tutto il traffico inviato agli indirizzi di un prefisso degli indirizzi più lungo si basa su altre route.

  Per impostazione predefinita, Azure indirizza a Internet tutto il traffico destinato a indirizzi diversi da quelli specificati in una delle altre route. Azure ha modificato automaticamente lo stato da Attivo a Non valido per la subnet Subnet1 quando è stata associata una route definita dall'utente per il prefisso di indirizzo 0.0.0.0/0 (ID12). Lo stato della route è ancora Attivo per tutte le altre subnet di entrambe le reti virtuali, perché la route non è associata ad altre subnet di altre reti virtuali.

• ID12: Azure ha aggiunto questa route quando è stata associata una route definita dall'utente per il prefisso degli indirizzi 0.0.0.0/0 alla subnet Subnet1. La route definita dall'utente specifica 10.0.100.4 come indirizzo IP dell'appliance virtuale. Questa route non è associata a Subnet2, quindi non appare nella tabella di route per Subnet2. Tutto il traffico per gli indirizzi non inclusi nei prefissi degli indirizzi delle altre route viene inviato all'appliance virtuale.

  L'aggiunta di questa route ha modificato lo stato della route predefinita per il prefisso di indirizzo 0.0.0.0/0 (ID11) da Attivo a Non valido per Subnet1 perché una route definita dall'utente esegue l'override di una route predefinita. Questa route esiste per soddisfare il requisito 3.

Subnet2

La tabella di route per Subnet2 nel diagramma precedente contiene le route seguenti:

La tabella di route per Subnet2 contiene tutte le route predefinite create da Azure, il peering di reti virtuali facoltativo e le route facoltative del gateway di rete virtuale. Azure ha aggiunto le route facoltative a tutte le subnet della virtuale di rete quando sono stati aggiunti il gateway e il peering alla rete virtuale.

Azure ha rimosso le route per 10.0.0.0/8, 192.168.0.0/16 e 100.64.0.0.0/10 dalla tabella di route Subnet1 quando la route definita dall'utente per il prefisso degli indirizzi 0.0.0.0/0 è stata aggiunta a Subnet1.

Contenuti correlati

• Creare una tabella UDR con route e un'appliance virtuale di rete.
• Configurare BGP per un gateway VPN di Azure.
• Usare BGP con ExpressRoute.
• Visualizzare tutte le route di una subnet. Una tabella UDR mostra solo le route definite dall'utente, non le route predefinite e BGP per una subnet. La visualizzazione di tutte le route mostra le route predefinite, BGP e route definite dall'utente per la subnet in cui si trova un'interfaccia di rete.
• Determinare il tipo di hop successivo tra una macchina virtuale e un indirizzo IP di destinazione. È possibile usare la funzionalità hop successivo di Azure Network Watcher per determinare se il traffico esce da una subnet e viene instradato a dove deve essere.