Come creare un Data Center sicuro con Aruba Cloud Pro Un viaggio all'interno di Aruba Cloud Pro, la soluzione IaaS Cloud Computing di Aruba che consente di creare un'infrastruttura virtuale in modalità pay-per-use

How to create a secure virtualized Data Center on Aruba Cloud Pro

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.

DISCLAIMER: Questo sito non è affiliato con Aruba e non ha ricevuto contributi di qualsivoglia tipo per realizzare o pubblicare questo articolo: tutte le opinioni e le critiche espresse rappresentano unicamente il libero pensiero dell'autore.

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.

Dall’elenco di cui sopra si evince come, in ambiente Linux, tendo a favorire l’impiego di CentOS e NGINX rispetto ad alternative molto utilizzate come Ubuntu e Apache: il motivo di tale scelta, che ho provato a spiegare in alcuni articoli che ho scritto su CentOSNGINX nel corso degli ultimi anni, è principalmente legato ad alcune non trascurabili considerazioni di performance e sicurezza che mi hanno portato a prediligere l’utilizzo di questi sistemi.

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).

Come creare un Data Center sicuro con Aruba Cloud Pro

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.

Per ulteriori dettagli su questo aspetto specifico consiglio di consultare l’articolo seguente:

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.

Per ulteriori informazioni su come configurare un server OpenVPN su pfSense, consultare l’articolo seguente:

  • 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.

Per maggiori dettagli sul problema di cui sopra e sulle modalità di risoluzione consiglio di leggere il seguente articolo:

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!

 

 

 

About Ryan

IT Project Manager, Web Interface Architect e Lead Developer di numerosi siti e servizi web ad alto traffico in Italia e in Europa. Dal 2010 si occupa anche della progettazione di App e giochi per dispositivi Android, iOS e Mobile Phone per conto di numerose società italiane. Microsoft MVP for Development Technologies dal 2018.

View all posts by Ryan

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.