Pregi e limitazioni di Networking su macchine virtuali in Windows Azure

Ciao a tutti!

Negli ultimi tempi, sono sempre più numerosi i clienti che hanno deciso di migrare i loro server sulla piattaforma IaaS nel cloud Windows Azure.

Se non lo avete ancora fatto, vi consiglio di dare una occhiata a questa straordinaria tecnologia perché, se siete appassionati di Windows e reti come il sottoscritto, non potete proprio perdervela (qui spieghiamo come fare http://blogs.technet.com/b/itasupport/archive/2013/10/16/windows-azure-tutto-sulla-versione-di-valutazione-gratuita.aspx).

Windows Azure vi permette di creare delle macchine virtuali sul cui sistema operativo avrete il (quasi) completo controllo, dall’installazione di ruoli, a personalizzazione di applicazioni e configurazioni, il tutto tramite una normalissima connessione RDP, proprio come quella che utilizzate quando dovete amministrare la vostra macchina in sala server. L’unica differenza è che, poiché ovviamente non ci sarà mai possibile “scendere in sala server” per andare a loggarsi in consolle, se creiamo dei problemi di connettività di rete non riusciremo più a collegarci alla VM.

Di seguito, vi propongo un breve elenco preliminare di quello che si può e non si può fare con una macchina virtuale Windows Azure – principalmente dal punto di vista del networking.

Scrivo questo articolo ad Ottobre 2013: poiché Windows Azure è una tecnologia nuovissima, non è escluso che alcune di queste funzionalità/limitazioni possano cambiare molto presto, già a partire dalla prossima release.

Indirizzamento IP interno

Le macchine virtuali in Windows Azure sono dotate di una singola scheda di rete, alla quale si può associare un singolo indirizzo IP. Questo indirizzo viene comunemente denominato Internal o Dynamic IP address (DIP).
Se vogliamo, possiamo scegliere una sottorete di indirizzamento privato ( nella classe 10.0.0.0, 172.16.0.0. o 192.168.0.0.) altrimenti il sistema la sceglierà per noi.

Quello che è molto importante sapere è che Windows Azure ha un meccanismo interno di DHCP, per il quale non è possibile assegnare un IP address statico ad una macchina virtuale! Attenzione: se ciò viene fatto dalle proprietà della scheda di rete, perderemo connettività con la VM.
Ma non abbiate paura: Azure assegna un lease DHCP sostanzialmente infinito alla VM (vedi screenshot) quindi finchè non la stopperemo, possiamo stare sicuri che la macchina virtuale avrà sempre lo stesso indirizzo IP. Quindi anche un server DNS / Domain Controller funzionerà egregiamente anche se l’IP è di fatto dinamico.

Una altra considerazione importante è che i primi 3 indirizzi IP di ogni subnet sono riservati per i servizi Windows Azure. è bene tenere in mente questa informazione in fase di network planning.
Se infatti una subnet /29 è normalmente sufficiente per assegnare indirizzi a 6 host (2^3=8 indirizzi disponibili – indirizzo di rete – indirizzo di broadcast = 6), una subnet /29 su Azure basterà per soli 3 host (6 -3 riservati).

Nella virtual network interna di Azure non ci sono firewall quindi tutto il traffico tra le VM nello stesso Cloud Service può transitare senza problemi (a meno che non configuriamo il Windows Firewall nel sistema operativo della VM).

Le uniche eccezioni a questa regola sono il traffico broadcast e il traffico IPv6 che non sono attualmente supportati su Azure.

Indirizzamento IP esterno

Tutte le macchine virtuali Azure sono esposte su Internet, e quindi sono abbinate anche ad un indirizzo IP pubblico. Tale IP pubblico è detto VIP (Public Virtual IP address).
è bene ricordare che ogni macchina virtuale è univocamente associata ad un singolo VIP, ma lo stesso VIP è utilizzato da Azure per esporre numerose VM.

Per essere sicuri quindi di accedere proprio alla nostra VM da internet, è stato implementato il concetto di Endpoint. L’endpoint è una semplicissima associazione tra una porta TCP o UDP sull’indirizzo IP esterno (VIP) ed una altra su quello interno (DIP).

In questo modo stiamo esponendo un servizio (nello specifico il Remote Desktop, che gira sulla porta TCP 3389) su una diversa porta all’esterno.
Se vi è venuto in mente il concetto di port forwarding su un NAT, avete capito perfettamente di cosa stiamo parlando. L’entità che fa questo lavoro su Azure però non è un NAT ma è un enorme Software Load Balancer.

Per fare un esempio:

	Virtual IP	Dedicated IP	Endpoints
VM 1	137.117.195.54	10.10.10.4	53083 (public) –> 3389 (private)
VM 2	137.117.195.54	10.20.20.5	34504 (public) –> 3389 (private)

Se mi volessi collegare in RDP verso la VM1, sarà sufficiente stabilire una connessione verso l’indirizzo 137.117.195.54 e la porta TCP 53083. A questo punto la nostra richiesta arriverà al Software Load Balancer di Azure. il SLB andrà a leggersi la tabella degli endpoints e saprà che dovrà inoltrare la richiesta verso la nostra VM all’indirizzo 10.10.10.4 sulla canonica porta 3389. A livello di sistema operativo guest su VM 1, Windows non ha la minima idea di quello che sta succedendo, riceve semplicemente una chiamata sul suo indirizzo privato e la sua porta 3389, e funziona. 
Allo stesso modo puntando alla porta 34504 sullo stesso indirizzo IP pubblico, arriveremmo a connetterci alla VM2, ma sempre sulla porta 3389 interna. 
Windows sulla macchina virtuale non sa nulla del load balancer e del VIP, che sono funzionalità esclusive della piattaforma Azure.

il Software Load Balancer su Azure si chiama in questo modo perchè abbiamo anche la possibilità di creare degli endpoint in modalità load balancing. Pensiamo ad esempio ad una batteria di Web Server su Azure: se esponiamo la porta per HTTP (TCP 80) con tanti endpoints bilanciati, le chiamate in accesso da parte dei client verranno re-indirizzate di volta in volta sui diversi server su Azure (tramite round robin).    
   

Possiamo quindi esporre all’esterno tutti i servizi che vogliamo, basterà semplicemente creare un endpoint per la relativa porta TCP o UDP. Tutto quello che non è esposto tramite un Endpoint non passerà mai alla VM ma verrà bloccato dal Load Balancer, quindi la sicurezza della nostra VM non è compromessa.

Attenzione: per questo motivo il traffico ICMP verrà sempre bloccato dal Load Balancer in quanto non è TCP nè UDP. Non sarà quindi mai possibile pingare una virtual machine dall’esterno (o viceversa), mentre internamente è tutto aperto quindi possiamo tranquillamente pingare tra due VM nello stesso cloud service.

Qualora volessimo effettuare dei test di connettività da Internet verso le nostre VM, non potremo usare il ping ma non c’è problema, basterà effettuare un test di connettività a livello TCP/UDP tramite tools quali Telnet, PortQry o PsPing (che consiglio a tutti per la sua semplicità, lo scaricate da qui http://technet.microsoft.com/en-us/sysinternals/jj729731.aspx )

Supportabilità

A causa delle limitazioni che abbiamo elencato in precedenza, alcuni ruoli/feature non possono funzionare su Windows Azure e non sono quindi supportati.

Tra questi i più noti a livello di networking sono il DHCP server (visto che tutte le VM devono prendere un indirizzo IP dal DHCP di Azure) e Network Load Balancing / Routing and Remote Access / Direct Access (a causa delle limitazioni di routing tramite il Software Load Balancer).

Per tutti gli altri vi rimando alla lista ufficiale, che vi ricordo potrebbe cambiare nelle future release del prodotto.

Microsoft server software support for Windows Azure Virtual Machines
http://support.microsoft.com/kb/2721672/en-us

Grazie a tutti e alla prossima!

Stefano Gagliardi
Sr. Support Engineer
Microsoft Enterprise Platform Support

Comments

• Anonymous
  January 01, 2003
  Quando sarà disponibile il supporto ICMP in outgoing dalle VM?
• Anonymous
  January 01, 2003
  thank you
• Anonymous
  January 01, 2003
  Ciao,Non ci sono piani per il momento per il supporto ICMP in outgoing dalle VM.Per cosa in particolare ha necessità di usare ICMP anzichè usare una connessione basata su TCP?StefanoWindows Support Team