Come configurare i criteri di routing e degli intenti per l'hub della rete WAN virtuale

rete WAN virtuale finalità di routing dell'hub consente di configurare criteri di routing semplici e dichiarativi per inviare il traffico a soluzioni di sicurezza in transito come Firewall di Azure, appliance virtuali di rete o soluzioni SaaS (Software-as-a-Service) distribuite all'interno dell'hub rete WAN virtuale.

Background

I criteri di routing e finalità di routing consentono di configurare l'hub rete WAN virtuale per Rete virtuale inoltrare il traffico a un'Firewall di Azure, firewall di nuova generazione (NGFW), appliance virtuale di rete (NVA) o soluzione SaaS (Security Software as a Service) distribuita nell'hub virtuale.

Esistono due tipi di criteri di routing: traffico Internet e traffico privato. Ogni hub della rete WAN virtuale può avere al massimo un criterio di routing del traffico Internet e un criterio di routing del traffico privato, ognuno con una sola risorsa hop successivo. Anche se il traffico privato include prefissi di indirizzi di rete virtuale e di ramo, i criteri di routing li considerano come un'unica entità all'interno dei concetti relativi alle finalità di routing.

• Criteri di routing del traffico Internet: quando un criterio di routing del traffico Internet è configurato in un hub rete WAN virtuale, in tutti i rami (VPN utente remoto (VPN da punto a sito), VPN da sito a sito ed ExpressRoute) e Rete virtuale connessioni a tale hub rete WAN virtuale inoltra il traffico associato a Internet a Firewall di Azure, provider di sicurezza di terze parti, appliance virtuale di rete o soluzione SaaS specificata come parte dei criteri di routing.

  In altre parole, quando un criterio di routing del traffico Internet è configurato in un hub rete WAN virtuale, rete WAN virtuale annuncia una route predefinita (0.0.0.0/0) a tutti gli spoke, i gateway e le appliance virtuali di rete (distribuite nell'hub o spoke).

• Criteri di routing del traffico privato: quando un criterio di routing del traffico privato è configurato in un hub di rete WAN virtuale, tutto il ramo e Rete virtuale traffico all'interno e all'esterno dell'hub rete WAN virtuale, incluso il traffico tra hub, viene inoltrato al Firewall di Azure hop successivo, Appliance virtuale di rete o risorsa della soluzione SaaS.

  In altre parole, quando viene configurato un criterio di routing del traffico privato nell'hub di rete WAN virtuale, in tutte le soluzioni da ramo a ramo, da ramo a rete virtuale, da rete virtuale a ramo e traffico tra hub viene inviato tramite Firewall di Azure, appliance virtuale di rete o soluzione SaaS distribuita nell'hub rete WAN virtuale.

Casi d'uso

La sezione seguente descrive due scenari comuni in cui i criteri di routing vengono applicati a hub della rete WAN virtuale protetti.

Tutti gli hub rete WAN virtuale sono protetti (distribuiti con Firewall di Azure, appliance virtuale di rete o soluzione SaaS)

In questo scenario, tutti gli hub rete WAN virtuale vengono distribuiti con una soluzione SaaS, Firewall di Azure Firewall di Azure, appliance virtuale di rete o SaaS. In questo scenario è possibile configurare un criterio di routing del traffico Internet, un criterio di routing del traffico privato o entrambi in ogni hub della rete WAN virtuale.

Si consideri la configurazione seguente in cui Hub 1 e Hub 2 hanno criteri di routing sia per il traffico privato che per il traffico Internet.

Configurazione dell'Hub 1:

• Criteri di traffico privato con Firewall di Azure, appliance virtuale di rete o soluzione SaaS dell'hub hop successivo 1
• Criteri di traffico Internet con l'hub hop successivo 1 Firewall di Azure, appliance virtuale di rete o soluzione SaaS

Configurazione dell'Hub 2:

• Criteri di traffico privato con la soluzione Next Hop Hub 2 Firewall di Azure, appliance virtuale di rete o SaaS
• Criteri di traffico Internet con soluzione di Firewall di Azure, appliance virtuale di rete o SaaS dell'hub hop successivo 2

Di seguito sono riportati i flussi di traffico risultanti da una configurazione di questo tipo.

Da	Per	Reti virtuali Hub 1	Rami Hub 1	Reti virtuali Hub 2	Rami Hub 2	Internet
Reti virtuali Hub 1	→	AzFW o NVA di Hub 1	AzFW o NVA di Hub 1	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 AzFW, appliance virtuale di rete o SaaS
Rami hub 1	→	Hub 1 AzFW, appliance virtuale di rete o SaaS	Hub 1 AzFW, appliance virtuale di rete o SaaS	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 AzFW, appliance virtuale di rete o SaaS
Reti virtuali Hub 2	→	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS
Rami Hub 2	→	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 1 e 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2AzFW, appliance virtuale di rete o SaaS

Distribuzione di hub della rete WAN virtuale protetti e normali

In questo scenario, non tutti gli hub nella rete WAN sono hub della rete WAN virtuale protetti (hub in cui è distribuita una soluzione di sicurezza).

Si consideri la configurazione seguente in cui l'Hub 1 (normale) e l'Hub 2 (protetto) sono distribuiti in una rete WAN virtuale. L'Hub 2 ha criteri di routing sia per il traffico privato che per il traffico Internet.

Configurazione Hub 1:

• N/D (non è possibile configurare i criteri di routing se l'hub non viene distribuito con Firewall di Azure, appliance virtuale di rete o soluzione SaaS)

Configurazione Hub 2:

• Criteri di traffico privato con la soluzione Hub hop successivo 2 Firewall di Azure, appliance virtuale di rete o SaaS.
• Criteri di traffico Internet con la soluzione Hub hop successivo 2 Firewall di Azure, appliance virtuale di rete o SaaS.

Di seguito sono riportati i flussi di traffico risultanti da una configurazione di questo tipo. I rami e le reti virtuali connesse all'Hub 1 non possono accedere a Internet tramite una soluzione di sicurezza distribuita nell'hub perché la route predefinita (0.0.0.0/0) non viene propagata tra gli hub.

Da	Per	Reti virtuali Hub 1	Rami Hub 1	Reti virtuali Hub 2	Rami Hub 2	Internet
Reti virtuali Hub 1	→	Diretto	Diretto	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	-
Rami hub 1	→	Diretto	Diretto	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	-
Reti virtuali Hub 2	→	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS
Rami Hub 2	→	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS	Hub 2 AzFW, appliance virtuale di rete o SaaS

Limitazioni note

• La tabella seguente descrive l'avaiablility della finalità di routing in ambienti Azure diversi.
  • La finalità di routing non è disponibile in Mirosoft Azure gestito da 21 Vianet.
  • Palo Alto Cloud NGFW è disponibile solo in Pubblico di Azure. Contattare Palo Alto Networks per quanto riguarda l'avaialbility of Cloud NGFW in Azure per enti pubblici e Microsoft Azure gestito da Viacom.
  • Le appliance virtuali di rete non sono disponibili in tutte le aree Azure per enti pubblici. Contattare il partner dell'appliance virtuale di rete per quanto riguarda la disponibilità in Azure per enti pubblici.

Ambiente cloud	Firewall di Azure	Appliance virtuale di rete	Soluzioni SaaS
Pubblico di Azure	Sì	Sì	Sì
Azure Government	Sì	Limitato	No
Microsoft Azure gestito da 21 Vianet	No	No	No

• La finalità di routing semplifica il routing gestendo le associazioni e le propagazioni delle tabelle di route per tutte le connessioni (Rete virtuale, VPN da sito a sito, VPN da punto a sito ed ExpressRoute). Di conseguenza, le reti WAN virtuali con tabelle di route personalizzate e criteri personalizzati non possono essere usate con i costrutti della finalità di routing.
• ExpressRoute crittografato (tunnel VPN da sito a sito in esecuzione su circuiti ExpressRoute) è supportato negli hub in cui la finalità di routing è configurata se Firewall di Azure è configurato per consentire il traffico tra endpoint del tunnel VPN (IP privato del gateway VPN da sito a sito e IP privato del dispositivo VPN locale). Per altre informazioni sulle configurazioni necessarie, vedere ExpressRoute crittografato con finalità di routing.
• I casi d'uso di connettività seguenti non sono supportati con la finalità di routing:
  • Le route statiche nell'oggetto defaultRouteTable che puntano a una connessione di rete virtuale non possono essere usate insieme alla finalità di routing. Tuttavia, è possibile usare la funzionalità di peering BGP.
  • Le route statiche nella connessione Rete virtuale con "propagazione route statica" non vengono applicate alla risorsa hop successivo specificata nei criteri di routing privato. Il supporto per l'applicazione di route statiche in connessioni di rete virtuale a criteri di routing privati hop successivo è contenuto nella roadmap.
  • La possibilità di distribuire sia un'NVA per la connettività SD-WAN che una soluzione SaaS o NVA firewall separata nello stesso hub della rete WAN virtuale è attualmente nella roadmap. Quando la finalità di routing è configurata con la soluzione SaaS o NVA firewall come hop successivo, ci sono effetti sulla connettività tra l'NVA SD-WAN e Azure. Distribuire invece l'NVA SD-WAN e la soluzione SaaS o NVA firewall o SaaS in hub virtuali diversi. In alternativa, è anche possibile distribuire l'NVA SD-WAN in una rete virtuale spoke connessa all'hub e sfruttare la funzionalità di peering BGP dell'hub virtuale.
  • Le appliance virtuali di rete (NVA) possono essere specificate come risorsa hop successivo per la finalità di routing solo se sono firewall di nuova generazione o firewall di nuova generazione a doppio ruolo e NVA SD-WAN. Attualmente, checkpoint, fortinet-ngfw e fortinet-ngfw-and-sdwan sono le uniche appliance virtuali di rete idonee per essere configurate come hop successivo per la finalità di routing. Se si tenta di specificare un'altra appliance virtuale di rete, la creazione della finalità di routing ha esito negativo. È possibile controllare il tipo di NVA passando all'hub virtuale -> Appliance virtuali di rete e quindi esaminando il campo Fornitore. Anche Palo Alto Networks Cloud NGFW è supportato come hop successivo per la finalità di routing, ma viene considerato un hop successivo di tipo Soluzione SaaS.
  • Gli utenti che usano l’intento di pianificazione percorso e vogliono connettere più circuiti ExpressRoute alla rete WAN virtuale e inviare traffico tra questi componenti tramite una soluzione di sicurezza implementata nell’hub, possono aprire un caso di supporto per abilitare questa operazione. Per altre informazioni, fare riferimento all'abilitazione della connettività tra circuiti ExpressRoute.

Limiti dello spazio indirizzi della rete virtuale

Per i clienti che usano la finalità di routing, il numero massimo di spazi indirizzi in tutte le reti virtuali direttamente connessi a un singolo hub della rete WAN virtuale è 400. Questo limite si applica singolarmente a ogni hub della rete WAN virtuale in una distribuzione della rete WAN virtuale. Gli spazi indirizzi della rete virtuale connessi a hub remoti (altri hub della rete WAN virtuale nella stessa rete WAN virtuale) non vengono conteggiati per questo limite.

Se il numero di spazi indirizzi della rete virtuale direttamente connessi a un hub supera il limite, l'abilitazione o l'aggiornamento della finalità di routing nell'hub virtuale avrà esito negativo. Per gli hub già configurati con la finalità di routing in cui gli spazi degli indirizzi della rete virtuale superano il limite a seguito di un'operazione come un aggiornamento dello spazio indirizzi della rete virtuale, lo spazio indirizzi appena connesso potrebbe non essere instradabile.

Richiedere in modo proattivo un aumento del limite se il numero totale di spazi indirizzi in tutte le reti virtuali connesse in locale supera il 90% del limite documentato o se sono previste operazioni di distribuzione o espansione della rete pianificate che aumentano il numero di spazi indirizzi della rete virtuale oltre il limite.

Nella tabella seguente vengono forniti esempi di calcoli dello spazio indirizzi della rete virtuale.

Hub virtuale	Numero reti virtuali	Spazi indirizzi per rete virtuale	Numero totale di spazi indirizzi di rete virtuale connessi all'hub virtuale	Azione suggerita
Hub 1	200	1	200	Nessuna azione necessaria, monitorare il numero di spazi indirizzi.
Hub 2	150	3	450	Richiedere un aumento del limite per usare la finalità di routing.
Hub 3	370	1	370	Richiedere un aumento del limite.

È possibile usare lo script di PowerShell seguente per approssimare il numero di spazi indirizzi nelle reti virtuali connessi a un singolo hub della rete WAN virtuale. Eseguire questo script per tutti gli hub della rete WAN virtuale nella rete WAN virtuale. Una metrica di Monitoraggio di Azure che consente di monitorare e configurare gli avvisi negli spazi indirizzi della rete virtuale connessi è nella roadmap.

Assicurarsi di modificare l'ID risorsa dell'hub della rete WAN virtuale nello script in modo che corrisponda all'ambiente. Se si dispone di connessioni di rete virtuale tra tenant, assicurarsi di disporre di autorizzazioni sufficienti per la lettura dell'oggetto connessione rete virtuale della rete WAN virtuale e la risorsa rete virtuale connessa.

$hubVNETconnections = Get-AzVirtualHubVnetConnection -ParentResourceId "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/virtualHubs/<virtual hub name>"
$addressSpaceCount = 0
  
foreach($connection in $hubVNETconnections) {
  try{
    $resourceURI = $connection.RemoteVirtualNetwork.Id
    $RG = ($resourceURI -split "/")[4]
    $name = ($resourceURI -split "/")[8]
    $VNET = Get-AzVirtualNetwork -Name $name -ResourceGroupName $RG -ErrorAction "Stop"
    $addressSpaceCount += $VNET.AddressSpace.AddressPrefixes.Count
  }
  catch{
    Write-Host "An error ocurred  while processing VNET connected to Virtual WAN hub with resource URI:  " -NoNewline
    Write-Host $resourceURI 
    Write-Host "Error Message: " -ForegroundColor Red
    Write-Host $_.Exception.Message -ForegroundColor Red 
  }
  finally{
  }
}
Write-Host "Total Address Spaces in VNETs connected to this Virtual WAN Hub: " -ForegroundColor Green -NoNewline
Write-Host $addressSpaceCount -ForegroundColor Green

Considerazioni

I clienti che attualmente usano Firewall di Azure nell'hub della rete WAN virtuale senza finalità di routing possono abilitare la finalità di routing usando Gestione firewall di Azure, il portale di routing dell'hub della rete WAN virtuale o altri strumenti di gestione di Azure (PowerShell, interfaccia della riga di comando, API REST).

Prima di abilitare la finalità di routing, considerare quanto segue:

• La finalità di routing può essere configurata solo negli hub la cui tabella defaultRouteTable non contiene tabelle di route personalizzate e route statiche per cui l'hop successivo è Connessione rete virtuale. Per altre informazioni, vedere la sezione Prerequisiti.
• Salvare una copia dei gateway, delle connessioni e delle tabelle di route prima di abilitare la finalità di routing. Il sistema non salverà né applicherà automaticamente le configurazioni precedenti. Per altre informazioni, vedere la strategia di rollback.
• La finalità di routing modifica le route statiche in defaultRouteTable. A causa delle ottimizzazioni del portale di Azure, lo stato di defaultRouteTable dopo la configurazione della finalità di routing può essere diverso se si configura la finalità di routing usando REST, l'interfaccia della riga di comando o PowerShell. Per altre informazioni, vedere Route statiche.
• L'abilitazione della finalità di routing influisce sull'annuncio dei prefissi in locale. Per altre informazioni, vedere annunci di prefissi.
• È possibile aprire un caso di supporto per abilitare la connettività tra circuiti ExpressRoute tramite un'appliance Firewall nell'hub. L'abilitazione di questo modello di connettività modifica i prefissi annunciati ai circuiti ExpressRoute. Per altre informazioni, vedere Informazioni su ExpressRoute.
• La finalità di routing è l'unico meccanismo nella rete WAN virtuale che consente di abilitare l'ispezione del traffico tra hub tramite appliance di sicurezza distribuite nell'hub. L'ispezione del traffico tra hub richiede anche l'abilitazione della finalità di routing in tutti gli hub per garantire che il traffico venga instradato in modo simmetrico tra le appliance di sicurezza distribuite negli hub della rete WAN virtuale.
• La finalità di routing invia la rete virtuale e il traffico locale alla risorsa hop successivo specificata nel criterio di routing. rete WAN virtuale programmi la piattaforma Azure sottostante per instradare il traffico locale e Rete virtuale in conformità ai criteri di routing configurati e non elabora il traffico attraverso il router dell'hub virtuale. Poiché i pacchetti indirizzati tramite finalità di routing non vengono elaborati dal router, non è necessario allocare unità di infrastruttura di routing aggiuntive per l'inoltro dei pacchetti del piano dati negli hub configurati con finalità di routing. Tuttavia, potrebbe essere necessario allocare unità di infrastruttura di routing aggiuntive in base al numero di Macchine virtuali in Rete virtuale connessi all'hub di rete WAN virtuale.
• La finalità di routing consente di configurare diverse risorse hop successivo per criteri di routing privati e di Internet. Ad esempio, è possibile impostare l'hop successivo per i criteri di routing privato su Firewall di Azure nell'hub e l'hop successivo per i criteri di routing Internet su una soluzione NVA o SaaS nell'hub. Poiché le soluzioni SaaS e le appliance virtuali di rete del firewall vengono distribuite nella stessa subnet nell'hub rete WAN virtuale, la distribuzione di soluzioni SaaS con un'appliance virtuale di rete del firewall nello stesso hub può influire sulla scalabilità orizzontale delle soluzioni SaaS perché sono disponibili meno indirizzi IP per la scalabilità orizzontale. Inoltre, è possibile avere al massimo una soluzione SaaS distribuita in ogni hub rete WAN virtuale.

Prerequisiti

Per abilitare la finalità e i criteri di routing, l'hub virtuale deve soddisfare i prerequisiti seguenti:

• Con l'hub virtuale non devono essere distribuite tabelle di route personalizzate. Le uniche tabelle di route esistenti sono noneRouteTable e defaultRouteTable.
• Non è possibile avere route statiche con Connessione rete virtuale come hop successivo. È possibile avere route statiche nella tabella defaultRouteTable con Firewall di Azure come hop successivo.

L'opzione per configurare la finalità di routing è disattivata per gli hub che non soddisfano i requisiti precedenti.

Per l'uso della finalità di routing (abilitare l'opzione tra hub) in Gestione firewall di Azure è previsto un requisito aggiuntivo:

• Le route create da Gestione firewall di Azure seguono la convenzione di denominazione private_traffic, internet_traffic o all_traffic. Pertanto, tutte le route nella tabella defaultRouteTable devono seguire questa convenzione.

Strategia di fallback

La finalità di routing semplifica il routing e la configurazione gestendo le associazioni e le propagazioni di route per tutte le connessioni di un hub.

Nella tabella seguente vengono descritte la tabella di route associata e le tabelle di route propagate di tutte le connessioni dopo la configurazione della finalità di routing.

Configurazione della finalità di routing	Tabella di route associata	Tabelle di route propagate
Internet	defaultRouteTable	Etichetta predefinita (defaultRouteTable di tutti gli hub nella rete WAN virtuale)
Privata	defaultRouteTable	noneRouteTable
Internet e privato	defaultRouteTable	noneRouteTable

Route statiche in defaultRouteTable

La sezione seguente descrive in che modo la finalità di routing gestisce le route statiche nella tabella defaultRouteTable quando la finalità di routing viene abilitata in un hub. Le modifiche apportate dalla finalità di routing a defaultRouteTable sono irreversibili.

Se si rimuove la finalità di routing, sarà necessario ripristinare manualmente la configurazione precedente. È quindi consigliabile salvare uno snapshot della configurazione prima di abilitare la finalità di routing.

Gestione firewall di Azure e portale hub della rete WAN virtuale

Quando la finalità di routing è abilitata nell'hub, le route statiche corrispondenti ai criteri di routing configurati vengono create automaticamente in defaultRouteTable. Queste route sono:

Nome di route	Prefissi	Risorsa hop successivo
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall di Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall di Azure

Si consideri, ad esempio, lo scenario in cui defaultRouteTable ha le route seguenti prima di configurare la finalità di routing:

Nome di route	Prefissi	Risorsa hop successivo
private_traffic	192.168.0.0/16, 172.16.0.0/12, 40.0.0.0/24, 10.0.0.0/24	Firewall di Azure
to_internet	0.0.0.0/0	Firewall di Azure
additional_private	10.0.0.0/8, 50.0.0.0/24	Firewall di Azure

L'abilitazione della finalità di routing in questo hub risulterebbe nello stato finale seguente di defaultRouteTable. Tutti i prefissi che non sono RFC1918 o 0.0.0.0/0 vengono consolidati in una singola route denominata private_traffic.

Nome di route	Prefissi	Risorsa hop successivo
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall di Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall di Azure
private_traffic	40.0.0.0/24, 10.0.0.0/24, 50.0.0.0/24	Firewall di Azure

Altri metodi (PowerShell, REST, CLI)

La creazione della finalità di routing tramite metodi non di portale crea automaticamente le route dei criteri corrispondenti in defaultRouteTable. Rimuove inoltre tutti i prefissi nelle route statiche che corrispondono esattamente a 0.0.0.0/0 o a supernet RFC1918 (10.0.0.0/8, 192.168.0.0/16 o 172.16.0.0/12). Tuttavia, altre route statiche non vengono consolidate automaticamente.

Si consideri, ad esempio, lo scenario in cui defaultRouteTable ha le route seguenti prima di configurare la finalità di routing:

Nome di route	Prefissi	Risorsa hop successivo
firewall_route_ 1	10.0.0.0/8	Firewall di Azure
firewall_route_2	192.168.0.0/16, 10.0.0.0/24	Firewall di Azure
firewall_route_3	40.0.0.0/24	Firewall di Azure
to_internet	0.0.0.0/0	Firewall di Azure

La tabella seguente rappresenta lo stato finale di defaultRouteTable dopo la corretta creazione della finalità di routing. Si noti che firewall_route_1 e to_internet sono state rimosse automaticamente perché gli unici prefissi in tali route erano 10.0.0.0/8 e 0.0.0.0.0/0. firewall_route_2 è stata modificata per rimuovere 192.168.0.0/16 perché tale prefisso è un prefisso aggregato RFC1918.

Nome di route	Prefissi	Risorsa hop successivo
_policy_PrivateTraffic	10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12	Firewall di Azure
_policy_PublicTraffic	0.0.0.0/0	Firewall di Azure
firewall_route_2	10.0.0.0/24	Firewall di Azure
firewall_route_3	40.0.0.0/24	Firewall di Azure

Annuncio del prefisso in locale

La sezione seguente descrive il modo in cui la rete WAN virtuale annuncia le route in locale dopo la configurazione della finalità di routing in un hub virtuale.

Criteri di routing Internet

Se si abilitano i criteri di routing Internet nell'hub virtuale, la route predefinita 0.0.0.0/0 viene annunciata a tutte le connessioni all'hub (ExpressRoute della rete virtuale, VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete nell'hub e connessioni BGP) in cui il flag Propaga route predefinita o Abilita la sicurezza Internet è impostato su true. È possibile impostare questo flag su false per tutte le connessioni che non devono apprendere la route predefinita.

Criterio di routing privato

Quando un hub virtuale è configurato con un criterio di routing privato, la rete WAN virtuale annuncia le route alle connessioni locali nel modo seguente:

• Route corrispondenti ai prefissi appresi dalle reti virtuali dell'hub locale, ExpressRoute, VPN da sito a sito, VPN da punto a sito, NVA nell'hub o connessioni BGP connesse all'hub corrente.
• Route corrispondenti ai prefissi appresi dalle reti virtuali dell'hub remoto, ExpressRoute, VPN da sito a sito, VPN da punto a sito, NVA nell'hub o connessioni BGP in cui sono configurati criteri di routing privato.
• Route corrispondenti ai prefissi appresi dalle reti virtuali dell'hub remoto, ExpressRoute, VPN da sito a sito, VPN da punto a sito, NVA nell'hub e connessioni BGP in cui la finalità di routing non è configurata e le connessioni remote vengono propagate alla tabella defaultRouteTable dell'hub locale.
• I prefissi appresi da un circuito ExpressRoute non vengono annunciati ad altri circuiti ExpressRoute a meno che non sia abilitata la Copertura globale. Se si vuole abilitare il transito da ExpressRoute a ExpressRoute tramite una soluzione di sicurezza distribuita nell'hub, aprire un caso di supporto. Per altre informazioni, vedere Abilitazione della connettività tra circuiti ExpressRoute.

Scenari di routing chiave

La sezione seguente descrive alcuni scenari di routing chiave e comportamenti di routing durante la configurazione della finalità di routing in un hub rete WAN virtuale.

Connettività di transito tra circuiti ExpressRoute con finalità di routing

La connettività di transito tra circuiti ExpressRoute all'interno della rete WAN virtuale viene fornita tramite due configurazioni diverse. Poiché queste due configurazioni non sono compatibili, i clienti devono scegliere un'opzione di configurazione per supportare la connettività di transito tra due circuiti ExpressRoute.

• Copertura globale di ExpressRoute: questo servizio consente a due circuiti abilitati per Copertura globale di scambiarsi traffico direttamente, senza transitare per l'hub virtuale.
• Criterio di routing privato della finalità di routing: la configurazione dei criteri di routing privato consente a due circuiti ExpressRoute di scambiarsi traffico tramite una soluzione di sicurezza distribuita nell'hub.

La connettività tra circuiti ExpressRoute tramite un'appliance firewall nell'hub con il criterio di routing privato della finalità di routing è disponibile nelle configurazioni seguenti:

• Entrambi i circuiti ExpressRoute sono connessi allo stesso hub e nell'hub è configurato un criterio di routing privato.
• I circuiti ExpressRoute sono connessi a hub diversi e in entrambi gli hub è configurato un criterio di routing privato. Pertanto, in entrambi gli hub deve essere distribuita una soluzione di sicurezza.

Considerazioni sul routing con ExpressRoute

Dopo aver abilitato la connettività di transito tra circuiti ExpressRoute usando un'appliance firewall distribuita nell'hub virtuale, si possono prevedere i cambiamenti seguenti nel comportamento di annuncio delle route a ExpressRoute locale:

• La rete WAN virtuale annuncia automaticamente prefissi aggregati RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) all'ambiente locale connesso a ExpressRoute. Queste route aggregate vengono annunciate in aggiunta alle route descritte nella sezione precedente.
• La rete WAN virtuale annuncia automaticamente tutte le route statiche in defaultRouteTable all'ambiente locale connesso al circuito ExpressRoute. Ciò significa che la rete WAN virtuale annuncia le route specificate nella casella di testo del prefisso del traffico privato all'ambiente locale.

A causa di queste modifiche agli annunci delle route, ciò significa che l'ambiente locale connesso a ExpressRoute non può annunciare intervalli di indirizzi esatti per gli intervalli di indirizzi aggregati RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Assicurarsi di annunciare subnet più specifiche (all'interno di intervalli RFC1918) anziché aggregare supernet ed eventuali prefissi nella casella di testo Traffico privato.

