Condividi tramite

Scenario dell'appliance virtuale

  • Articolo

Uno scenario comune tra i clienti di Azure di grandi dimensioni è la necessità di offrire un'applicazione a due livelli che sia esposta a Internet e che, al contempo, consenta anche l'accesso al livello back-end da un data center locale. Questo articolo illustra uno scenario che prevede tabelle di route, un gateway VPN e appliance di rete virtuali per distribuire un ambiente a due livelli che soddisfi i requisiti seguenti:

  • Un'applicazione Web deve essere accessibile solo da Internet pubblico.
  • Un server Web che ospita l'applicazione deve essere in grado di accedere a un server applicazioni back-end.
  • Tutto il traffico da Internet all'applicazione Web deve passare attraverso un'appliance virtuale firewall. Questa appliance virtuale viene usata solo per il traffico Internet.
  • Tutto il traffico verso il server applicazioni deve passare attraverso un'appliance virtuale firewall. Questa appliance virtuale viene usata per l'accesso al server back-end e per l'accesso proveniente dalla rete locale tramite un gateway VPN.
  • Gli amministratori devono essere in grado di gestire le appliance virtuali firewall dai computer locali, con una terza appliance virtuale firewall che viene usata esclusivamente per scopi di gestione.

Questo esempio è uno scenario di rete perimetrale standard con una rete perimetrale e una rete protetta. È possibile costruire questo scenario in Azure usando gruppi di sicurezza di rete (NSG), appliance virtuali del firewall o una combinazione di entrambi.

La tabella seguente mostra un confronto tra vantaggi e svantaggi di gruppi di sicurezza di rete e appliance virtuali firewall.

Articolo Vantaggi Svantaggi
NSG Nessun costo.
Integrato nell'accesso in base al ruolo di Azure.
Possibilità di creare regole nei modelli di Azure Resource Manager.		 La complessità può variare in ambienti più grandi.
Firewall Controllo completo del piano dati.
Gestione centrale con console firewall.		 Costo dell'appliance firewall.
Non integrato nell'accesso in base al ruolo di Azure.

La soluzione seguente usa appliance virtuali firewall per implementare uno scenario di rete perimetrale/rete protetta.

Considerazioni

È possibile distribuire l'ambiente precedente in Azure usando le funzionalità attualmente disponibili:

  • Rete virtuale: una rete virtuale di Azure agisce in modo simile a una rete locale. È possibile segmentarla in una o più subnet per offrire l'isolamento del traffico e la separazione delle problematiche.
  • Appliance virtuale: numerosi partner offrono appliance virtuali in Azure Marketplace da usare per i tre firewall descritti in precedenza.
  • Tabelle di route: le tabelle di route vengono usate dalla rete di Azure per controllare il flusso dei pacchetti all'interno di una rete virtuale. È possibile applicare queste tabelle di route alle subnet. È possibile applicare una tabella di route a GatewaySubnet, che inoltra tutto il traffico che entra nella rete virtuale di Azure da una connessione ibrida a un'appliance virtuale.
  • Inoltro IP: per impostazione predefinita, il motore di rete Azure inoltra i pacchetti alle schede di interfaccia di rete (NIC) virtuale solo se l'indirizzo IP di destinazione dei pacchetti corrisponde all'indirizzo IP della scheda di interfaccia di rete. Se una tabella di route indica che un pacchetto dovrà essere inviato a un'appliance virtuale specifica, il motore di rete di Azure elimina tale pacchetto. Per far sì che il pacchetto venga inviato a una macchina virtuale (in questo caso un'appliance virtuale) che non è la destinazione effettiva del pacchetto, abilitare l'inoltro IP per l'appliance virtuale.
  • Gruppi di sicurezza di rete: l'esempio seguente non usa gruppi di sicurezza di rete, ma è possibile usare gruppi di sicurezza di rete applicati alle subnet o alle schede di interfaccia di rete in questa soluzione. I gruppi di sicurezza di rete filtrano ulteriormente il traffico all'interno e all'esterno di tali subnet e schede di interfaccia di rete.

Diagramma che mostra la connettività IPv6.

