Condividi tramite

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

  • Articolo

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 inoltrare il traffico a internet e privato (VPN da punto a sito, VPN da sito a sito, ExpressRoute, Rete virtuale e appliance virtuale di rete) a un Firewall di Azure, appliance virtuale di rete firewall di nuova generazione (NGFW-NVA) o soluzione SaaS (Security Software-as-a-Service) distribuita nell'hub virtuale.

Esistono due tipi di criteri di routing: traffico Internet e criteri di routing del traffico privato. Ogni hub 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 singola risorsa hop successivo. Mentre il traffico privato include sia i prefissi di indirizzi di ramo che Rete virtuale, i criteri di routing li considerano come un'entità all'interno dei concetti relativi alla 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, il rete WAN virtuale annuncia una route predefinita (0.0.0.0/0) a tutti gli spoke, i gateway e le appliance virtuali di rete (distribuiti 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, Risorsa della soluzione Appliance virtuale di rete o SaaS.

    In altre parole, quando viene configurato un criterio di routing del traffico privato nell'hub rete WAN virtuale, tutte le reti da ramo a ramo, da ramo a rete virtuale, da rete virtuale a ramo e traffico tra hub vengono inviate 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 agli hub 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 Firewall di Azure, appliance virtuale di rete o SaaS. In questo scenario è possibile configurare criteri di routing del traffico Internet, criteri di routing del traffico privato o entrambi in ogni hub rete WAN virtuale.

Screenshot che mostra l'architettura con due hub protetti.

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 dell'hub hop successivo, appliance virtuale di rete o soluzione SaaS
  • Criteri di traffico Internet con Firewall di Azure dell'hub hop successivo, appliance virtuale di rete o soluzione SaaS

Configurazione dell'hub 2:

  • Criteri di traffico privato con soluzione di Firewall di Azure, appliance virtuale di rete o SaaS dell'hub hop successivo 2
  • Criteri di traffico Internet con la soluzione Next Hop Hub 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.

Nota

Il traffico Internet deve passare attraverso la soluzione di sicurezza locale 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 → Hub 1 AzFW o appliance virtuale di rete Hub 1 AzFW o appliance virtuale di rete 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 rete WAN virtuale protetti e regolari

In questo scenario, non tutti gli hub nella rete WAN sono protetti rete WAN virtuale Hub (hub con una soluzione di sicurezza distribuita in essi).

Si consideri la configurazione seguente in cui l'hub 1 (normale) e l'hub 2 (protetto) vengono distribuiti in un rete WAN virtuale. Hub 2 dispone di criteri di routing per il traffico privato e 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 Next Hop Hub 2 Firewall di Azure, appliance virtuale di rete o SaaS.
  • Criteri di traffico Internet con la soluzione Next Hop Hub 2 Firewall di Azure, NVA o SaaS.

Screenshot che mostra l'architettura con un hub protetto un hub normale.

Di seguito sono riportati i flussi di traffico risultanti da una configurazione di questo tipo. I rami e i Rete virtuale connessi 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 finalità di routing è attualmente disponibile in Azure pubblico. Microsoft Azure gestito da 21Vianet e Azure per enti pubblici sono attualmente in programma di orientamento.
  • 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). rete WAN virtuale con tabelle di route personalizzate e criteri personalizzati non possono quindi essere usati con i costrutti 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 gli endpoint del tunnel VPN (ip privato da sito a sito Gateway VPN IP privato e ip privato del dispositivo VPN locale). Per altre informazioni sulle configurazioni necessarie, vedere Encrypted ExpressRoute con finalità di routing.
  • I casi d'uso di connettività seguenti non sono supportati con la finalità di routing:
    • Le route statiche nella tabella predefinitaRouteTable che puntano a una connessione Rete virtuale non possono essere usate insieme alla finalità di routing. Tuttavia, è possibile usare la funzionalità di peering BGP.
    • La possibilità di distribuire un'appliance virtuale di rete per la connettività SD-WAN e una soluzione SaaS o un'appliance virtuale di rete del firewall separata nello stesso hub rete WAN virtuale è attualmente nella roadmap. Dopo aver configurato la finalità di routing con la soluzione SaaS hop successivo o l'appliance virtuale di rete del firewall, la connettività tra l'appliance virtuale di rete SD-WAN e Azure è interessata. Distribuire invece l'appliance virtuale di rete SD-WAN e la soluzione NVA del firewall o SaaS in hub virtuali diversi. In alternativa, è anche possibile distribuire l'appliance virtuale di rete SD-WAN in un Rete virtuale spoke connesso all'hub e sfruttare la funzionalità di peering BGP dell'hub virtuale.
    • Le appliance virtuali di rete (APPLIANCE virtuali di rete) possono essere specificate solo come risorsa hop successivo per la finalità di routing se sono firewall di nuova generazione o firewall di nuova generazione e appliance virtuali di rete 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 appliance virtuale di rete passando all'hub virtuale -> Appliance virtuali di rete e quindi esaminando il campo Fornitore . Palo Alto Networks Cloud NGFW è supportato anche come hop successivo per finalità di routing, ma viene considerato un hop successivo di tipo Soluzione SaaS.
    • Gli utenti della finalità di routing che vogliono connettere più circuiti ExpressRoute a rete WAN virtuale e vogliono inviare traffico tra di essi tramite una soluzione di sicurezza distribuita nell'hub possono abilitare l'apertura di un caso di supporto per abilitare questo caso d'uso. Per altre informazioni, fare riferimento all'abilitazione della connettività tra circuiti ExpressRoute.

