Condividi tramite

Scenario: instradare il traffico tramite appliance virtuali di rete usando impostazioni personalizzate

  • Articolo

Quando si usa il routing dell'hub virtuale di Azure rete WAN virtuale, sono disponibili molte opzioni. L'obiettivo di questo articolo è quello di instradare il traffico attraverso un'appliance virtuale di rete per la comunicazione tra reti virtuali e rami e usare un'appliance virtuale di rete diversa per il traffico associato a Internet. Per altre informazioni, vedere Informazioni sul routing dell'hub virtuale.

Nota

Si noti che per gli scenari di routing seguenti, l'hub rete WAN virtuale e il Rete virtuale spoke contenenti l'appliance virtuale di rete devono trovarsi nella stessa area di Azure.

Progettazione

  • Spoke per reti virtuali connesse all'hub virtuale. Ad esempio, rete virtuale 1, rete virtuale 2 e rete virtuale 3 nel diagramma più avanti in questo articolo.
  • Rete virtuale del servizio per le reti virtuali in cui gli utenti hanno distribuito un'appliance virtuale di rete per controllare il traffico non Internet ed eventualmente con i servizi comuni a cui accedono gli spoke. Ad esempio, la rete virtuale 4 nel diagramma più avanti in questo articolo.
  • Rete virtuale perimetrale per le reti virtuali in cui gli utenti hanno distribuito un'appliance virtuale di rete da usare per controllare il traffico associato a Internet. Ad esempio, la rete virtuale 5 nel diagramma più avanti in questo articolo.
  • Hub per hub rete WAN virtuale gestiti da Microsoft.

La tabella seguente riepiloga le connessioni supportate in questo scenario:

Da Per Spoke Rete virtuale del servizio Rami Internet
Raggi -> Direttamente Direttamente tramite la rete virtuale del servizio tramite rete virtuale perimetrale
Rete virtuale del servizio -> Direttamente n/d Direttamente
Rami -> tramite la rete virtuale del servizio Direttamente Direttamente

Ognuna delle celle nella matrice di connettività descrive se la connettività passa direttamente su rete WAN virtuale o su una delle reti virtuali con un'appliance virtuale di rete.

Osservare i seguenti dettagli:

  • Raggi:
    • Gli spoke raggiungeranno altri spoke direttamente tramite hub rete WAN virtuale.
    • Gli spoke otterranno la connettività ai rami tramite una route statica che punta alla rete virtuale del servizio. Non imparano prefissi specifici dai rami, perché questi prefissi sono più specifici ed eseguono l'override del riepilogo.
    • Gli spoke invieranno traffico Internet alla rete virtuale perimetrale tramite un peering di reti virtuali dirette.
  • I rami passeranno agli spoke tramite un routing statico che punta alla rete virtuale del servizio. Non imparano prefissi specifici dalle reti virtuali che eseguono l'override della route statica riepilogata.
  • La rete virtuale del servizio sarà simile a una rete virtuale di Servizi condivisi che deve essere raggiungibile da ogni rete virtuale e da ogni ramo.
  • La rete virtuale perimetrale non deve avere connettività tramite rete WAN virtuale, perché l'unico traffico supportato avviene tramite peering di rete virtuale diretta. Per semplificare la configurazione, tuttavia, usare lo stesso modello di connettività di per la rete virtuale perimetrale.

Esistono tre modelli di connettività distinti, che si traducono in tre tabelle di route. Le associazioni alle diverse reti virtuali sono:

  • Raggi:
    • Tabella di route associata: RT_V2B
    • Propagazione alle tabelle di route: RT_V2B e RT_SHARED
  • Reti virtuali di appliance virtuali di rete (rete virtuale del servizio e rete virtuale di rete perimetrale):
    • Tabella di route associata: RT_SHARED
    • Propagazione alle tabelle di route: RT_SHARED
  • Rami:
    • Tabella di route associata: impostazione predefinita
    • Propagazione alle tabelle di route: RT_SHARED e Impostazione predefinita

Nota

Assicurarsi che le reti virtuali spoke non vengano propagate all'etichetta predefinita. Ciò garantisce che il traffico dai rami alle reti virtuali spoke venga inoltrato alle appliance virtuali di rete.

