Condividi tramite

Routing del traffico di rete virtuale

  • Articolo

Informazioni sul modo in cui Azure instrada il traffico tra Azure, l'ambiente locale e le 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. Per altre informazioni sulle reti virtuali e sulle subnet, vedere la panoramica della rete virtuale. È possibile eseguire l'override di alcune delle route di sistema di Azure usando 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 né rimuoverle, ma è possibile eseguire l'override di alcune route di sistema usando 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.

Default

Ogni route contiene un prefisso degli indirizzi e il tipo di hop successivo. Quando il traffico in uscita da una subnet viene inviato a un indirizzo IP compreso nel prefisso degli indirizzi di una route, la route che contiene il prefisso è quella usata da Azure. Vedere in che modo Azure seleziona una route quando più route contengono lo stesso prefisso oppure prefissi che si sovrappongono. Quando si crea una rete virtuale, Azure crea automaticamente le route di sistema predefinite seguenti per ogni subnet della rete virtuale:

Source (Sorgente) Prefissi degli indirizzi Tipo hop successivo
Predefinito Univoco per la rete virtuale Rete virtuale
Predefinito 0.0.0.0/0 Internet
Predefinita 10.0.0.0/8 None
Predefinita 172.16.0.0/12 None
Predefinita 192.168.0.0/16 None
Predefinita 100.64.0.0/10 None

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

  • 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 sostituiscono le route predefinite, Azure instrada verso Internet il traffico di tutti gli indirizzi non specificati da un intervallo di indirizzi all'interno di una rete virtuale. Esiste un'eccezione a questo routing. Se l'indirizzo di destinazione è di uno dei servizi di Azure, Azure instrada il traffico direttamente al servizio tramite la rete backbone di Azure, piuttosto che verso Internet. Il traffico tra i servizi di Azure non attraversa Internet, indipendentemente dall'area di Azure in cui si trova la rete virtuale o in cui viene distribuita un'istanza del servizio di Azure. È possibile eseguire l'override della route di sistema predefinita di Azure per il prefisso degli indirizzi 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 aggiunge altre route di sistema predefinite per diverse funzionalità di Azure, ma solo se si abilitano queste funzionalità. A seconda della funzionalità, Azure aggiunge route predefinite facoltative a subnet specifiche o a tutte le subnet della rete virtuale. Le altre route di sistema e i tipi di hop successivi che Azure potrebbe aggiungere quando si abilitano funzionalità diverse sono:

Source (Sorgente) Prefissi degli indirizzi Tipo hop successivo Subnet all'interno della rete virtuale a cui viene aggiunta la route
Default Univoco per la rete virtuale, ad esempio 10.1.0.0/16 Peering reti virtuali Tutte le date
Gateway di rete virtuale Prefissi annunciati dall'ambiente locale tramite BGP o configurati nel gateway di rete locale Gateway di rete virtuale Tutte le date
Default Multipla VirtualNetworkServiceEndpoint Solo la subnet per la quale è abilitato un endpoint di servizio.

  • Peering di reti virtuali: quando si crea un peering di reti virtuali tra due reti virtuali, il sistema aggiunge una route per ogni intervallo di indirizzi nello spazio di 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 con un gateway di rete virtuale tramite Border Gateway Protocol (BGP), il sistema aggiunge una route per ogni route. Queste route vengono propagate dal gateway di rete locale. È consigliabile riepilogare le route locali negli intervalli di indirizzi più ampi possibile, in modo da propagare il minor numero possibile 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 informazioni dettagliate, vedere Limiti di Azure.

  • VirtualNetworkServiceEndpoint: Azure aggiunge gli indirizzi IP pubblici per alcuni servizi alla tabella di route quando si abilita un endpoint di servizio per il servizio. Gli endpoint di servizio vengono abilitati per singole subnet all'interno di una rete virtuale, quindi la route viene aggiunta solo alla tabella di route di una subnet per la quale è abilitato un endpoint di servizio. Gli indirizzi IP pubblici dei servizi di Azure cambiano periodicamente. Azure gestisce automaticamente gli indirizzi nella tabella di route quando gli indirizzi cambiano. Vedere altre informazioni sugli endpoint servizio di rete virtuale e sui servizi per i quali è possibile creare endpoint di servizio.

    Nota

    I tipi di hop successivi Peering di rete virtuale e VirtualNetworkServiceEndpoint vengono aggiunti solo alle tabelle di route delle subnet che si trovano nelle 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

Le route personalizzate vengono create con route definite dall'utente oppure scambiando route tra un gateway di rete locale e un gateway di rete virtuale di Azure tramite Border Gateway Protocol (BGP).

personalizzato