Considerazioni

I clienti che usano attualmente Firewall di Azure nell'hub rete WAN virtuale senza finalità di routing possono abilitare la finalità di routing usando Firewall di Azure Manager, rete WAN virtuale portale di routing dell'hub 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 in cui non sono presenti tabelle di route personalizzate e nessuna route statica nella tabella predefinitaRouteTable con hop successivo Rete virtuale Connessione ion. 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à e applicherà automaticamente le configurazioni precedenti. Per altre informazioni, vedere Strategia di rollback.
  • La finalità di routing modifica le route statiche in defaultRouteTable. A causa di portale di Azure ottimizzazioni, 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 prefisso.
  • È 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 in rete WAN virtuale per 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 simmetricamente tra le appliance di sicurezza distribuite negli hub rete WAN virtuale.

Prerequisiti

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

  • Nessuna tabella di route personalizzata distribuita con l'hub virtuale. Le uniche tabelle di route esistenti sono noneRouteTable e defaultRouteTable.
  • Non è possibile avere route statiche con Rete virtuale Connessione hop successivo. È possibile che nella tabella predefinita siano presenti route statiche con hop successivo Firewall di Azure.

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

L'uso della finalità di routing (opzione abilita l'hub) in Firewall di Azure Manager ha un requisito aggiuntivo:

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

Strategia di rollback

Nota

Quando la configurazione della finalità di routing viene rimossa completamente da un hub, tutte le connessioni all'hub vengono impostate per la propagazione all'etichetta predefinita ( che si applica a 'all' defaultRouteTables nella rete WAN virtuale). Di conseguenza, se si sta valutando l'implementazione della finalità di routing in rete WAN virtuale, è necessario salvare una copia delle configurazioni esistenti (gateway, connessioni, tabelle di route) da applicare se si desidera ripristinare la configurazione originale. Il sistema non ripristina automaticamente la configurazione precedente.

La finalità di routing semplifica il routing e la configurazione gestendo le associazioni di route e le propagazioni di tutte le connessioni in 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 nel 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 predefinitaRouteTable quando la finalità di routing è 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.

Firewall di Azure Manager e rete WAN virtuale Hub Portal

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

Nota