In questo esempio, una sottoscrizione include gli elementi seguenti:

  • Due gruppi di risorse (non indicati nel diagramma):

    • ONPREMRG: contiene tutte le risorse necessarie per simulare una rete locale.
    • AZURERG: contiene tutte le risorse necessarie per l'ambiente di rete virtuale di Azure.

  • Una rete virtuale denominata onpremvnet viene segmentata e usata per simulare un data center locale:

    • onpremsn1: una subnet che contiene una macchina virtuale che esegue una distribuzione Linux per simulare un server locale.
    • onpremsn2: una subnet che contiene una macchina virtuale che esegue una distribuzione Linux per simulare un computer locale usato da un amministratore.

  • Un'appliance virtuale firewall è denominata OPFW in onpremvnet. Viene usata per gestire un tunnel per azurevnet.

  • Una rete virtuale denominata azurevnet è segmentata come segue:

    • azsn1: una subnet del firewall esterno usata esclusivamente per il firewall esterno. Tutto il traffico Internet in ingresso passa attraverso questa subnet. Questa subnet contiene solo una scheda di interfaccia di rete collegata al firewall esterno.
    • azsn2: una subnet front-end che ospita una macchina virtuale in esecuzione come server Web accessibile da Internet.
    • azsn3: una subnet back-end che ospita una macchina virtuale che esegue un server applicazioni back-end a cui accede il server Web front-end.
    • azsn4: una subnet di gestione usata esclusivamente per consentire l'accesso di gestione a tutte le appliance virtuali firewall. Questa subnet contiene solo una scheda di interfaccia di rete per ogni appliance virtuale firewall usata nella soluzione.
    • GatewaySubnet: una subnet di connessione ibrida di Azure necessaria per consentire ad Azure ExpressRoute e al gateway VPN di Azure di offrire la connessione tra le reti virtuali di Azure e altre reti.

  • Nella rete azurevnet sono presenti tre appliance virtuali firewall:

    • AZF1: un firewall esterno esposto a Internet pubblico con una risorsa di indirizzo IP pubblico in Azure. È necessario ottenere un modello da Azure Marketplace o direttamente dal fornitore dell'appliance per la distribuzione di un'appliance virtuale con tre schede di interfaccia di rete.
    • AZF2: un firewall interno usato per gestire il traffico tra azsn2 e azsn3. Questo firewall è anche un'appliance virtuale a tre schede di interfaccia di rete.
    • AZF3: un firewall di gestione accessibile agli amministratori dal centro dati locale e connesso a una subnet usata per la gestione di tutte le appliance firewall. I modelli di appliance virtuale a due schede di interfaccia di rete sono disponibili in Azure Marketplace. Inoltre, è possibile richiederne uno direttamente al fornitore dell'appliance.

Tabelle di route

Collegare ogni subnet in Azure a una tabella di route per definire come viene indirizzato il traffico che ha origine nella subnet. Se non sono presenti route definite dall'utente (UDR), Azure usa le route predefinite per consentire il flusso del traffico da una subnet all'altra. Per comprendere meglio le tabelle di route e il routing del traffico, vedere Routing del traffico di rete virtuale di Azure.

Per garantire la comunicazione tramite l'appliance firewall adeguata, in base all'ultimo requisito indicato in precedenza, è necessario creare la tabella seguente in azurevnet.

azgwudr

In questo scenario, il solo traffico da locale ad Azure viene usato per gestire i firewall connettendosi a AZF3 e tale traffico deve passare attraverso il firewall interno, AZF2. In GatewaySubnet è necessaria una sola route, come illustrato di seguito:

Destinazione Hop successivo Spiegazione
10.0.4.0/24 10.0.3.11 Consente al traffico locale di raggiungere il firewall di gestione AZF3.

azsn2udr

Destinazione Hop successivo Spiegazione
10.0.3.0/24 10.0.2.11 Consente il traffico verso la subnet di back-end che ospita il server applicazioni tramite AZF2.
0.0.0.0/0 10.0.2.10 Consente di indirizzare il resto del traffico tramite AZF1.

azsn3udr

Destinazione Hop successivo Spiegazione
10.0.2.0/24 10.0.3.10 Consente al traffico verso azsn2 di passare da un server app al server Web attraverso AZF2.

È anche necessario creare tabelle route per le subnet in onpremvnet per simulare il centro dati locale.

onpremsn1udr

Destinazione Hop successivo Spiegazione
192.168.2.0/24 192.168.1.4 Consente il traffico da onpremsn2 attraverso OPFW.

onpremsn2udr

Destinazione Hop successivo Spiegazione
10.0.3.0/24 192.168.2.4 Consente il traffico verso la subnet back-end in Azure tramite OPFW.
192.168.1.0/24 192.168.2.4 Consente il traffico da onpremsn1 attraverso OPFW.

Inoltro IP

Le tabelle di route e l'inoltro IP sono funzionalità che è possibile usare in combinazione per consentire alle appliance virtuali di gestire il flusso del traffico in una rete virtuale di Azure. Un dispositivo virtuale non è altro che una macchina virtuale che esegue un'applicazione utilizzata per gestire il traffico di rete in qualche modo, ad esempio un firewall o un dispositivo NAT.