Per personalizzare le route di traffico, non è consigliabile modificare le route predefinite, ma è 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, quindi la si associa a zero o più subnet della rete virtuale. A ogni subnet può essere associata una o nessuna tabella di route. Vedere Limiti di Azure per informazioni sul numero massimo di route che possono essere aggiunte a una tabella di route e sul numero massimo di tabelle di route definite dall'utente che possono essere create per ogni sottoscrizione di Azure. Quando crei una tabella di route e la associ 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 seguenti tipi di hop successivi durante la creazione di una route definita dall'utente:

  • Appliance virtuale: un'appliance virtuale è una macchina virtuale che generalmente esegue un'applicazione di rete, ad esempio un firewall. Per informazioni sulle 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. Questa impostazione disabilita il controllo di origine e destinazione di Azure per l'interfaccia di rete. 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.

      Nota

      Distribuire un'appliance virtuale in una subnet diversa dalle risorse instradate attraverso l'appliance stessa. La distribuzione di un'appliance virtuale nella stessa subnet, con la successiva applicazione di una tabella di route alla subnet che instrada il traffico attraverso l'appliance, può comportare loop di routing che impediscono al traffico di uscire dalla subnet.

      Un indirizzo IP privato hop successivo deve avere una connettività diretta senza dover instradare tramite il gateway ExpressRoute o la rete WAN virtuale. L'impostazione dell'hop successivo su un indirizzo IP senza connettività diretta ha come risultato una configurazione di routing 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.

    Puoi 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 che contiene il prefisso degli indirizzi 0.0.0.0/0, vedere prima Prefisso degli indirizzi 0.0.0.0/0.

  • Gateway di rete virtuale: specificare quando si vuole che il traffico destinato a prefissi degli indirizzi specifici venga indirizzato a un gateway di rete virtuale. Il gateway di rete virtuale deve essere creato con il tipo VPN. Non è possibile specificare un gateway di rete virtuale creato come tipo ExpressRoute in una route definita dall'utente perché con ExpressRoute è necessario usare BGP per le route personalizzate. Non è possibile specificare gateway di rete virtuale se si dispone di connessioni VPN ed ExpressRoute coesistenti. È possibile definire una route che indirizzi il traffico destinato al prefisso degli indirizzi 0.0.0.0/0 a un gateway di rete virtuale basato su route. 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 di indirizzo 0.0.0.0/0, vedere prima Prefisso degli indirizzi 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 elencare Nessuno per alcune delle route di sistema facoltative se non è configurata una funzionalità. Ad esempio, se None è elencato come indirizzo IP hop successivo con un tipo hop successivo del gateway di rete virtuale o dell'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. Vedere Esempio di routing per un esempio che illustra perché creare una route con il tipo di hop Rete virtuale.

  • Internet: specificare l’opzione Internet quando si vuole instradare esplicitamente a Internet il traffico destinato a un prefisso degli indirizzi oppure se si vuole che il traffico destinato ai servizi di Azure con indirizzi IP pubblici resti all'interno della rete backbone di Azure.

Non è possibile specificare Peering di reti virtuali o VirtualNetworkServiceEndpoint come tipo di hop successivo nelle route definite dall'utente. Le route con tipi di hop successivi Peering di reti virtuali o VirtualNetworkServiceEndpoint vengono create da Azure solo quando si configura un peering di reti virtuali oppure un endpoint di servizio.

Tag di servizio per le route definite dall'utente

È ora possibile specificare un tag del 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 aggiorna automaticamente il tag in caso di modifica degli indirizzi. In questo modo, vengono ridotti al minimo sia il numero di route da creare sia la complessità degli aggiornamenti frequenti alle route definite dall'utente. Attualmente puoi 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 dell’area geografica (ad esempio, Storage.EastUS, AppService.AustraliaCentral)

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

  3. Tag dell’area geografica di AzureCloud (ad esempio, AzureCloud.canadacentral, AzureCloud.eastasia)

  4. Tag AzureCloud

Per usare questa funzionalità, specifica un nome tag di 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 verso un'appliance virtuale usando: 

$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 è il seguente:

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 si fa riferimento per i tipi di hop successivi è diverso tra il portale di Azure e gli strumenti da riga di comando e tra i modelli di distribuzione Azure Resource Manager e classica. La tabella seguente elenca i nomi usati per fare riferimento a ogni tipo di hop successivo nei diversi strumenti e modelli di distribuzione:

Tipo hop successivo Interfaccia della riga di comando di Azure e PowerShell (Resource Manager) Interfaccia della riga di comando classica di Azure e PowerShell (classica)
Gateway di rete virtuale VirtualNetworkGateway VPNGateway
Rete virtuale VNetLocal VNETLocal (non disponibile nell'interfaccia della riga di comando classica in modalità modello di distribuzione classica)
Internet Internet Internet (non disponibile nell'interfaccia della riga di comando classica in modalità modello di distribuzione classica)
Appliance virtuale VirtualAppliance VirtualAppliance
None None Null (non disponibile nell'interfaccia della riga di comando classica in modalità modello di distribuzione classica)
Peering di rete virtuale Peering reti virtuali Non applicabile
Endpoint servizio di rete virtuale VirtualNetworkServiceEndpoint Non applicabile

Border gateway protocol

Un gateway di rete locale può scambiare le route con un gateway di rete virtuale di Azure tramite Border Gateway Protocol (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 di Microsoft Edge. Se si distribuisce un gateway di rete virtuale di tipo ExpressRoute, non è possibile creare route definite dall'utente per forzare il traffico verso il gateway di rete virtuale ExpressRoute. È possibile usare route definite dall'utente per forzare il traffico da ExpressRoute, ad esempio verso un'appliance virtuale di rete.

  • VPN: è possibile usare BGP. Per informazioni dettagliate, vedere BGP con connessioni VPN da sito a sito.

Quando si scambiano le route con Azure tramite BGP, viene aggiunta una route separata alla tabella di route di tutte le subnet di 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 delle route ER e Gateway VPN su una subnet mediante una proprietà in una tabella di route. Quando si disabilita la propagazione delle 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 connessioni VPN è ottenuta usando route personalizzate con gateway di rete virtuale come tipo di hop successivo. La propagazione della route non deve essere disabilitata in GatewaySubnet. Il gateway non funzionerà con questa impostazione disabilitata. Per maggiori dettagli, vedere le indicazioni su come disabilitare la propagazione della route del gateway di rete virtuale.

Modalità di selezione di una route da parte di Azure

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 specifica il prefisso degli indirizzi 10.0.0.0/24, l'altra specifica il prefisso degli indirizzi 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 degli indirizzi 10.0.0.0/24, rendendo 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

Nota

Le route di sistema per il traffico correlato alla rete virtuale, ai peering di rete virtuale o agli endpoint servizio di rete virtuale sono le route preferite anche se le route BGP sono più specifiche. Non è possibile eseguire l'override delle route con tipo hop successivo dell'endpoint servizio di rete virtuale, anche usando una tabella di route.

Una tabella di route contiene ad esempio le route seguenti:

Source (Sorgente) Prefissi degli indirizzi Tipo hop successivo
Predefinito 0.0.0.0/0 Internet
User 0.0.0.0/0 Gateway di rete virtuale

Quando il traffico è destinato a un indirizzo IP non compreso nei prefissi degli indirizzi di qualsiasi altra route presente nella tabella di route, Azure seleziona la route con l'origine Utente, perché le route definite dall'utente hanno una priorità più elevata delle route predefinite di sistema.

Vedere Esempio di routing per una tabella di route completa con la spiegazione delle route contenute.

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, non solo il traffico in uscita dalla subnet passa attraverso il gateway di rete virtuale o l'appliance virtuale, ma si verificano anche le modifiche seguenti 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 degli indirizzi 0.0.0.0/0 è Internet, il traffico in uscita dalla subnet destinato agli indirizzi IP pubblici dei servizi di Azure non lascia mai la rete backbone di Azure, indipendentemente dall'area di Azure in cui si trova la rete virtuale o il servizio di Azure. Quando tuttavia si crea una route definita dall'utente o BGP con un tipo di hop successivo Gateway di rete virtuale o Appliance virtuale, tutto il traffico (incluso quello inviato agli indirizzi IP pubblici dei servizi di Azure per i quali non sono stati abilitati endpoint di servizio) viene inviato al tipo di hop successivo specificato nella route. 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 della 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 informazioni dettagliate, vedere Perché alcune porte sono aperte nel gateway VPN?

Vedere Rete perimetrale tra Azure e il data center locale per i dettagli di implementazione quando si usano i gateway di rete virtuale tra Internet e Azure.

Esempio di routing

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

  • Uno scenario con requisiti

  • Le route personalizzate necessarie per soddisfare i requisiti

  • La tabella di route presente per una subnet che include le route predefinite e personalizzate necessarie per soddisfare i requisiti

Nota

Questo esempio non rappresenta l'implementazione consigliata. Viene fornito solo per illustrare i concetti di questo articolo.

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 in questo esempio viene usata 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 ispezionare il traffico tra gli 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

La figura seguente illustra un'implementazione tramite il modello di distribuzione Azure Resource Manager che soddisfa i requisiti precedenti:

Diagramma della rete.

Le frecce indicano il flusso del traffico.

Tabelle di route

Subnet1

La tabella di route per Subnet1 rappresentata nell'immagine contiene le route seguenti:

ID Origine Provincia Prefissi degli indirizzi Tipo hop successivo Indirizzo IP hop successivo Nome route definita dall'utente
1 Default Non valido 10.0.0.0/16 Rete virtuale
2 User Attive 10.0.0.0/16 Appliance virtuale 10.0.100.4 Within-VNet1
3 User Attive 10.0.0.0/24 Rete virtuale Within-Subnet1
4 Default Non valido 10.1.0.0/16 Peering reti virtuali
5 Default Non valido 10.2.0.0/16 Peering reti virtuali
6 User Attive 10.1.0.0/16 None ToVNet2-1-Drop
7 User Attive 10.2.0.0/16 None ToVNet2-2-Drop
8 Default Non valido 10.10.0.0/16 Gateway di rete virtuale [X.X.X.X]
9 User Attive 10.10.0.0/16 Appliance virtuale 10.0.100.4 To-On-Prem
10 Default Attive [X.X.X.X] VirtualNetworkServiceEndpoint
11 Default Non valido 0.0.0.0/0 Internet
12 User Attive 0.0.0.0/0 Appliance virtuale 10.0.100.4 Default-NVA

Di seguito è riportata la spiegazione di ogni ID 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 in route ID2, il traffico inviato a qualsiasi indirizzo compreso tra 10.0.0.1 e 10.0.255.254 verrà instradato all'interno della rete virtuale. Questo processo è dovuto al fatto che 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 è stata aggiunta la route ID2 definita dall'utente perché la route ha lo stesso prefisso della route predefinita e le route definite dall'utente sostituiscono le route predefinite. Lo stato della route è ancora Attivo per Subnet2, perché la tabella di route in cui si trova la route ID2 definita dall'utente non è associata a Subnet2.

  • ID2: Azure ha aggiunto questa route quando una route definita dall'utente per il prefisso degli indirizzi 10.0.0.0/16 è stata associata 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 si trova questa route non è associata a Subnet2, quindi non appare 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, per forzare tutto il traffico in uscita attraverso un'appliance virtuale.

  • ID3: Azure ha aggiunto questa route quando una route definita dall'utente per il prefisso degli indirizzi 10.0.0.0/24 è stata associata 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 queste route in ID 4 e 5 per tutte le subnet di Virtual-network-1, quando è stato eseguito il peering della rete virtuale con Virtual-network-2. Virtual-network-2 ha due intervalli di indirizzi nel proprio spazio degli indirizzi: 10.1.0.0/16 e 10.2.0.0/16, quindi Azure ha aggiunto una route per ogni intervallo. Se non si crea la route definita dall'utente in route IDs 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 verrà instradato all'interno della rete virtuale con peering. Questo processo è dovuto al fatto che 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 è dovuto al fatto che hanno gli stessi prefissi delle route negli ID 4 e 5 e che le route definite dall'utente eseguono l'override delle route predefinite. Lo stato delle route ID 4 e 5 è ancora Attivo per Subnet2, perché la tabella di route in cui si trovano le route ID 6 e 7 non è associata 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 ID7 quando sono state associate route definite dall'utente per i prefissi degli indirizzi 10.1.0.0/16 e 10.2.0.0/16 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, che non viene indirizzato alla rete virtuale con peering, perché le route definite dall'utente sostituiscono le 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 una route definita dall'utente per il prefisso degli indirizzi 10.10.0.0/16 è stata aggiunta alla tabella di route associata alla subnet Subnet1. Questa route sostituisce ID8. La route invia tutto il traffico destinato alla rete locale a un'appliance virtuale di rete per l'ispezione, piuttosto che indirizzare il traffico direttamente all'ambiente 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 di Virtual-network-1 e Virtual-network-2. Il prefisso degli indirizzi 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 alla subnet è stata associata una route definita dall'utente per il prefisso degli indirizzi 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 una route definita dall'utente per il prefisso degli indirizzi 0.0.0.0/0 è stata associata 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. Con l'aggiunta di questa route, lo stato della route predefinita per il prefisso degli indirizzi 0.0.0.0/0 (ID11) è cambiato da Attivo a Non valido per Subnet1, perché una route definita dall'utente sostituisce una route predefinita. Questa route esiste per soddisfare il terzo requisito.

Subnet2

La tabella di route per Subnet2 rappresentata nell'immagine contiene le route seguenti:

Origine Provincia Prefissi degli indirizzi Tipo hop successivo Indirizzo IP hop successivo
Default Attive 10.0.0.0/16 Rete virtuale
Default Attive 10.1.0.0/16 Peering di rete virtuale
Default Attive 10.2.0.0/16 Peering di rete virtuale
Default Attive 10.10.0.0/16 Gateway di rete virtuale [X.X.X.X]
Default Attive 0.0.0.0/0 Internet
Default Attive 10.0.0.0/8 None
Default Attive 100.64.0.0/10 None
Default Attive 192.168.0.0/16 None

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 i prefissi degli indirizzi 10.0.0.0/8, 192.168.0.0/16 e 100.64.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.

Passaggi successivi