Queste route statiche assicurano che il traffico da e verso la rete virtuale e il ramo attraversi l'appliance virtuale di rete nella rete virtuale del servizio (VNet 4):

Descrizione Tabella di route Route statica
Rami RT_V2B 10.2.0.0/16 -> vnet4conn
Spoke dell'appliance virtuale di rete Predefiniti 10.1.0.0/16 -> vnet4conn

È ora possibile usare rete WAN virtuale per selezionare la connessione corretta a cui inviare i pacchetti. È anche necessario usare rete WAN virtuale per selezionare l'azione corretta da eseguire durante la ricezione di tali pacchetti. Per questa operazione si usano le tabelle di route di connessione, come indicato di seguito:

Descrizione Connection Route statica
VNet2Branch vnet4conn 10.2.0.0/16 -> 10.4.0.5
Branch2VNet vnet4conn 10.1.0.0/16 -> 10.4.0.5

Per altre informazioni, vedere Informazioni sul routing dell'hub virtuale.

Architettura

Il diagramma seguente illustra l'architettura descritta in precedenza nell'articolo.

Nel diagramma è presente un hub; Hub 1.

  • L'hub 1 è connesso direttamente alle reti virtuali di rete virtuali di rete 4 e alla rete virtuale 5.

  • Il traffico tra reti virtuali 1, 2, 3 e i rami deve passare tramite VNet 4 NVA 10.4.0.5.

  • Tutto il traffico associato a Internet dalle reti virtuali 1, 2 e 3 deve passare tramite VNet 5 NVA 10.5.0.5.

Diagramma dell'architettura di rete.

Workflow

Diagramma del flusso di lavoro.

Per configurare il routing tramite appliance virtuale di rete, seguire questa procedura:

  1. Per consentire il traffico associato a Internet tramite la rete virtuale 5, sono necessarie reti virtuali 1, 2 e 3 per connettersi direttamente tramite peering di rete virtuale alla rete virtuale 5. È necessaria anche una route definita dall'utente configurata nelle reti virtuali per 0.0.0.0/0 e l'hop successivo 10.5.0.5.

    Se non si vuole connettere reti virtuali 1, 2 e 3 alla rete virtuale 5 e usare invece l'appliance virtuale di rete nella rete virtuale 4 per instradare il traffico 0.0.0.0/0 dai rami (connessioni VPN locali o ExpressRoute), passare al flusso di lavoro alternativo.

    Tuttavia, se si vuole che il traffico da rete virtuale a rete virtuale transiti attraverso l'appliance virtuale di rete, è necessario disconnettere la rete virtuale 1,2,3 dall'hub virtuale e connetterla o impilarla sopra la rete virtuale spoke NVA4. In rete WAN virtuale il traffico da rete virtuale a rete virtuale transita attraverso l'hub rete WAN virtuale o l'Firewall di Azure di un hub rete WAN virtuale (hub protetto). Se il peer di reti virtuali usa direttamente il peering reti virtuali, è possibile comunicare direttamente ignorando il transito tramite l'hub virtuale.

  2. Nella portale di Azure passare all'hub virtuale e creare una tabella di route personalizzata denominata RT_Shared. Questa tabella illustra le route tramite propagazione da tutte le reti virtuali e le connessioni di succursale. È possibile visualizzare questa tabella vuota nel diagramma seguente.

    • Route: non è necessario aggiungere route statiche.

    • Associazione: selezionare reti virtuali 4 e 5, il che significa che le connessioni di queste reti virtuali sono associate alla tabella di route RT_Shared.

    • Propagazione: poiché si desidera che tutti i rami e le connessioni di rete virtuale propagano dinamicamente le route a questa tabella di route, selezionare rami e tutte le reti virtuali.

  3. Creare una tabella di route personalizzata denominata RT_V2B per indirizzare il traffico dalle reti virtuali 1, 2 e 3 ai rami.

    • Route: aggiungere una voce di route statica aggregata per i rami, con hop successivo come connessione della rete virtuale 4. Configurare una route statica nella connessione della rete virtuale 4 per i prefissi dei rami. Indicare l'hop successivo come indirizzo IP specifico dell'appliance virtuale di rete nella rete virtuale 4.

    • Associazione: selezionare tutte le reti virtuali 1, 2 e 3. Ciò implica che le connessioni di rete virtuale 1, 2 e 3 verranno associate a questa tabella di route e potranno apprendere le route (statiche e dinamiche tramite propagazione) in questa tabella di route.

    • Propagazione: le connessioni propagano le route alle tabelle di route. Se si selezionano reti virtuali 1, 2 e 3, è possibile propagare le route dalle reti virtuali 1, 2 e 3 a questa tabella di route. Non è necessario propagare le route dalle connessioni di ramo a RT_V2B, perché il traffico di rete virtuale di succursale passa attraverso l'appliance virtuale di rete nella rete virtuale 4.

  4. Modificare la tabella di route predefinita DefaultRouteTable.

    Tutte le connessioni VPN, Azure ExpressRoute e VPN utente sono associate alla tabella di route predefinita. Tutte le connessioni VPN, ExpressRoute e VPN utente propagano le route allo stesso set di tabelle di route.

    • Route: aggiungere una voce di route statica aggregata per le reti virtuali 1, 2 e 3, con hop successivo come connessione alla rete virtuale 4. Configurare una route statica nella connessione della rete virtuale 4 per la rete virtuale 1, 2 e 3 prefissi aggregati. Indicare l'hop successivo come indirizzo IP specifico dell'appliance virtuale di rete nella rete virtuale 4.

    • Associazione: assicurarsi che l'opzione per i rami (VPN/ER/P2S) sia selezionata, assicurandosi che le connessioni di rami locali siano associate alla tabella di route predefinita.

    • Propagazione da: assicurarsi che l'opzione per i rami (VPN/ER/P2S) sia selezionata, assicurandosi che le connessioni locali propagano le route alla tabella di route predefinita.

