Routing del traffico di rete virtuale
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 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 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 o a ogni subnet, quando si usano funzionalità di Azure specifiche.
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. Azure effettua il routing automatico del traffico tra le subnet usando le route create per ogni intervallo di indirizzi. Non è necessario definire gateway per consentire ad Azure di instradare il traffico tra subnet. Anche se una rete virtuale contiene subnet e ogni subnet ha un intervallo di indirizzi definito, 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 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. C'è 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 nell'area di Azure 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 le 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 può 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 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 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 (Border Gateway Protocol) 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 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 alle subnet di rete virtuale 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
È possibile creare route personalizzate o definite dall'utente (statiche) in Azure per eseguire l'override delle route di sistema predefinite di Azure o per aggiungere ulteriori route alla tabella di route di una subnet. 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 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. 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. Anche se l'abilitazione dell'inoltro IP è un'impostazione di Azure, può essere necessario abilitare l'inoltro IP anche nel sistema operativo della macchina virtuale affinché l'appliance inoltri il traffico tra gli indirizzi IP 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 rispetto alle risorse che instradano attraverso l'appliance virtuale. La distribuzione dell'appliance virtuale nella stessa subnet 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 il gateway ExpressRoute o 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. Invece di configurare una route definita dall'utente per il prefisso degli indirizzi 0.0.0.0/0, è possibile annunciare una route con il prefisso 0.0.0.0/0 tramite BGP, se è stato abilitato BGP per un gateway di rete virtuale VPN.
Nessuno: specificare quando si vuole eliminare il traffico verso un prefisso degli indirizzi, invece di inoltrarlo a una destinazione. Se una funzionalità non è completamente configurata, Azure può elencare Nessuno per alcune delle route di sistema facoltative. Se ad esempio è indicato Nessuno come Indirizzo IP hop successivo con Tipo hop successivoGateway di rete virtuale o Appliance virtuale, è possibile che il dispositivo non sia in esecuzione o non sia 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 vuole eseguire l'override del routing predefinito all'interno di 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 in modo esplicito il traffico destinato a un prefisso di indirizzo a Internet oppure 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. Le route con il peering di rete virtuale o i tipi di hop successivo VirtualNetworkServiceEndpoint vengono create solo da Azure, 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 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:
Tag dell’area geografica (ad esempio, Storage.EastUS, AppService.AustraliaCentral)
Tag di primo livello (ad esempio, Archiviazione, AppService)
Tag dell’area geografica di AzureCloud (ad esempio, AzureCloud.canadacentral, AzureCloud.eastasia)
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. In PowerShell, ad esempio, è possibile creare una nuova route per indirizzare il traffico inviato a un prefisso IP Archiviazione di Azure a 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à gestione dei servizi) |
| Internet | Internet | Internet (non disponibile nell'interfaccia della riga di comando classica in modalità gestione dei servizi) |
| Appliance virtuale | VirtualAppliance | VirtualAppliance |
| None | None | Null (non disponibile nell'interfaccia della riga di comando classica in modalità gestione dei servizi) |
| Peering di rete virtuale | Peering reti virtuali | Non applicabile |
| Endpoint servizio di rete virtuale | VirtualNetworkServiceEndpoint | Non applicabile |
Protocollo BGP (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:
ExpressRoute: è necessario usare BGP per annunciare le route locali al router 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 alla versione 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:
Route definita dall'utente
Route BGP
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.
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 rientra nel prefisso dell'indirizzo di qualsiasi altra route nella tabella di route di una 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 è che il traffico verso gli indirizzi IP pubblici dei servizi di Azure 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 non all'interno dei prefissi degli indirizzi 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 nella subnet da Internet. È possibile accedere alle risorse nella subnet da Internet indirettamente. 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 che il traffico attraversa 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 la domanda Perché determinate porte sono aperte nella mia gateway VPN? nelle Domande frequenti sul 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 deve essere un'implementazione consigliata o consigliata. Viene fornito solo per illustrare i concetti di questo articolo.
Requisiti
Implementare due reti virtuali nella stessa area di Azure e consentire alle risorse di comunicare tra le reti virtuali.
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.
Per una sola subnet in una sola rete virtuale:
Forzare tutto il traffico in uscita dalla subnet, ad eccezione di Archiviazione di Azure e del traffico interno alla subnet, attraverso un'appliance virtuale di rete per l'ispezione e la registrazione.
Non controllare 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.
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:
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 | Attivo | [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 per tutte le subnet all'interno di Virtual-network-1, perché 10.0.0.0/16 è l'unico intervallo di indirizzi definito nello spazio indirizzi per la rete virtuale. Se non si crea la route definita dall'utente in ROUTE ID2, il traffico inviato a un 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 è 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 si trova questa route non è associata a Subnet2, quindi 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, per 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 di indirizzo 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, piuttosto che essere indirizzato all'appliance virtuale specificata nella regola precedente (ID2), perché contiene un prefisso più lungo della route ID2. Questa route non è stata associata a Subnet2, quindi la route non viene visualizzata 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 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 verrà instradato alla 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 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 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 instradato alla rete virtuale con peering, perché le route definite dall'utente sostituiscono le route predefinite. Le route non sono associate a Subnet2, quindi le route non vengono visualizzate 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 all'interno di Virtual-network-1 quando è stato creato un gateway di rete virtuale di tipo VPN all'interno della 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, 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 un endpoint di servizio a un servizio di Azure è stato abilitato 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 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 è stata associata una route definita dall'utente per il prefisso di indirizzo 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 la route non viene visualizzata 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 | Attivo | 10.0.0.0/16 | Rete virtuale | |
| Default | Attivo | 10.1.0.0/16 | Peering di rete virtuale | |
| Default | Attivo | 10.2.0.0/16 | Peering di rete virtuale | |
| Default | Attivo | 10.10.0.0/16 | Gateway di rete virtuale | [X.X.X.X] |
| Default | Attivo | 0.0.0.0/0 | Internet | |
| Default | Attive | 10.0.0.0/8 | None | |
| Default | Attivo | 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 e il peering di rete virtuale 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
Creare una tabella di route definite dall'utente con route e un'appliance virtuale di rete
Visualizzare tutte le route di una subnet. Una tabella di route definite dall'utente mostra solo le route definite dall'utente, non le route BGP e predefinite di una subnet. La visualizzazione di tutte le route elenca le route predefinite, BGP e 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. La funzionalità di hop successivo di Azure Network Watcher consente di determinare se il traffico è in uscita da una subnet e viene indirizzato dove previsto.