Indice dei contenuti
Questo articolo è il primo di una serie di post nei quali racconterò la mia esperienza con Aruba Cloud Pro, la soluzione IaaS messa a disposizione da Aruba per creare Data Center di macchine virtuali con un pricing model pay-per-use e una serie di funzionalità interessanti.
A scanso di equivoci, è bene chiarire subito che non si tratta di un servizio che può competere con soluzioni oggettivamente più complete come Google Cloud Platform, Amazon AWS o MS Azure, anche se l'obiettivo che si propone l'azienda italiana è per certi aspetti simile a quello dei "cugini grandi": mettere a disposizione un ecosistema di servizi cloud-based integrabili tra loro, espandibili o riducibili secondo necessità, attraverso un'interfaccia di gestione interamente accessibile tramite il web.
Nello specifico, il parco prodotti prevede:
- Cloud Server, ovvero delle Macchine Virtuali create all'interno di una serie di cluster (in tecnologia VMware o Hyper-V) che implementano meccanismi di ridondanza.
- Virtual Switch, degli apparati virtuali che possono essere utilizzati per creare reti private tra i vari server.
- IP Pubblici, per garantire l'accesso dall'esterno.
- Unified Storage, una sorta di contenitori di spazio condiviso per i Cloud Server.
- Bilanciatori, che consentono di distribuire il carico di lavoro bilanciandolo tra due o più Cloud Server (identici per configurazione e per dati contenuti).
Vi sono poi una serie di servizi accessori che possono essere utilizzati a corredo dei prodotti sopra elencati, tra cui: backup bare-metal, template predefiniti, accesso FTP per caricare dischi virtuali personalizzati e/o esportare quelli delle macchine virtuali create, etc.
Infrastruttura
I servizi a disposizione di Aruba Cloud mi hanno consentito di costruire un Data Center basato su una tipica architettura edge-origin con le seguenti caratteristiche:
- 1 Firewall e VPN Server basato su pfSense (uno dei due firewall template messi a disposizione da Aruba Cloud: l'altro è Endian)
- 1 Reverse Proxy NGINX su una macchina virtuale Linux CentOS 7.x
- 1 Web Server IIS su una macchina virtuale Windows Server 2016
- 1 Database SQL Server su una seconda macchina virtuale Windows Server 2016
- 1 Web Server NGINX su un'altra macchina virtuale Linux CentOS 7.x
- 1 Database MariaDB su una terza macchina virtuale Linux CentOS 7.x
Come si può vedere, stiamo parlando di un classico ambiente ibrido Windows + Linux, soluzione che tendo ad adottare spesso (e a suggerire ai miei clienti) perché consente di avere a disposizione il meglio di entrambi i mondi: applicazioni web basate su ASP.NET 2.x & 4x su Windows, servizi LAMP / LEMP / MEAN su Linux, nonché progetti .NET Core da pubblicare su Windows o Linux a seconda della disponibilità dei pacchetti esterni sulle singole architetture.
Networking
La configurazione predefinita di Aruba Cloud prevede un IP pubblico e una scheda di rete direttamente connessa a internet per ogni virtual server.
Per ovvie ragioni di sicurezza ho preferito abbandonare questo approccio in favore di una configurazione basata su due reti distinte: una WAN con accesso a internet in ingresso e in uscita, accessibile soltanto dal firewall pfSense, e una LAN privata da utilizzare per consentire ai server di comunicare tra loro e condividere le risorse di rete.
L'implementazione di una LAN interna su Aruba Cloud è stata in realtà piuttosto semplice grazie all'acquisto e all'utilizzo di un Virtual Switch, che serve proprio ad assolvere a questo scopo; tutto quello che ho dovuto fare è stato configurare la rete LAN su pfSense e attivare la funzionalità DHCP server, così da poter gestire l'intera subnet (cfr screenshot qui sotto).
Ho quindi impostato un outbound NAT tra la LAN e la WAN, così da consentire a ciascun server di poter accedere a internet in uscita restando nel contempo protetto dalle connessioni in ingresso.
Connessioni tramite VPN
Una volta completata la configurazione delle reti, ho utilizzato le funzionalità offerte da pfSense per impostare una VPN sicura così da consentire agli amministratori di sistema di poter accedere in modalità protetta alla LAN privata e connettersi ai server tramite Remote Desktop, VNC, SSH e tecnologie similari.
Per implementare la VPN ho scelto il protocollo OpenVPN, probabilmente ad oggi il più sicuro tra quelli messi a disposizione da pfSense, con una configurazione predisposta per la modalità client-server. La configurazione dei client avviene in modo estremamente semplice, visto che pfSense consente di scaricare gli script di configurazione per ciascun utente, che consentono di configurare automaticamente il client, nonché addirittura - per i meno esperti - un file installer personalizzato comprensivo dell'OpenVPN Client e di tutte le impostazioni necessarie per effettuare la connessione. Ovviamente né lo script né il file installer autogenerati da pfSense contengono le credenziali utente, indispensabili per effettuare la connessione.
- pfSense - Configurazione VPN con OpenVPN
Problemi e contrattempi
Nonostante si sia trattato di una configurazione piuttosto facile non sono mancati alcuni contrattempi, più che altro legati ad alcune problematiche specifiche dei vari sistemi utilizzati. In questo paragrafo ho cercato di riassumere le principali, nella speranza che le soluzioni che ho trovato per risolverle possano aiutare anche altri amministratori di sistema.
Condivisione di File e Cartelle
Tra le varie cose che avevo necessità di configurare nei server virtuali basati su OS Windows vi era la condivisione del file system tramite la LAN interna, in modo che i server e gli utenti VPN (gli amministratori di sistema) potessero accedere alle cartelle condivise utilizzando il File Explorer di Windows. Per attivare questa funzionalità ho dovuto procedere nel seguente modo:
- Condividere le cartelle tra i vari Windows Server, abilitando la funzionalità File and Printer Sharing (condivisione file e stampanti) sulle rispettive schede di rete.
- Aggiungere le necessarie regole Firewall su pfSense così da consentire il traffico di rete tra le interfacce LAN e OpenVPN interne all'infrastruttura Cloud.
- Aprire le porte dedicate al file sharing (135-139 e 445 TCP e UDP) sui Windows Firewall dei rispettivi server, attività che può essere compiuta con un paio di click abilitando le regole Condivisione File e Stampanti (SMB-In) e Condivisione File e Stampanti su SMBDirect (iWARP-In), entrambe già presenti all'interno del Windows Firewall e disabilitate per impostazione predefinita.
Questi passaggi mi erano inizialmente sembrati sufficienti... o almeno questo era ciò che pensavo, fino a quando non mi sono imbattuto in un problema ulteriore tentando di accedere a una delle cartelle condivise così impostate:
An error occurred while connecting to address \\<LAN-IP>\<SHARED-FOLDER>\.
The operation being requested was not performed because the user has not been authenticated.
You can't access this shared folder because your organization's security policies block unauthenticated guest access. These policies help protect your PC from unsafe or malicious devices on the network.
Gli errori di cui sopra mi si sono presentati su due diverse macchine Windows: in entrambi i casi, benché il messaggio sembrasse relativo a un problema diverso, la connessione alla cartella condivisa non era effettuata.
Questa difficoltà di accesso, apparentemente banale, ha richiesto parecchio tempo per essere risolto; il secondo messaggio mi ha aiutato molto a capire dove fosse effettivamente il problema poiché mi ha spinto a controllare in modo più approfondito le policy di gruppo locale (local group policies) di Windows. Per farla breve, il problema era legato alla configurazione predefinita dell'account Guest di Windows, al quale l'accesso alla rete è bloccato per impostazione predefinita.
Conclusioni
Per il momento è tutto: ci auguriamo che questo post possa aiutare altri amministratori di sistema a valutare i pro e contro legati all'utilizzo di Aruba Cloud Pro per creare la propria infrastruttura Cloud in modalità IaaS rispetto ad alternative più note e complete, ma anche decisamente più costose, come MS Azure, Amazon AWS e Google Cloud Platform. Alla prossima!