Flusso di lavoro alternativo

In questo flusso di lavoro non si connettono reti virtuali 1, 2 e 3 alla rete virtuale 5. Usare invece l'appliance virtuale di rete nella rete virtuale 4 per instradare il traffico 0.0.0.0/0 dai rami (connessioni VPN locali o ExpressRoute).

Diagramma del flusso di lavoro alternativo.

Per configurare il routing tramite appliance virtuale di rete, seguire questa procedura:

  1. Nella portale di Azure passare all'hub virtuale e creare una tabella di route personalizzata denominata RT_NVA per indirizzare il traffico tramite l'appliance virtuale di rete 10.4.0.5

    • Route: nessuna azione necessaria.

    • Associazione: selezionare VNet4. Ciò implica che la connessione alla rete virtuale 4 verrà associata a questa tabella di route ed è in grado di apprendere le route (statiche e dinamiche tramite propagazione) in questa tabella di route.

    • Propagazione: le connessioni propagano le route alle tabelle di route. Se si selezionano reti virtuali 1, 2 e 3, è possibile propagare le route dalle reti virtuali 1, 2 e 3 a questa tabella di route. La selezione di rami (VPN/ER/P2S) consente la propagazione di route da rami/connessioni locali a questa tabella di route. Tutte le connessioni VPN, ExpressRoute e VPN utente propagano le route allo stesso set di tabelle di route.

  2. Creare una tabella di route personalizzata denominata RT_VNET per indirizzare il traffico dalle reti virtuali 1, 2 e 3 ai rami o a Internet (0.0.0.0/0) tramite l'appliance virtuale di rete VNet4. Il traffico da rete virtuale a rete virtuale sarà diretto e non tramite l'appliance virtuale di rete della rete virtuale 4. Se si vuole che il traffico venga eseguito tramite l'appliance virtuale di rete, disconnettere la rete virtuale 1, 2 e 3 e connetterli usando il peering reti virtuali a VNet4.

    • Route: 

      • Aggiungere una route aggregata '10.2.0.0/16' con hop successivo come connessione della rete virtuale 4 per il traffico proveniente da reti virtuali 1, 2 e 3 verso rami. Nella connessione VNet4 configurare una route per '10.2.0.0/16' e indicare l'hop successivo come indirizzo IP specifico dell'appliance virtuale di rete nella rete virtuale 4.

      • Aggiungere una route "0.0.0.0/0" con hop successivo come connessione alla rete virtuale 4. '0.0.0.0/0' viene aggiunto per implicare l'invio del traffico a Internet. Non implica prefissi di indirizzi specifici relativi a reti virtuali o rami. Nella connessione VNet4 configurare una route per "0.0.0.0/0" e indicare l'hop successivo come indirizzo IP specifico dell'appliance virtuale di rete nella rete virtuale 4.

    • Associazione: selezionare tutte le reti virtuali 1, 2 e 3. Ciò implica che le connessioni di rete virtuale 1, 2 e 3 verranno associate a questa tabella di route e potranno apprendere le route (statiche e dinamiche tramite propagazione) in questa tabella di route.

    • Propagazione: le connessioni propagano le route alle tabelle di route. Se si selezionano reti virtuali 1, 2 e 3, è possibile propagare le route dalle reti virtuali 1, 2 e 3 a questa tabella di route. Assicurarsi che l'opzione per i rami (VPN/ER/P2S) non sia selezionata. In questo modo, le connessioni locali non possono accedere direttamente alle reti virtuali 1, 2 e 3.

  3. Modificare la tabella di route predefinita DefaultRouteTable.

    Tutte le connessioni VPN, Azure ExpressRoute e VPN utente sono associate alla tabella di route predefinita. Tutte le connessioni VPN, ExpressRoute e VPN utente propagano le route allo stesso set di tabelle di route.

    • Route: 

      • Aggiungere una route aggregata '10.1.0.0/16' per le reti virtuali 1, 2 e 3 con hop successivo come connessione della rete virtuale 4.

      • Aggiungere una route "0.0.0.0/0" con hop successivo come connessione alla rete virtuale 4. '0.0.0.0/0' viene aggiunto per implicare l'invio del traffico a Internet. Non implica prefissi di indirizzi specifici relativi a reti virtuali o rami. Nel passaggio precedente per la connessione VNet4 è già stata configurata una route per '0.0.0.0/0', con hop successivo come indirizzo IP specifico dell'appliance virtuale di rete nella rete virtuale 4.

    • Associazione: assicurarsi che sia selezionata l'opzione per i rami (VPN/ER/P2S ). In questo modo si garantisce che le connessioni di rami locali siano associate alla tabella di route predefinita. Tutte le connessioni VPN, Azure ExpressRoute e VPN utente sono associate solo alla tabella di route predefinita.

    • Propagazione da: assicurarsi che sia selezionata l'opzione per i rami (VPN/ER/P2S). In questo modo, le connessioni locali propagano le route alla tabella di route predefinita. Tutte le connessioni VPN, ExpressRoute e VPN utente propagano le route allo stesso set di tabelle di route.