Inoltre, se il circuito ExpressRoute annuncia un prefisso non RFC1918 ad Azure, assicurarsi che gli intervalli di indirizzi inseriti nella casella di testo dei prefissi del traffico privato siano meno specifici delle route annunciate da ExpressRoute. Ad esempio, se il circuito ExpressRoute annuncia 40.0.0.0/24 dall'ambiente locale, inserire un intervallo CIDR /23 o superiore nella casella di testo relativa al prefisso del traffico privato (ad esempio: 40.0.0.0/23).

Gli annunci di route ad altri ambienti locali (VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete) non sono interessati dall'abilitazione della connettività di transito da ExpressRoute a ExpressRoute tramite un'appliance di sicurezza distribuita nell'hub.

ExpressRoute crittografato

Per usare ExpressRoute crittografato (tunnel VPN da sito a sito in esecuzione su un circuito ExpressRoute) con criteri di routing privato della finalità di routing, configurare una regola del firewall per consentire il traffico tra gli indirizzi IP privati del tunnel del gateway VPN da sito a sito della rete WAN virtuale (origine) e il dispositivo VPN locale (destinazione). Per i clienti che usano l'ispezione approfondita dei pacchetti nel dispositivo firewall, è consigliabile escludere il traffico tra questi IP privati dall'ispezione approfondita dei pacchetti.

