Azure Networking: gestione degli indirizzi IP per il traffico in uscita da Azure

Quando si progettano architetture in Azure è spesso importante stabilire con precisione quali indirizzi IP pubblici vengono utilizzati per il traffico di rete in uscita. Un requisito comunemente richiesto è garantire che il traffico in uscita dalla rete virtuale di Azure avvenga con indirizzi IP pubblici stabiliti. Questo requisito tipicamente è dato dalla necessità di autorizzare in modo esplicito il traffico proveniente da Azure su altre risorse. In questo articolo viene descritto come in Azure è possibile governare questo aspetto, quali sono gli elementi da prendere in considerazione e quali novità sono state recentemente introdotte in questo ambito.

Per impostazione predefinita, il traffico in uscita da una rete virtuale di Azure utilizza degli indirizzi IP pubblici allocati in modo casuale e questi possono cambiare.

Assegnazione IP Pubblico alla singola macchina virtuale

Quando si ha la necessità di fissare l’indirizzo IP Pubblico per il traffico in uscita di una singola macchina virtuale, il metodo più semplice è assegnare a questa un indirizzo IP Pubblico. Tale indirizzo IP sarà utilizzato per il traffico in ingresso, se necessario, e per il traffico in uscita. Tramite i Network Security Groups (NSGs), lo strumento principale per controllare il traffico di rete in Azure, è possibile filtrare le comunicazioni con apposite regole di deny e permit.

Assegnazione IP Pubblico al Load Balancer

Anziché assegnare un indirizzo IP pubblico direttamente a una macchina virtuale, è possibile assegnarlo a un load balancer. In questo modo, qualsiasi macchina virtuale aggiunta al pool di back-end del load balancer utilizzerà l’IP pubblico ad esso assegnato per il traffico di rete in uscita.

Figura 1 – Load Balancer con IP Pubblico

Questo approccio è consigliato qualora ci sia davvero l’esigenza di adottare un Load Balancer per bilanciare il traffico di rete in ingresso tra più macchine virtuali. In questo modo è anche possibile limitare il numero di IP pubblici richiesti, configurando più macchine virtuali dietro allo stesso load balancer.

Utilizzo di Azure Firewall

In presenza di Azure Firewall, se il traffico di rete viene opportunamente fatto confluire a questo componente tramite delle rotte specifiche, si ha la certezza che uscirà verso Internet usando gli IP Pubblici assegnati all’istanza Azure Firewall. Ad Azure Firewall si possono associare fino a 250 indirizzi IP pubblici, ma è opportuno tenere in considerazione che attualmente l’indirizzo IP Pubblico sorgente di Azure Firewall utilizzato per le connessioni viene scelto in modo casuale tra gli IP assegnati. Questo aspetto è da valutare quando sono necessarie autorizzazioni specifiche per il traffico proveniente da Azure Firewall e se si deve gestire l’accesso a FTP Passivi (non supportati se Azure Firewall ha più indirizzi IP assegnati). Microsoft ha comunque in roadmap la possibilità di fare configurazioni SNAT specificando l’indirizzo IP Pubblico da utilizzare.

Figura 2 – Azure Firewall overview

Azure Firewall è un componente sempre più diffuso e la sua attivazione è consigliata per gestire e governare al meglio il traffico di rete. Tuttavia, in assenza di questo componente è possibile valutare metodi alternativi meno costosi se l’obiettivo unico è governare quali indirizzi IP vengono utilizzati nel traffico di rete in uscita.

Virtual Network NAT

Virtual Network NAT è un nuovo metodo che è stato recentemente introdotto per semplificare nelle reti virtuali la connettività Internet ed interessa esclusivamente il traffico di rete in uscita. Se configurato su una subnet, tutta il traffico in uscita utilizzerà gli indirizzi IP pubblici statici specificati. Il tutto è possibile senza l’adozione di indirizzi IP pubblici direttamente collegati alle macchine virtuali e di load balancer.

Figura 3 – Virtual Network NAT

Una subnet può quindi essere configurata specificando quale risorsa Gateway NAT utilizzare. Al termine della configurazione tutti i flussi di rete in uscita (UDP e TCP) provenienti da qualsiasi macchina virtuale attestata su quella subnet, utilizzeranno l’IP Pubblico (standard SKU), il Public IP Prefix oppure una combinazione di questi. La medesima risorsa Gateway NAT può essere utilizzata da più subnet, purché appartenenti alla stessa Virtual Network.

Virtual Network NAT è compatibile con le seguenti risorse, aventi SKU standard:

  • Load balancer
  • Public IP address
  • Public IP prefix

Questi componenti utilizzati insieme a Virtual Network NAT forniscono connettività Internet in entrata alle subnet. Virtual Network NAT gestisce invece tutta la connettività Internet in uscita dalla subnet. L’utilizzo congiunto di questi componenti è possibile in quanto sono consapevoli della direzione in cui è stato avviato il flusso e ne permettono la corretta gestione.

Figura 4 – Virtual Network NAT flow direction

Lo SLA garantito per questa funzionalità è del 99.9%, in quanto viene distribuita automaticamente dalla piattaforma su più fault domains per sostenere al meglio eventuali fault.

Virtual Network NAT è di default un servizio regionale ed è possibile isolarlo in una specifica zona (zonal deployment), quando si devono contemplare scenari che adottano diverse availability zones.

Figura 5 – Virtual Network NAT con availability zones

Per monitorare l’utilizzo di questo componente e per effettuare operazioni di troubleshooting è possibile consultare le metriche esposte in Azure Monitor:

  • Bytes
  • Packets
  • Dropped Packets
  • Total SNAT connections
  • SNAT connection state transitions per interval.

NSG flow logging non è al momento supportato per il Virtual Network NAT.

Il costo di questo componente è dato da due fattori:

  • Ore di esistenza della risorsa
  • Dati processati

Per maggiori dettagli sui costi è possibile consultare la pagina Microsoft relativa al pricing per questo componente.

Conclusioni

Per governare quali indirizzi IP vengono utilizzati dai sistemi in Azure per comunicare verso l’esterno ci sono diverse possibilità, ciascuna con le proprie caratteristiche. Nel caso si stia adottando la topologia di rete Hub-spoke con un Azure Firewall nella rete di Hub, il controllo è garantito by design. Un’ottima soluzione in assenza di Azure Firewall oppure di altre Network Virtual Appliance è l’adozione della metodologia Virtual Network NAT recentemente introdotta.