Considerazioni

  • Gli utenti del portale devono abilitare "Propaga alla route predefinita" nelle connessioni (VPN/ER/P2S/VNet) per rendere effettiva la route 0.0.0.0/0.

  • Per rendere effettiva la route 0.0.0.0.0/0, gli utenti PS/CLI/REST devono impostare il flag 'enableinternetsecurity' su true.

  • La connessione di rete virtuale non supporta l'indirizzo IP hop successivo "multiplo/univoco" all'appliance virtuale di rete "stessa" in una rete virtuale spoke "se" una delle route con indirizzo IP hop successivo è indicata come indirizzo IP pubblico o 0.0.0.0/0 (Internet).

  • Quando 0.0.0.0/0 è configurato come route statica in una connessione di rete virtuale, tale route viene applicata a tutto il traffico, incluse le risorse all'interno dello spoke stesso. Ciò significa che tutto il traffico verrà inoltrato all'indirizzo IP hop successivo della route statica (IP privato dell'appliance virtuale di rete). Pertanto, nelle distribuzioni con una route 0.0.0.0/0 con l'indirizzo IP dell'appliance virtuale di rete hop successivo configurato in una connessione di rete virtuale spoke, per accedere ai carichi di lavoro nella stessa rete virtuale dell'appliance virtuale di rete direttamente (ovvero che il traffico non passa attraverso l'appliance virtuale di rete), specificare una route /32 nella connessione di rete virtuale spoke. Ad esempio, se si vuole accedere direttamente alla versione 10.1.3.1, specificare 10.1.3.1/32 hop successivo 10.1.3.1 nella connessione di rete virtuale spoke.

  • Per semplificare il routing e ridurre le modifiche apportate alle tabelle di route dell'hub rete WAN virtuale, è consigliabile usare la nuova opzione "peering BGP con rete WAN virtuale hub".

Passaggi successivi