Condividi tramite


Azure per tecnici di rete

In qualità di tecnico di rete convenzionale,ci si è già occupati di asset fisici come router, commutatori, cavi, firewall per creare l'infrastruttura. A un livello logico è stata configurata la rete LAN virtuale (VLAN), il protocollo STP (albero di spanning) e i protocolli di routing (RIP, OSPF, BGP). La rete è stata gestita usando gli strumenti di gestione e l'interfaccia della riga di comando. La rete in ingresso nel cloud è diversa dove gli endpoint di rete sono logici e l'uso di protocolli di routing è minimo. Si userà l'API di Azure Resource Manager, l'interfaccia della riga di comando di Azure e PowerShell per configurare e gestire gli asset in Azure. Si inizierà il percorso di rete nel cloud comprendendo i tenant di base della rete di Azure.

Rete virtuale

Quando si progetta una rete dal basso verso l'alto, si raccolgono alcune informazioni di base. Queste informazioni potrebbero riguardare il numero di host, i dispositivi di rete, il numero di subnet, il routing tra subnet e i domini di isolamento, ad esempio VLAN. Queste informazioni consentono di dimensionare i dispositivi di rete e di sicurezza oltre che di creare l'architettura per supportare applicazioni e servizi.

Per distribuire le applicazioni e i servizi in Azure, si inizierà creando un limite logico in Azure, denominato rete virtuale. Questa rete virtuale è simile a un limite fisico di rete. Trattandosi di una rete virtuale, non sono necessarie apparecchiature fisiche, ma bisogna comunque pianificare le entità logiche, ad esempio indirizzi IP, subnet IP, routing e criteri.

Le reti virtuali create in Azure sono preconfigurate con un intervallo di indirizzi IP (10.0.0.0/16). Questo intervallo non è fisso; è possibile definire un intervallo IP personalizzato. È possibile definire sia gli intervalli di indirizzi IPv4 che IPv6. Gli intervalli IP definiti per la rete virtuale non vengono annunciati su Internet. È possibile creare più subnet dall'intervallo IP. Queste subnet verranno usate per assegnare indirizzi IP alle interfacce di rete virtuale (vNIC). I primi quattro indirizzi IP di ogni subnet sono riservati e non possono essere usati per l'allocazione. Non esiste alcun concetto di VLAN in un cloud pubblico. È tuttavia possibile creare l'isolamento all'interno di una rete virtuale in base alle subnet definite.

È possibile creare una subnet di grandi dimensioni che comprende tutto lo spazio indirizzi della rete virtuale oppure scegliere di creare più subnet. Tuttavia, se si usa un gateway di rete virtuale, Azure richiede di creare una subnet denominata "subnet gateway". Azure userà questa subnet per assegnare indirizzi IP ai gateway della rete virtuale.

Impostazioni

Quando si assegna un indirizzo IP a un host, in realtà si assegna l'indirizzo IP a una scheda di interfaccia di rete. È possibile assegnare due tipi di indirizzi IP a una scheda di interfaccia di rete in Azure:

  • Indirizzi IP pubblici: usati per comunicare in ingresso e in uscita (senza NAT), con Internet e altre risorse di Azure non connesse a una rete virtuale. L'assegnazione di un indirizzo IP pubblico a un'interfaccia di rete è facoltativa. Gli indirizzi IP pubblici appartengono allo spazio indirizzi IP di Microsoft.
  • Indirizzi IP privati: usati per la comunicazione all’interno di una rete virtuale, nella rete locale e in Internet (con NAT). Lo spazio indirizzi IP definito nella rete virtuale viene considerato privato anche se si configura lo spazio indirizzi IP pubblici. Microsoft non annuncia questo spazio in Internet. È necessario assegnare almeno un indirizzo IP privato a una VM.

Come per gli host o i dispositivi fisici esistono due modi per allocare un indirizzo IP a una risorsa, ovvero dinamico o statico. In Azure il metodo di allocazione predefinito è dinamico, cioè un indirizzo IP viene allocato quando si crea una macchina virtuale o si avvia una macchina virtuale arrestata. L'indirizzo IP viene rilasciato quando si arresta o si elimina la macchina virtuale. Per far sì che l'indirizzo IP della VM rimanga invariato, è possibile impostare in modo esplicito il metodo di allocazione statico. In questo caso, un indirizzo IP viene assegnato immediatamente. Viene rilasciato solo quando si elimina la VM o si modifica il relativo metodo di allocazione in dinamico.

Gli indirizzi IP privati vengono allocati dalle subnet definite all'interno di una rete virtuale. Per una macchina virtuale viene scelta una subnet per l'allocazione di indirizzi IP. Se una macchina virtuale contiene più schede di interfaccia di rete, è possibile scegliere una subnet diversa per ogni scheda di interfaccia di rete.

Definizione dei percorsi di trasferimento

Quando si crea una rete virtuale, Azure crea una tabella di routing per la rete. Questa tabella di routing contiene i tipi di route seguenti.

  • Route di sistema
  • Route predefinite della subnet
  • Route di altre reti virtuali
  • Route BGP
  • Route dell'endpoint servizio
  • Route definite dall'utente