È possibile ottenere gli indirizzi IP privati del tunnel del gateway VPN da sito a sito della rete WAN virtuale scaricando la configurazione VPN e visualizzando vpnSiteConnections -> gatewayConfiguration - >IPAddresses. Gli indirizzi IP elencati nel campo IPAddresses sono gli IP privati assegnati a ogni istanza del gateway VPN da sito a sito usato per terminare i tunnel VPN su ExpressRoute. Nell'esempio seguente, gli indirizzi IP del tunnel nel gateway sono 192.168.1.4 e 192.168.1.5.

 "vpnSiteConnections": [
      {
        "hubConfiguration": {
          "AddressSpace": "192.168.1.0/24",
          "Region": "South Central US",
          "ConnectedSubnets": [
            "172.16.1.0/24",
            "172.16.2.0/24",
            "172.16.3.0/24",
            "192.168.50.0/24",
            "192.168.0.0/24"
          ]
        },
        "gatewayConfiguration": {
          "IpAddresses": {
            "Instance0": "192.168.1.4",
            "Instance1": "192.168.1.5"
          },
          "BgpSetting": {
            "Asn": 65515,
            "BgpPeeringAddresses": {
              "Instance0": "192.168.1.15",
              "Instance1": "192.168.1.12"
            },
            "CustomBgpPeeringAddresses": {
              "Instance0": [
                "169.254.21.1"
              ],
              "Instance1": [
                "169.254.21.2"
              ]
            },
            "PeerWeight": 0
          }
        }

Gli indirizzi IP privati usati dai dispositivi locali per la terminazione VPN sono gli IP specificati come parte della connessione del collegamento di sito VPN.

Usando la configurazione VPN di esempio e il sito VPN precedenti, creare regole del firewall per consentire il traffico seguente. Nelle regole configurate, gli indirizzi IP del gateway VPN devono essere l'IP di origine e il dispositivo VPN locale deve essere l'IP di destinazione.

Parametro della regola	Valore
IP di origine	192.168.1.4 e 192.168.1.5
Porta di origine	*
IP di destinazione	10.100.0.4
Porta di destinazione	*
Protocollo	QUALSIASI

Prestazioni per Encrypted ExpressRoute

La configurazione dei criteri di routing privato con ExpressRoute crittografato instrada i pacchetti ESP VPN tramite l'appliance di sicurezza hop successivo distribuita nell'hub. Di conseguenza, è possibile prevedere una velocità effettiva massima del tunnel VPN di ExpressRoute crittografato parti a 1 Gbps in entrambe le direzioni (in ingresso dall'ambiente locale e in uscita da Azure). Per ottenere la velocità effettiva massima del tunnel VPN, considerare le ottimizzazioni della distribuzione seguenti:

• Distribuire Firewall di Azure Premium anziché Firewall di Azure Standard o Firewall di Azure Basic.
• Assicurarsi che Firewall di Azure elabori la regola che consente il traffico tra gli endpoint del tunnel VPN (192.168.1.4 e 192.168.1.5 nell'esempio precedente) per prima rendendola la regola con la priorità più alta nei criteri di Firewall di Azure. Per altre informazioni sulla logica di elaborazione delle regole di Firewall di Azure, vedere Logica di elaborazione delle regole di Firewall di Azure.
• Disattivare il deep-packet per il traffico tra gli endpoint del tunnel VPN. Per informazioni su come configurare Firewall di Azure per escludere il traffico dall'ispezione approfondita dei pacchetti, vedere la documentazione relativa all'elenco di bypass IDPS.
• Configurare i dispositivi VPN per l'uso di GCMAES256 sia per l'integrità che per la crittografia IPSEC al fine di ottimizzare le prestazioni.

Routing diretto alle istanze dell'appliance virtuale di rete per connettività a doppio ruolo e appliance virtuali di rete del firewall

Alcune appliance virtuali di rete possono avere funzionalità di connettività (SD-WAN) e sicurezza (NGFW) nello stesso dispositivo. Queste appliance virtuali di rete sono considerate appliance virtuali di rete a doppio ruolo. Verificare se l'appliance virtuale di rete è un'appliance virtuale di rete con doppio ruolo nei partner dell'appliance virtuale di rete.

Quando i criteri di routing privato sono configurati per appliance virtuali di rete a doppio ruolo, rete WAN virtuale annuncia automaticamente le route apprese dal dispositivo dell'appliance virtuale di rete dell'hub rete WAN virtuale a Rete virtuale connesse direttamente (locali) e ad altri hub virtuali nel rete WAN virtuale con l'hop successivo come istanza dell'appliance virtuale di rete anziché il servizio di bilanciamento del carico interno delle appliance virtuali di rete.

Per le configurazioni dell'appliance virtuale di rete attivo-passivo in cui una sola istanza delle appliance virtuali di rete annuncia una route per un prefisso specifico da rete WAN virtuale (o la lunghezza AS-PATH delle route apprese da una delle istanze è sempre la più breve), rete WAN virtuale garantisce che il traffico in uscita da un'istanza di Azure Rete virtuale viene sempre instradato all'istanza di appliance virtuale di rete attiva (o preferita).

Per le configurazioni dell'appliance virtuale di rete attive(più istanze dell'appliance virtuale di rete annunciano lo stesso prefisso con la stessa lunghezza AS-PATH), Azure esegue automaticamente ECMP per instradare il traffico da Azure a locale. La piattaforma di rete software-defined di Azure non garantisce la simmetria a livello di flusso, ovvero il flusso in ingresso ad Azure e il flusso in uscita da Azure può raggiungere istanze diverse dell'appliance virtuale di rete. Ciò comporta un routing asimmetrico che viene eliminato dall'ispezione del firewall con stato. Pertanto, non è consigliabile usare modelli di connettività attivi-attivi in cui un'appliance virtuale di rete si comporta come appliance virtuale di rete a doppio ruolo, a meno che l'appliance virtuale di rete non possa supportare l'inoltro asimmetrico o supportare la condivisione/sincronizzazione delle sessioni. Per altre informazioni su se l'appliance virtuale di rete supporta l'inoltro asimmetrico o la condivisione/sincronizzazione dello stato della sessione, contattare il provider dell'appliance virtuale di rete.

Configurazione della finalità di routing tramite il portale di Azure

I criteri di routing e la finalità di routing possono essere configurati tramite il portale di Azure usando Gestione firewall di Azure o il portale della rete WAN virtuale. Il portale di Gestione firewall di Azure consente di configurare i criteri di routing con risorsa hop successivo di tipo Firewall di Azure. Il portale della rete WAN virtuale consente di configurare i criteri di routing con risorsa hop successivo Firewall di Azure, appliance virtuali di rete distribuite all'interno dell'hub virtuale o soluzioni SaaS.

I clienti che usano Firewall di Azure nell'hub protetto della rete WAN virtuale possono abilitare l'impostazione "Tra hub" di Gestione firewall di Azure per usare la finalità di routing o usare il portale della rete WAN virtuale per configurare direttamente Firewall di Azure come risorsa hop successivo per i criteri e la finalità di routing. Le configurazioni in entrambi i portali sono equivalenti e le modifiche in Gestione firewall di Azure vengono riflesse automaticamente nel portale della rete WAN virtuale e viceversa.

Configurare la finalità e i criteri di routing tramite Gestione firewall di Azure

I passaggi seguenti descrivono come configurare la finalità di routing e i criteri di routing nell'hub virtuale usando Gestione firewall di Azure. Gestione firewall di Azure supporta solo le risorse hop successivo di tipo Firewall di Azure.

1. spostarsi nell'hub rete WAN virtuale in cui si desidera configurare i criteri di pianificazione percorso.

2. In Sicurezza selezionare Impostazioni hub virtuale protetto e quindi Gestire le impostazioni del provider di sicurezza e delle route per questo hub virtuale protetto in Gestione firewall di Azure.

3. Selezionare dal menu l'hub su cui si desidera configurare i criteri di routing.

4. In Impostazioni selezionare Configurazione sicurezza

5. Per configurare un criterio di routing del traffico Internet, selezionare Firewall di Azure o il provider di sicurezza Internet pertinente nell'elenco a discesa Traffico Internet. In caso contrario, selezionare Nessuno

6. Per configurare un criterio di routing del traffico privato (per il traffico dei rami e della rete virtuale) tramite Firewall di Azure, selezionare Firewall di Azure dall'elenco a discesa Traffico privato. In caso contrario, selezionare Ignora Firewall di Azure.

   

7. Per configurare un criterio di routing del traffico privato e fare in modo che rami o reti virtuali annuncino prefissi non IANA RFC1918, selezionare Prefissi del traffico privato e specificare gli intervalli di prefissi non IANA RFC1918 nella casella di testo visualizzata. Selezionare Fatto.

   

8. Per Tra hub selezionare Abilitato. L'abilitazione di questa opzione garantisce che i criteri di routing vengano applicati alla finalità di routing di questo hub rete WAN virtuale.

9. Seleziona Salva.

10. Ripetere i passaggi da 2 a 8 per altri hub rete WAN virtuale protetti per cui si desidera configurare i criteri di routing.

11. A questo punto, si è pronti per inviare il traffico di test. Assicurarsi che i criteri del firewall siano configurati in modo appropriato per consentire/negare il traffico in base alle configurazioni di sicurezza desiderate.

Configurare la finalità e i criteri di routing tramite il portale della rete WAN virtuale

I passaggi seguenti descrivono come configurare la finalità di routing e i criteri di routing nell'hub virtuale usando il portale della rete WAN virtuale.

1. Dal collegamento al portale personalizzato fornito nel messaggio di posta elettronica di conferma del passaggio 3 della sezione Prerequisiti passare all'hub della rete WAN virtuale in cui si vogliono configurare i criteri di routing.

2. In Routing selezionare Criteri di routing.

   

3. Per configurare un criterio di routing del traffico privato (per il traffico dei rami e della rete virtuale), selezionare Firewall di Azure, Appliance virtuale di rete o Soluzioni SaaS in Traffico privato. In Risorsa hop successivo selezionare la risorsa hop successivo pertinente.

   

4. Per configurare un criterio di routing del traffico privato e fare in modo che rami o reti virtuali usino prefissi non IANA RFC1918, selezionare Altri prefissi e specificare gli intervalli di prefissi non IANA RFC1918 nella casella di testo visualizzata. Selezionare Fatto. Assicurarsi di aggiungere lo stesso prefisso alla casella di testo Prefisso traffico privato in tutti gli hub virtuali configurati con criteri di routing privato per assicurarsi che i percorsi corretti vengano annunciati a tutti gli hub.

   

5. Per configurare un criterio di routing del traffico Internet, selezionare Firewall di Azure, Appliance virtuale di rete o Soluzione SaaS. In Risorsa hop successivo selezionare la risorsa hop successivo pertinente.

   

6. Per applicare la configurazione dei criteri e della finalità di routing, fare clic su Salva.

   

7. Ripetere l'operazione per tutti gli hub per cui si desidera configurare i criteri di routing.

8. A questo punto, si è pronti per inviare il traffico di test. Verificare che i criteri del firewall siano configurati in modo appropriato per consentire/negare il traffico in base alle configurazioni di sicurezza desiderate.

Configurare la finalità di routing usando un modello BICEP

Per informazioni sul modello e sui passaggi, vedere il modello BICEP.

Risoluzione dei problemi

La sezione seguente descrive i modi comuni per risolvere i problemi relativi alla configurazione dei criteri e della finalità di routing nell'hub della rete WAN virtuale.

Route valide

Quando i criteri di routing privato sono configurati nell'hub virtuale, tutto il traffico tra l'ambiente locale e le reti virtuali viene controllato da Firewall di Azure, dall'appliance virtuale di rete o dalla soluzione SaaS nell'hub virtuale.

Di conseguenza, le route valide della tabella defaultRouteTable mostrano i prefissi aggregati RFC1918 (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) con hop successivo Firewall di Azure o Appliance virtuale di rete. Ciò riflette che tutto il traffico tra Rete virtuale e rami viene instradato a Firewall di Azure, appliance virtuale di rete o soluzione SaaS nell'hub per l'ispezione.

Dopo che il firewall ha esaminato il pacchetto (e il pacchetto è consentito in base alla configurazione della regola del firewall), la rete WAN virtuale inoltra il pacchetto alla destinazione finale. Per vedere le route usate dalla rete WAN virtuale per inoltrare pacchetti ispezionati, esaminare la tabella delle route valide del firewall o dell'appliance virtuale di rete.

La tabella delle route valide del firewall consente di limitare e isolare i problemi nella rete, ad esempio configurazioni errate o problemi relativi a particolari rami e reti virtuali.

Risoluzione dei problemi di configurazione

Se si stanno risolvendo problemi di configurazione, tenere presente quanto segue:

• Assicurarsi di non avere tabelle di route personalizzate o route statiche nella tabella defaultRouteTable con hop successivo di tipo Connessione di rete virtuale.
  • L'opzione per configurare la finalità di routing è disattivata nel portale di Azure se la distribuzione non soddisfa i requisiti indicati in precedenza.
  • Se si usa l'interfaccia della riga di comando, PowerShell o REST, l'operazione di creazione della finalità di routing ha esito negativo. Eliminare la finalità di routing non riuscita, rimuovere le tabelle di route personalizzate e le route statiche e quindi ritentare la creazione.
  • Se si usa Gestione firewall di Azure, assicurarsi che le route esistenti nella tabella defaultRouteTable siano denominate private_traffic, internet_traffic o all_traffic. L'opzione per configurare la finalità di routing (abilitare l'opzione tra hub) è disattivata se le route sono denominate in modo diverso.
• Dopo aver configurato la finalità di routing in un hub, assicurarsi che gli eventuali aggiornamenti alle connessioni esistenti o le nuove connessioni all'hub vengano creati con i campi opzionali della tabella di route delle associazioni e delle propagazioni impostati come vuoti. L'impostazione delle associazioni e delle propagazioni facoltative come vuote viene eseguita automaticamente per tutte le operazioni eseguite tramite il portale di Azure.

Risoluzione dei problemi del percorso dati

Supponendo che la sezione Limitazioni note sia già stata esaminata, ecco alcuni modi per risolvere i problemi relativi al percorso dati e alla connettività:

• Risoluzione dei problemi relativi alle route valide:
  • Se sono configurati criteri di routing privato, dovrebbero essere presenti route con hop successivo Firewall nelle route valide della tabella defaultRouteTable per gli aggregati RFC1918 (10.0.0.0.0/8, 192.168.0.0.0/16, 172.16.0.0/12) oltre che tutti gli eventuali prefissi specificati nella casella di testo del traffico privato. Assicurarsi che tutti i prefissi locali e della rete virtuale siano subnet all'interno delle route statiche nella tabella defaultRouteTable. Se una rete locale o virtuale usa uno spazio indirizzi che non è una subnet all'interno delle route valide in defaultRouteTable, aggiungere il prefisso nella casella di testo del traffico privato.
  • Se sono configurati criteri di routing del traffico Internet, nelle route valide di defaultRouteTable dovrebbe essere presente una route predefinita (0.0.0.0/0).
  • Dopo aver verificato che le route valide di defaultRouteTable abbiano i prefissi corretti, esaminare le route valide dell'appliance virtuale di rete o di Firewall di Azure. Le route valide nel firewall mostrano le route selezionate dalla rete WAN virtuale e determinano le destinazioni a cui il firewall può inoltrare i pacchetti. Capire quali prefissi sono mancanti o in uno stato non corretto consente di restringere i problemi relativi al percorso dei dati e puntare alla connessione VPN, ExpressRoute, appliance virtuale di rete o BGP corretta in cui occorre risolvere i problemi.
• Risoluzione dei problemi specifici dello scenario:
  • Se si dispone di un hub non protetto (hub senza Firewall di Azure o NVA) nella rete WAN virtuale, assicurarsi che le connessioni all'hub non protetto vengano propagate alla defaultRouteTable degli hub con finalità di routing configurata. Se le propagazioni non sono impostate su defaultRouteTable, le connessioni all'hub protetto non saranno in grado di inviare pacchetti all'hub non protetto.
  • Se sono configurati criteri di routing Internet, assicurarsi che l'impostazione "Propaga route predefinita" o "Abilita la sicurezza Internet" sia impostata su "true" per tutte le connessioni che devono apprendere la route predefinita 0.0.0.0/0. Le connessioni in cui questa impostazione è "false" non apprenderanno la route 0.0.0.0/0, anche se sono configurati criteri di routing Internet.
  • Se si usano endpoint privati distribuiti in Rete virtuale connessi all'hub virtuale, il traffico proveniente dall'ambiente locale destinato agli endpoint privati distribuiti in Rete virtuale connessi all'hub rete WAN virtuale per impostazione predefinita ignora l'hop successivo Firewall di Azure, l'appliance virtuale di rete o l'hop successivo SaaS. Questo comporta tuttavia un routing asimmetrico (che può causare la perdita di connettività tra endpoint locali ed endpoint privati) poiché gli endpoint privati nelle reti virtuali spoke inoltrano il traffico locale al firewall. Per garantire la simmetria del routing, abilitare i criteri di rete della tabella di route per gli endpoint privati nelle subnet in cui vengono distribuiti endpoint privati. La configurazione di route /32 corrispondenti a indirizzi IP privati di endpoint privato nella casella di testo del traffico privato non garantisce la simmetria del traffico quando nell'hub sono configurati criteri di routing privato.
  • Se si usa ExpressRoute crittografato con criteri di routing privato, assicurarsi che il dispositivo firewall disponga di una regola configurata per consentire il traffico tra l'endpoint del tunnel IP privato del gateway VPN da sito a sito della rete WAN virtuale e il dispositivo VPN locale. I pacchetti ESP (crittografati esterni) devono essere inseriti nei log di Firewall di Azure. Per altre informazioni su ExpressRoute crittografato con finalità di routing, vedere la documentazione di ExpressRoute crittografato.

Risoluzione dei problemi di routing di Firewall di Azure

• Assicurarsi che lo stato di provisioning di Firewall di Azure sia riuscito prima di provare a configurare la finalità di routing.
• Se si usano prefissi non IANA RFC1918 nei rami o nelle reti virtuali, assicurarsi di aver specificato tali prefissi nella casella di testo dei prefissi privati. I prefissi privati configurati non vengono propagati automaticamente ad altri hub nella rete WAN virtuale configurata con la finalità di routing. Per garantire la connettività, aggiungere questi prefissi alla casella di testo "Prefissi privati" in ogni singolo hub con finalità di routing.
• Se sono stati specificati indirizzi non RFC1918 nella casella di testo dei prefissi del traffico privato in Gestione firewall, può essere necessario configurare i criteri SNAT nel firewall per disabilitare SNAT per il traffico privato non RFC1918. Per altre informazioni, vedere Intervalli SNAT di Firewall di Azure.
• Configurare e visualizzare i log di Firewall di Azure per risolvere i problemi e analizzare il traffico di rete. Per altre informazioni su come configurare il monitoraggio per Firewall di Azure, vedere Diagnostica di Firewall di Azure. Per una panoramica dei diversi tipi di log del firewall, vedere Log e metriche di Firewall di Azure.
• Per altre informazioni su Firewall di Azure, vedere la documentazione di Firewall di Azure.

Risoluzione dei problemi delle appliance virtuali di rete

• Assicurarsi che lo stato di provisioning dell'appliance virtuale di rete sia riuscito prima di provare a configurare la finalità di routing.
• Se si usano prefissi non IANA RFC1918 nelle reti locali o virtuali connesse, assicurarsi di aver specificato tali prefissi nella casella di testo dei prefissi privati. I prefissi privati configurati non vengono propagati automaticamente ad altri hub nella rete WAN virtuale configurata con la finalità di routing. Per garantire la connettività, aggiungere questi prefissi alla casella di testo "Prefissi privati" in ogni singolo hub con finalità di routing.
• Se sono stati specificati indirizzi non RFC1918 nella casella di testo dei prefissi del traffico privato, può essere necessario configurare i criteri SNAT nell'appliance di rete virtuale per disabilitare SNAT per determinato traffico privato non RFC1918.
• Controllare i log del firewall dell'appliance virtuale di rete per verificare se il traffico viene eliminato o negato dalle regole del firewall.
• Contattare il provider dell'appliance virtuale di rete per altre informazioni e indicazioni sulla risoluzione dei problemi.

Risoluzione dei problemi relativi alla soluzione SaaS

• Assicurarsi che lo stato di provisioning della soluzione SaaS sia riuscito prima di provare a configurare la finalità di routing.
• Per altri suggerimenti per la risoluzione dei problemi, vedere la sezione relativa alla risoluzione dei problemi nella documentazione della rete WAN virtuale o vedere la documentazione di Palo Alto Networks Cloud NGFW.

Passaggi successivi

Per altre informazioni sul routing dell'hub virtuale, vedere Informazioni sul routing dell'hub virtuale. Per altre informazioni sulla rete WAN virtuale, vedere le domande frequenti.