Qualsiasi route statica nella tabella predefinitaRouteTable contenente prefissi che non corrispondono esattamente a 0.0.0.0/0 o alla RFC1918 super nets (10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12) vengono consolidati automaticamente in una singola route statica denominata private_traffic. I prefissi nella tabella defaultRouteTable corrispondente RFC1918 supernet o 0.0.0.0/0 vengono sempre rimossi automaticamente dopo la configurazione della finalità di routing, indipendentemente dal tipo di criterio.

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 comporta lo 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 portale crea automaticamente le route dei criteri corrispondenti in defaultRouteTable e rimuove anche tutti i prefissi nelle route statiche che corrispondono esattamente a 0.0.0.0/0 o RFC1918 supernet (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 che la creazione della finalità di routing ha esito positivo. Si noti che firewall_route_1 e to_internet sono stati rimossi automaticamente come unico prefisso in tali route 10.0.0.0/8 e 0.0.0.0.0/0. firewall_route_2 è stato modificato per rimuovere 192.168.0.0/16 perché tale prefisso è un prefisso di aggregazione 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 come rete WAN virtuale annuncia le route in locale dopo la configurazione della finalità di routing in un hub virtuale.

Criteri di routing Internet

Nota

La route predefinita 0.0.0.0/0 non viene pubblicizzata tra hub virtuali.

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 (Rete virtuale ExpressRoute, VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete nell'hub e connessioni BGP) in cui la route predefinita Propagate o Enable Internet security flag è impostata su true. È possibile impostare questo flag su false per tutte le connessioni che non devono apprendere la route predefinita.

Criteri di routing privato

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

  • Route corrispondenti ai prefissi appresi dalle Rete virtuale dell'hub locale, ExpressRoute, VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete nell'hub locale o connessioni BGP connesse all'hub corrente.
  • Route corrispondenti ai prefissi appresi dai Rete virtuale dell'hub remoto, ExpressRoute, VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete nell'hub remoto o connessioni BGP in cui sono configurati i criteri di routing privato.
  • Route corrispondenti ai prefissi appresi dai Rete virtuale dell'hub remoto, ExpressRoute, VPN da sito a sito, VPN da punto a sito, appliance virtuale di rete nell'hub remoto e connessioni BGP in cui la finalità di routing non è configurata e le connessioni remote si propagano alla tabella predefinitaRouteTable dell'hub locale.
  • I prefissi appresi da un circuito ExpressRoute non vengono annunciati ad altri circuiti ExpressRoute a meno che non sia abilitato 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.

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

La connettività di transito tra circuiti ExpressRoute all'interno di 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.

Nota

Per abilitare la connettività di transito da ExpressRoute a ExpressRoute tramite un'appliance Firewall nell'hub con criteri di routing privato, aprire un caso di supporto con supporto tecnico Microsoft. Questa opzione non è compatibile con Copertura globale e richiede la disabilitazione di Copertura globale per garantire un routing di transito appropriato tra tutti i circuiti ExpressRoute connessi a rete WAN virtuale.

  • Copertura globale di ExpressRoute: Copertura globale di ExpressRoute consente a due circuiti abilitati per Copertura globale di inviare il traffico tra loro direttamente senza transitare l'hub virtuale.
  • Criteri di routing privato della finalità di routing: la configurazione dei criteri di routing privato consente a due circuiti ExpressRoute di inviare il traffico l'uno all'altro tramite una soluzione di sicurezza distribuita nell'hub.

Connessione ivity tra circuiti ExpressRoute tramite un'appliance Firewall nell'hub con i criteri di routing privati delle finalità di routing sono disponibili nelle configurazioni seguenti:

  • Entrambi i circuiti ExpressRoute sono connessi allo stesso hub e viene configurato un criterio di routing privato in tale hub.
  • I circuiti ExpressRoute sono connessi a hub diversi e i criteri di routing privato sono configurati in entrambi gli hub. Pertanto, entrambi gli hub devono avere una soluzione di sicurezza distribuita.

Considerazioni sul routing con ExpressRoute

Nota

Le considerazioni sul routing seguenti si applicano a tutti gli hub virtuali nelle sottoscrizioni abilitate da supporto tecnico Microsoft per consentire la connettività ExpressRoute a ExpressRoute tramite un'appliance di sicurezza nell'hub.

Dopo aver abilitato la connettività di transito tra circuiti ExpressRoute usando un'appliance firewall distribuita nell'hub virtuale, è possibile prevedere le modifiche seguenti nel comportamento del modo in cui le route vengono annunciate a ExpressRoute in locale:

  • rete WAN virtuale annuncia automaticamente RFC1918 prefissi aggregati (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) all'istanza locale connessa a ExpressRoute. Queste route di aggregazione vengono annunciate oltre alle route descritte nella sezione precedente.
  • rete WAN virtuale annuncia automaticamente tutte le route statiche nell'istanza predefinitaRouteTable a un circuito ExpressRoute connesso in locale. Ciò significa che rete WAN virtuale annuncia le route specificate nella casella di testo prefisso del traffico privato in locale.

A causa di queste modifiche agli annunci di route, ciò significa che ExpressRoute locale 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 pubblicizzare subnet più specifiche (all'interno di intervalli di RFC1918) anziché aggregare super net e 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 Prefissi 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 Prefisso traffico privato (ad esempio: 40.0.0.0/23).

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

ExpressRoute crittografato

Per usare Encrypted ExpressRoute (tunnel VPN da sito a sito in esecuzione su un circuito ExpressRoute) con criteri di routing privati con finalità di routing, configurare una regola del firewall per consentire il traffico tra gli indirizzi IP privati del tunnel dell'rete WAN virtuale Gateway VPN da sito a sito (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 INDIRIZZI IP privati dall'ispezione approfondita dei pacchetti.

È possibile ottenere gli indirizzi IP privati del tunnel del Gateway VPN da sito a sito rete WAN virtuale scaricando la configurazione VPN e visualizzando vpnSite Connessione ions -> gatewayConfiguration -> IPAddresses. Gli indirizzi IP elencati nel campo IPAddresses sono gli indirizzi 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 indirizzi IP specificati come parte della connessione al collegamento al sito VPN.

Screenshot che mostra l'indirizzo IP del tunnel del dispositivo locale del sito VPN.

Usando la configurazione VPN di esempio e il sito VPN precedente, creare regole del firewall per consentire il traffico seguente. Gli indirizzi IP di Gateway VPN devono essere l'INDIRIZZO IP di origine e il dispositivo VPN locale deve essere l'INDIRIZZO IP di destinazione nelle regole configurate.

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

La configurazione dei criteri di routing privato con Encrypted ExpressRoute instrada i pacchetti ESP VPN tramite l'appliance di sicurezza hop successivo distribuita nell'hub. Di conseguenza, è possibile prevedere la velocità effettiva massima del tunnel VPN crittografata expressRoute di 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, prendere in considerazione le ottimizzazioni di distribuzione seguenti:

  • Distribuire Firewall di Azure Premium anziché Firewall di Azure Standard o Firewall di Azure Basic.
  • Assicurarsi Firewall di Azure elabora la regola che consente il traffico tra gli endpoint del tunnel VPN (192.168.1.4 e 192.168.1.5 nell'esempio precedente) rendendo la regola la priorità più alta nei criteri di Firewall di Azure. Per altre informazioni sulla logica di elaborazione delle regole di Firewall di Azure, vedere Firewall di Azure logica di elaborazione delle regole.
  • 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 per la crittografia IP edizione Standard C e l'integrità per ottimizzare le prestazioni.

Configurazione della finalità di routing tramite portale di Azure

I criteri di routing e finalità di routing possono essere configurati tramite portale di Azure usando Firewall di Azure Manager o rete WAN virtuale portale. Firewall di Azure Portale di Manager consente di configurare i criteri di routing con Firewall di Azure di risorse hop successivo. rete WAN virtuale portale consente di configurare i criteri di routing con la 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 rete WAN virtuale possono impostare l'impostazione "Abilita inter hub" di Firewall di Azure Manager su "Abilitato" per usare la finalità di routing o usare rete WAN virtuale portale per configurare direttamente Firewall di Azure come risorsa hop successivo per finalità e criteri di routing. Le configurazioni in entrambe le esperienze del portale sono equivalenti e le modifiche in Firewall di Azure Manager vengono riflesse automaticamente nel portale di rete WAN virtuale e viceversa.

Configurare la finalità e i criteri di routing tramite Firewall di Azure Manager

I passaggi seguenti descrivono come configurare la finalità di routing e i criteri di routing nell'hub virtuale usando Firewall di Azure Manager. Firewall di Azure Manager 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 Gestisci provider di sicurezza e impostazioni di route per questo hub virtuale protetto in Firewall di Azure Manager. Screenshot che mostra come modificare le impostazioni dell'hub protetto.

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

  4. Selezionare Configurazione di sicurezza in Impostazioni

  5. Per configurare criteri 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 criteri di routing del traffico privato (per il ramo e il traffico Rete virtuale) tramite Firewall di Azure, selezionare Firewall di Azure nell'elenco a discesa Traffico privato. In caso contrario, selezionare Ignora Firewall di Azure.

    Screenshot che mostra come configurare i criteri di routing.

  7. Per configurare criteri di routing del traffico privato e avere rami o reti virtuali che annunciano prefissi non IANA RFC1918, selezionare Prefissi traffico privato e specificare gli intervalli di prefissi non IANA RFC1918 nella casella di testo visualizzata. Selezionare Fatto.

    Screenshot che mostra come modificare i prefissi del traffico privato.

  8. Selezionare Inter-hub da abilitare. 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 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 rete WAN virtuale portale

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

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

  2. In Routing selezionare Criteri di routing.

    Screenshot che mostra come passare ai criteri di routing.

  3. Per configurare criteri di routing del traffico privato (per ramo e traffico 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.

    Screenshot che mostra come configurare i criteri di routing privato dell'appliance virtuale di rete.

  4. Per configurare criteri di routing del traffico privato e avere rami o reti virtuali usando prefissi non IANA RFC1918, selezionare Prefissi aggiuntivi 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.

    Screenshot che mostra come configurare prefissi privati aggiuntivi per i criteri di routing dell'appliance virtuale di rete.

  5. Per configurare criteri 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.

    Screenshot che mostra come configurare i criteri di routing pubblico per l'appliance virtuale di rete.

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

    Screenshot che mostra come salvare le configurazioni dei criteri di routing.

  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. Assicurarsi che i criteri 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 della finalità di routing e dei criteri nell'hub rete WAN virtuale.

Route valide

Quando i criteri di routing privato sono configurati nell'hub virtuale, tutto il traffico tra l'ambiente locale e i Rete virtuale vengono controllati da Firewall di Azure, appliance virtuale di rete o soluzione SaaS nell'hub virtuale.

Di conseguenza, le route valide di 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.

Screenshot che mostra le route valide per defaultRouteTable.

Dopo che il firewall esamina il pacchetto (e il pacchetto è consentito per ogni configurazione della regola del firewall), rete WAN virtuale inoltra il pacchetto alla destinazione finale. Per visualizzare le route usate rete WAN virtuale per inoltrare i pacchetti controllati, visualizzare la tabella di route effettiva del firewall o dell'appliance virtuale di rete.

Screenshot che mostra le route valide per Firewall di Azure.

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

Risoluzione dei problemi di configurazione

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

  • Assicurarsi di non avere tabelle di route personalizzate o route statiche nella tabella predefinitaRouteTable con hop successivo Rete virtuale connessione.
    • L'opzione per configurare la finalità di routing è disattivata in portale di Azure se la distribuzione non soddisfa i requisiti precedenti.
    • 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 provare a creare di nuovo.
    • Se si usa Firewall di Azure Manager, assicurarsi che le route esistenti nell'oggetto defaultRouteTable siano denominate private_traffic, internet_traffic o all_traffic. L'opzione per configurare la finalità di routing (abilitare l'hub) è disattivata se le route sono denominate in modo diverso.
  • Dopo aver configurato la finalità di routing in un hub, assicurarsi che tutti gli aggiornamenti alle connessioni esistenti o alle nuove connessioni all'hub vengano creati con i campi della tabella di route associati e propagati facoltativi impostati su vuoti. L'impostazione delle associazioni e delle propagazioni facoltative come vuota viene eseguita automaticamente per tutte le operazioni eseguite tramite portale di Azure.

Risoluzione dei problemi relativi al percorso dei dati

Supponendo di aver già esaminato la sezione Limitazioni note, 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, nelle route effettive della tabella predefinitaRouteTable per RFC1918 le aggregazioni predefinite (10.0.0.0.0/8, 192.168.0.0.0/16, 172.16.0.0/12) verranno visualizzati route con tutti i prefissi specificati nella casella di testo del traffico privato. Assicurarsi che tutti i prefissi Rete virtuale e locali siano subnet all'interno delle route statiche nella tabella predefinitaRouteTable. Se un'istanza locale o Rete virtuale usa uno spazio indirizzi che non è una subnet all'interno delle route valide nella tabella predefinitaRouteTable, aggiungere il prefisso nella casella di testo traffico privato.
    • Se sono configurati criteri di routing del traffico Internet, verrà visualizzata una route predefinita (0.0.0.0/0) nelle route valide di defaultRouteTable.
    • Dopo aver verificato che le route valide di defaultRouteTable abbiano i prefissi corretti, visualizzare le route valide dell'appliance virtuale di rete o Firewall di Azure. Le route valide nel firewall mostrano le route rete WAN virtuale selezionate e determinano le destinazioni a cui firewall può inoltrare i pacchetti. Capire quali prefissi sono mancanti o in uno stato non corretto consente di limitare i problemi relativi al percorso dei dati e puntare alla connessione VPN, ExpressRoute, appliance virtuale di rete o BGP corretta per la risoluzione dei problemi.
  • Risoluzione dei problemi specifici dello scenario:
    • Se nell'rete WAN virtuale è presente un hub non protetto (hub senza Firewall di Azure o appliance virtuale di rete), assicurarsi che le connessioni all'hub non sicuro vengano propagate all'hub predefinitoRouteTable degli hub con finalità di routing configurate. 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 sicurezza Internet" sia impostata su "true" per tutte le connessioni che devono apprendere la route predefinita 0.0.0.0/0. Connessione ions in cui questa impostazione è impostata su 'false' non apprenderà la route 0.0.0.0/0, anche se sono configurati i 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 SaaS. Questo comporta tuttavia un routing asimmetrico (che può causare la perdita di connettività tra endpoint locali ed endpoint privati) come endpoint privati in spoke Rete virtuale inoltra il traffico locale al firewall. Per garantire la simmetria del routing, abilitare i criteri di rete tabella di route per gli endpoint privati nelle subnet in cui vengono distribuiti gli endpoint privati. La configurazione di route /32 corrispondenti agli indirizzi IP privati dell'endpoint privato nella casella di testo Traffico privato non garantisce la simmetria del traffico quando i criteri di routing privato sono configurati nell'hub.
    • Se si usa Encrypted ExpressRoute con criteri di routing privato, assicurarsi che il dispositivo Firewall disponga di una regola configurata per consentire il traffico tra il rete WAN virtuale da sito a sito Gateway VPN endpoint del tunnel IP privato e il dispositivo VPN locale. I pacchetti ESP (crittografati esterni) devono accedere Firewall di Azure log. Per altre informazioni su Encrypted ExpressRoute con finalità di routing, vedere La documentazione di Encrypted ExpressRoute.

Risoluzione dei problemi di routing Firewall di Azure

  • Assicurarsi che lo stato di provisioning del Firewall di Azure sia riuscito prima di provare a configurare la finalità di routing.
  • Se si usano prefissi non IANA RFC1918 nei rami/Rete virtuale, assicurarsi di aver specificato tali prefissi nella casella di testo "Prefissi privati". I "prefissi privati" configurati non vengono propagati automaticamente ad altri hub nel rete WAN virtuale configurato 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 come parte della casella di testo Prefissi traffico privato in Gestione firewall, potrebbe essere necessario configurare i criteri SNAT nel firewall per disabilitare SNAT per il traffico privato non RFC1918. Per altre informazioni, fare riferimento Firewall di Azure intervalli SNAT.
  • Configurare e visualizzare i log 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, fare riferimento Firewall di Azure diagnostica. Per una panoramica dei diversi tipi di log del firewall, vedere Firewall di Azure log e metriche.
  • Per altre informazioni sulle Firewall di Azure, vedere Firewall di Azure Documentazione.

Risoluzione dei problemi delle appliance virtuali di rete

  • Assicurarsi che lo stato di provisioning dell'appliance virtuale di rete sia stato completato prima di provare a configurare la finalità di routing.
  • Se si usano prefissi non IANA RFC1918 nei Rete virtuale o locali connessi, assicurarsi di aver specificato tali prefissi nella casella di testo "Prefissi privati". I "prefissi privati" configurati non vengono propagati automaticamente ad altri hub nel rete WAN virtuale configurato 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 come parte della casella di testo Prefissi traffico privato, potrebbe essere necessario configurare i criteri SNAT nell'appliance virtuale di rete per disabilitare SNAT per determinati 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 di appliance virtuali di rete per altre informazioni e indicazioni sulla risoluzione dei problemi.

Risoluzione dei problemi relativi al software come servizio

  • Assicurarsi che lo stato di provisioning della soluzione SaaS abbia esito positivo 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 in rete WAN virtuale documentazione 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.