Quando si crea una rete virtuale per la prima volta senza definire alcuna subnet, Azure crea voci di routing nella tabella di routing. Queste route sono dette route di sistema. Le route di sistema vengono definite in questa posizione. Non è possibile modificare queste route. È tuttavia possibile sostituire le route di sistema configurando route definite dall'utente.

Quando si creano una o più subnet all'interno di una rete virtuale, Azure crea voci predefinite nella tabella di routing per abilitare la comunicazione tra queste subnet. Queste route possono essere modificate usando route statiche, ovvero route definite dall'utente in Azure.

quando si crea un peering di rete virtuale tra due reti virtuali, viene aggiunta una route per ogni intervallo di indirizzi nello spazio degli indirizzi di ogni rete virtuale per la quale viene creato un peering.

Se il gateway di rete locale scambia route con un gateway di rete virtuale di Azure tramite Border Gateway Protocol (BGP), viene aggiunta una route per ogni route propagata dal gateway di rete locale. Queste route vengono visualizzate nella tabella di routing come route BGP.

Azure aggiunge gli indirizzi IP pubblici per alcuni servizi alla tabella di route quando si abilita un endpoint di servizio per il servizio. Gli endpoint servizio sono abilitati per le singole subnet all'interno di una rete virtuale. Quando si abilita un endpoint servizio, la route viene aggiunta solo alla tabella di route per la subnet appartenente a questo servizio. Azure gestisce automaticamente gli indirizzi nella tabella di route quando gli indirizzi cambiano.

Le route definite dall'utente sono anche dette route personalizzate. È possibile creare route definite dall'utente in Azure per sostituire le route di sistema predefinite di Azure oppure per aggiungere altre route alla tabella di route di una subnet. Creare una tabella di route in Azure, poi associare la tabella di route alle subnet della rete virtuale.

Nel caso di voci in conflitto in una tabella di routing, Azure seleziona l'hop successivo in base alla corrispondenza del prefisso più lungo, in modo simile ai router tradizionali. Tuttavia, se sono presenti più voci di hop successivo con lo stesso prefisso di indirizzo, Azure seleziona le route nell'ordine seguente.

  1. Route definite dall'utente
  2. Route BGP
  3. Route di sistema

Sicurezza

È possibile filtrare il traffico di rete da e verso le risorse in una rete virtuale usando i gruppi di sicurezza di rete. È anche possibile usare appliance virtuali di rete come Firewall di Azure o firewall da altri fornitori. È possibile controllare come Azure instrada il traffico proveniente da subnet. È inoltre possibile limitare gli utenti dell'organizzazione che possono usare le risorse nelle reti virtuali.

Un gruppo di sicurezza di rete (NSG) contiene una serie di regole dell'elenco di controllo di accesso (ACL) che consentono o rifiutano il traffico di rete verso le subnet, le interfacce di rete o entrambe. I gruppi di sicurezza di rete possono essere associati a subnet o singole interfacce di rete connesse a una subnet. Quando un gruppo di sicurezza di rete viene associato a una subnet, le regole ACL si applicano a tutte le VM in tale subnet. Inoltre, il traffico verso una singola scheda di interfaccia di rete può essere limitato associando un gruppo di sicurezza di rete direttamente a una scheda di interfaccia di rete.

I gruppi di sicurezza di rete includono due tipi di regole: In ingresso e In uscita. La priorità per una regola deve essere univoca all'interno di ogni set. Ogni regola ha proprietà di protocollo, intervalli di porte di origine e destinazione, prefissi degli indirizzi, direzione del traffico, priorità e tipo di accesso. Tutti i gruppi di sicurezza di rete contengono un set di regole predefinite. Le regole predefinite non possono essere eliminate, ma poiché hanno la priorità più bassa, è possibile eseguirne l'override con le regole create dall'utente.

Verifica

Route nella rete virtuale

La combinazione di route create dall'utente, route predefinite di Azure e route propagate dalla rete locale tramite un gateway VPN di Azure (se la rete virtuale è connessa alla rete locale) con BGP (Border Gateway Protocol), rappresenta le route valide per tutte le interfacce di rete in una subnet. È possibile visualizzare queste route valide passando alla scheda di interfaccia di rete tramite il portale, PowerShell o l'interfaccia della riga di comando. Per altre informazioni sulle route valide su una scheda di interfaccia di rete vedere Get-AzEffectiveRouteTable.

Gruppi di sicurezza di rete

Le regole di sicurezza valide applicate a un'interfaccia di rete sono un’aggregazione delle regole presenti nel gruppo di sicurezza associato all'interfaccia di rete e quelle della subnet in cui si trova l'interfaccia di rete. È possibile visualizzare tutte le regole di sicurezza effettive dei gruppi di sicurezza di rete applicate alle interfacce di rete della macchina virtuale passando alla scheda di interfaccia di rete tramite il portale, PowerShell o l'interfaccia della riga di comando.

Passaggi successivi

Informazioni sulla rete virtuale.

Informazioni sul routing di rete virtuale.

Informazioni sui gruppi di sicurezza di rete.