Questa macchina virtuale di appliance virtuale deve essere in grado di ricevere traffico in ingresso che non sia indirizzato a se stessa. Per consentire a una macchina virtuale di ricevere il traffico indirizzato ad altre destinazioni, è necessario abilitare l'inoltro IP per la macchina virtuale. Si tratta di un'impostazione di Azure e non del sistema operativo guest. L'appliance virtuale deve comunque eseguire qualche tipo di applicazione per gestire il traffico in ingresso e indirizzarlo correttamente.

Per altre informazioni sull'inoltro IP, vedere Routing del traffico di rete virtuale di Azure.

Si supponga, ad esempio, che una rete virtuale di Azure sia configurata come segue:

  • La subnet onpremsn1 contiene una macchina virtuale denominata onpremvm1.
  • La subnet onpremsn2 contiene una macchina virtuale denominata onpremvm2.
  • Un'appliance virtuale denominata OPFW è connessa a onpremsn1 e onpremsn2.
  • Una route definita dall'utente collegata a onpremsn1 specifica che tutto il traffico verso onpremsn2 deve essere inviato a OPFW.

A questo punto, se onpremvm1 tenta di stabilire una connessione con onpremvm2, viene usata la route definita dall'utente e il traffico viene inviato a OPFW come hop successivo. La destinazione effettiva del pacchetto non viene modificata. Indica ancora che la destinazione è onpremvm2.

Se l'inoltro IP non è attivato per OPFW, la logica della rete virtuale di Azure rilascia i pacchetti perché consente l'invio di pacchetti a una macchina virtuale solo se l'indirizzo IP della macchina virtuale è la destinazione del pacchetto.

Con l'inoltro IP, la logica della rete virtuale di Azure inoltra i pacchetti a OPFW, senza modificare l'indirizzo di destinazione originale. OPFW deve gestire i pacchetti e determinare cosa farne.

Per far sì che lo scenario precedente funzioni è necessario abilitare l'inoltro IP sulle schede di interfaccia di rete per OPFW, AZF1, AZF2 e AZF3 che vengono usate per il routing. Si tratta di tutte le schede di interfaccia di rete ad eccezione di quelle collegate alla subnet di gestione.

Regole del firewall

Come descritto in precedenza, l'inoltro IP assicura solo che i pacchetti vengano inviati alle appliance virtuali. L'appliance deve comunque stabilire come gestire i pacchetti. Nello scenario precedente è necessario creare le regole seguenti nelle appliance.

OPFW

OPFW rappresenta un dispositivo locale che contiene le regole seguenti:

  • Route: tutto il traffico verso 10.0.0.0/16 (azurevnet) deve essere inviato attraverso il tunnel ONPREMAZURE.
  • Criteri: consentire tutto il traffico bidirezionale tra port2 e ONPREMAZURE.

AZF1

AZF1 rappresenta un'appliance virtuale di Azure che contiene la regola seguente:

Criteri: consentire tutto il traffico bidirezionale tra port1 e port2.

AZF2

AZF2 rappresenta un'appliance virtuale di Azure che contiene la regola seguente:

Criteri: consentire tutto il traffico bidirezionale tra port1 e port2.

AZF3

AZF3 rappresenta un'appliance virtuale di Azure che contiene la regola seguente:

Route: tutto il traffico verso 192.168.0.0/16 (onpremvnet) deve essere inviato all'indirizzo IP del gateway di Azure (ovvero 10.0.0.1) attraverso port1.

Gruppi di sicurezza di rete

In questo scenario i gruppi di sicurezza di rete non vengono usati. È tuttavia possibile applicare i gruppi di sicurezza di rete a ogni subnet per limitare il traffico in ingresso e in uscita. È ad esempio possibile applicare le seguenti regole per gruppi di sicurezza di rete alla subnet del firewall esterno.

In ingresso

  • Consentire tutto il traffico TCP da Internet alla porta 80 in qualsiasi macchina virtuale della subnet.
  • Rifiutare il resto del traffico da Internet.

In uscita

Rifiutare il traffico verso Internet.

Procedura generale

Per distribuire questo scenario, seguire questa procedura:

  1. Accedere alla sottoscrizione di Azure.

  2. Se si intende distribuire una rete virtuale per simulare la rete locale, distribuire le risorse che fanno parte di ONPREMRG.

  3. Distribuire le risorse che fanno parte di AZURERG.

  4. Distribuire il tunnel da onpremvnet a azurevnet.

  5. Dopo il provisioning di tutte le risorse, accedere a onpremvm2 ed effettuare il ping di 10.0.3.101 per testare la connettività tra onpremsn2 e azsn3.