Archivi categoria: Microsoft Azure

Azure Saturday 2018 – Save the date!

Facebooktwittergoogle_plusredditlinkedin

I servizi cloud offerti dalla piattaforma Microsoft Azure sono in continua espansione, iniziano ad essere utilizzati con successo anche dalle aziende del nostro paese nonostante l’ostacolo della connessione. Globalmente, nel 2017, la velocità della rete internet è aumentata del 30% (vedi l’articolo sul blog di SpeedTest). In Italia, però, c’è ancora molto da fare, specialmente al di fuori dei capoluoghi.

Se vuoi migliorare la tua conoscenza sulla piattaforma di servizi cloud di Microsoft, Azure Saturday 2018 è l’evento che fa per te!

Azure Saturday 2018, organizzato da 1nn0va, si terrà sabato 6 ottobre 2018 nelle aule del Consorzio Universitario di Pordenone, le stesse che ospitano gli eventi della famiglia SQL Saturday! Avrete quindi già intuito che la famiglia degli eventi “Saturday” avrà nel 2018 un evento completamente dedicato a Microsoft Azure!

L’agenda dell’evento è pubblicata qui, si parlerà di Dev, IT Pro, DevOps, Data(science) e IoT, tre track erogheranno sessioni in parallelo per un totale di 18 ore di formazione gratuita su Azure.

Per effettuare la registrazione, puntate il vostro browser qui.

Non mancate!

OMS e System Center: novità di Luglio 2018

Facebooktwittergoogle_plusredditlinkedin

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. Come di consueto la nostra community rilascia questo riepilogo mensile che consente di avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre ulteriori approfondimenti.

Operations Management Suite (OMS)

Azure Log Analytics

La possibile integrazione di Azure Data Factory (ADF) con Azure Monitor consente di inviare le metriche di utilizzo verso Operations Management Suite (OMS). La nuova solution Azure Data Factory Analytics, disponibile nell’Azure marketplace, può fornire una panoramica sullo stato di salute del proprio Data Factory, consentendo di andare nel dettaglio delle informazioni raccolte. Questo può risultare molto utile in particolare per operazioni di troubleshooting. Risulta inoltre possibile collezionare le metriche provenienti da diverse data factories verso lo stesso workspace di OMS Log Analytics. Per i dettagli sulla configurazione necessaria per utilizzare questa solution, è possibile consultare la documentazione ufficiale.

Figura 1 – Overview della nuova solution Azure Data Factory Analytics

Nell’esecuzione delle query di Log Analytics è stata introdotta la possibilità di selezionare facilmente il workspace sul quale eseguire le interrogazioni:

Figura 2 – Selezione del workspace su cui effettuare le query di Log Analytics

La stessa possibilità è stata introdotta anche in Azure Application Insights Analytics. Tale funzionalità risulta utile in quanto in ogni query tab è possibile selezionare il workspace specifico, evitando di dover aprire Log Analytics in tab differenti del browser.

Nel caso vengano collezionati custom logs in Azure Log Analytics, è stata creata una categoria separata denominata “Custom Logs”, dove vengono raggruppati.

Figura 3 – Raggruppamento dei custom logs nella categoria specifica

 

Per i workspace di Log Analytics presenti nelle region di West Europe, East US, e West Central è stata annunciata la disponibilità in public preview dei Metric Alerts per i logs. I Metric alerts per i logs consentono di utilizzare i dati provenienti da Log Analytics come metriche di Azure Monitor. La tipologia dei log supportati è stata estesa e la lista completa è disponibile a questo indirizzo. Per ulteriori informazioni in merito è possibile consultare la documentazione ufficiale.

Azure Backup

In Azure Pricing Calculator, lo strumento ufficiale Microsoft per stimare i costi dei servizi Azure, è stata introdotta la possibilità di ottenere una stima più accurata dei costi di Azure Backup, consentendo di specificare il range di retention dei vari Recovery Point.

Figura 4 – Nuovi parametri per effettuare una stima più accurata dei costi di Azure Backup

Azure Site Recovery

Per Azure Site Recovery è stato rilasciato l’Update Rollup 26 che introduce nuove versioni per i seguenti componenti:

  • Microsoft Azure Site Recovery Unified Setup/Mobility agent (versione 9.17.4897.1): utilizzato per scenari di replica da VMware verso Azure.
  • Microsoft Azure Site Recovery Provider (versione 5.1.3400.0): utilizzato per scenari di replica da Hyper-V verso Azure oppure verso un secondary site.
  • Microsoft Azure Recovery Services agent (versione 2.0.9122.0): utilizzato per scenari di replica da Hyper-V verso Azure.

L’installazione di questo update rollup è consigliata in deployments dove sono presenti i componenti e le rispettive versioni in seguito riportate:

  • Unified Setup/Mobility agent versione 9.13.000.1 o successiva.
  • Site Recovery Provider versione 5.1.3000 o successiva.
  • Hyper-V Recovery Manager 3.4.486 o successiva.
  • Site Recovery Hyper-V Provider 4.6.660 o successiva.

Per ottenere maggiori informazioni sulle problematiche risolte, sugli improvements dati da questo Update Rollup e per ottenere la procedura da seguire per la relativa installazione è possibile consultare la KB specifica 4344054.

Azure Automation

Per quanto riguarda Azure Automation è stata introdotta la possibilità di configurare gli Hybrid Runbook Workers in modo che possano eseguire solamente runbook digitalmente firmati (l’esecuzione di runbook unsigned non andrà a buon fine). La procedura da seguire è riportata in questa sezione dell’articolo Microsoft.

System Center

In seguito al primo annuncio della Semi-Annual Channel release di System Center, avvenuto nel mese di febbraio con la versione 1801, questo mese è stata rilasciata la nuova update release, System Center 1807.

L’update release 1807 introduce nuove funzionalità per Virtual Machine Manager e Operations Manager, mentre per Data Protection Manager, Orchestrator e Service Manager contiene fix per problemi noti (includendo i bug fixes presenti nell’UR5 di System Center 2016, rilasciata in aprile).

Novità introdotte in Virtual Machine Manager 1807
  • Supports selection of CSV for placing a new VHD
  • Display of LLDP information for networking devices
  • Convert SET switch to logical switch
  • VMware host management: VMM 1807 supports VMware ESXi v6.5 servers in VMM fabric
  • Support for S2D cluster update
  • Support for SQL 2017
Novità introdotte in Operations Manager 1807
  • Configure APM component during agent install or repair
  • Linux log rotation
  • HTML5 Web console enhancements
  • Support for SQL Server 2017
  • Operations Manager and Service Manager console coexistence

Per maggiori informazioni a riguardo è possibile consultare la documentazione ufficiale Microsoft:

System Center 1807 è possibile scaricarlo dal System Center Evaluation Center.

Per tutti i prodotti System Center (DPM, SCORCH, SM, VMM e SCOM) è ora possibile aggiornare i deployment esistenti passando da SQL server 2016 a SQL server 2017.

Si ricorda infine che le release appartenenti al Semi-Annual Channel hanno un periodo di supporto di 18 mesi.

System Center Configuration Manager

Rilasciata la versione 1807 per il branch Technical Preview di System Center Configuration Manager. La novità principale presente in questo rilascio è l’introduzione del nuovo community hub, attraverso il quale è possibile condividere scripts, reports, configuration items ed altro, relativamente a Configuration Manager. Attraverso il community hub, accessibile dalla console di SCCM, è possibile introdurre nel proprio ambiente soluzioni messe a disposizione dalla community.

Tra le novità introdotte in questo rilascio troviamo inoltre:

  • Improvements to third-party software updates
  • Co-managed device activity sync from Intune
  • Approve application requests via email
  • Repair applications
  • Admin defined offline operating system image servicing drive
  • Improvements to run scripts

Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

Per poter configurare la connessione tra Operations Management Suite (OMS) e System center Operations Manager è necessario importare i seguenti nuovi management packs, specifici per versione:

Questa modifica ai MPs è stata resa necessaria per consentire la corretta comunicazione con le nuove APIs di OMS Log Analytics, introdotte in seguito allo spostamento verso il portale Azure di Log Analytics.

Figura 5 – Wizard di SCOM per l’onboarding di OMS

Si riporta la nuova wave dei management packs di System Center Operations Manager rilasciati per SQL Server, ora allineati alla versione 7.0.7.0:

Nel mese di Luglio sono inoltre stati rilasciati i seguenti Management Packs per software Open Source, versione 7.7.1129.0, che comprendono le seguenti novità:

Apache HTTP Server

  • Supports Apache HTTP Server version 2.2 and 2.4
  • Provides monitoring of busy and idle workers
  • Provides monitoring of resource usage – memory and CPU
  • Provides statistics for virtual hosts such as “Requests per Minute” and “Errors per Minute”
  • Provides alerting for SSL Certificate expiration

MySQL Server

  • Supports MySQL Server version 5.0, 5.1, 5.5, 5.6, and 5.7
  • Supports MariaDB Server version 5.5, and 10.0
  • Provides monitoring of databases
  • Provides monitoring of disk space usage for server and databases
  • Provides statistics for Key Cache, Query Cache, and Table Cache
  • Provides alerting for slow queries, failed connections, and full table scans

Sono stati inoltre rilasciati da parte di Microsoft i seguenti nuovi MPs:

  • MP per Active Directory Federation Services versione 0.2.0
  • MP per Active Directory Federation Services 2012 R2 versione 1.10172.1
  • MP per Microsoft Azure versione 5.20.18

Si segnala inoltre la nuova versione community (1807) del Management Pack di Azure, rilasciata da Daniele Grandini.

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center è possibile accedere all’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Implementare una VPN site-to-site in Azure con Veeam PN

Facebooktwittergoogle_plusredditlinkedin

Quando un’organizzazione decide di adottare servizi offerti da cloud pubblici si trova spesso a dover affrontare la sfida di interconnettere in modo sicuro e gestito utenti e servizi della propria rete con le risorse ospitate nel cloud.

Tipicamente, questo scenario implica mettere in conto i costi del servizio VPN offerto dal vendor del cloud pubblico e il dover configurare un appliance locale seguendo indicazioni e prescrizioni in termini di compatibilità legate a tale servizio.

Ad esempio, nel caso di Microsoft Azure, realizzare una VPN site-to-site prevede la disponibilità nella propria rete locale di un dispositivo VPN “convalidato” (vedi https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices).

Talvolta potrebbe essere necessario dover collegare una o più sedi della nostra organizzazione a virtual machine o applicazioni che abbiamo collocato su Azure non disponendo però del numero o del tipo di apparati necessari, oppure non essendo possibile alterare la configurazione di quelli esistenti…

In questo articolo vedremo come creare una VPN fra la rete locale aziendale e una subnet in Azure utilizzando il componente gratuito Veeam PN realizzato da Veeam Software (https://www.veeam.com).

Veeam Powered Network (PN)

Veeam PN è un tool di Software Defined Networking (basato su una distro Linux Ubuntu 16.04.1 LTS) che consente di creare in maniera molto semplice e lineare tunnel VPN fra reti aziendali (“site-to site”) o fra un client e la rete aziendale (“point-to-site”).

Si basa sulla tecnologia OpenVPN (https://openvpn.net/index.php/open-source/333-what-is-openvpn.html) la cui implementazione è semplificata da un’interfaccia web che permette di applicare intuitivamente configurazioni e politiche amministrative.

Si può scaricare, previa registrazione gratuita, da qui: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il download consiste in un file .ova di circa 1 Gb.

Nota: I file .ova sono “pacchetti” che contengono descrizioni e informazioni di certificazione relative ad una macchina virtuale (nel nostro caso l’appliance Veeam PN) che possono agilmente essere importate in ambiente VMware.

Come anticipato, Veeam PN può aiutarci (e possiamo dire che il tool sia nato proprio per questo scopo) nel creare connessioni protette verso nostre risorse collocate in Azure risolvendo il problema di dover modificare la configurazione di apparati VPN esistenti in conformità con le specifiche indicate da Microsoft:

  • VPN site-to-site, fra una o più sedi della nostra organizzazione ed una nostra subnet in Azure;
  • VPN point-to-site, fra uno o più client ed una nostra subnet in Azure.

Figura 1 – Scenari di implementazione di Veeam PN

Il ruolo svolto da Veeam PN, e quindi la relativa configurazione, dipende dalla collocazione nell’architettura:

  • Network Hub: gestisce il traffico fra la rete che offre i servizi e le reti o i client che devono accedervi in modo protetto; nel nostro schema il ruolo Network Hub di Veeam PN è collocato in Azure.
  • Site Gateway: stabilisce il tunnel VPN fra la rete che offre i servizi ed una rete remota; nel nostro schema, il ruolo Site Gateway è collocato on-premise.

Per consentire ad un singolo computer di accedere ad una rete gestita dal ruolo Network Hub, occorre installare sul PC Windows o Linux il client OpenVPN (https://openvpn.net/index.php/open-source/downloads.html). Per OS X e MacOS seguire le indicazioni riportate qui: https://openvpn.net/index.php/access-server/docs/admin-guides/183-how-to-connect-to-access-server-from-a-mac.html.

Requisiti di Veeam PN

Per installare l’appliance on-premise si raccomanda di utilizzare VMware vSphere versione 5.x o successive. La virtual machine dovrà disporre di almeno 1 CPU, 1GB di RAM e di un disco thin-provisioned di 4 GB. Per fare qualche sperimentazione è anche possibile utilizzare VMware Workstation o Virtual Box, ma non se ne raccomanda l’impiego in produzione.

Per installare l’appliance in Azure, dovremo prevedere una virtual machine almeno di dimensioni A1 (1 core, 1,75GB di RAM, 70 GB di spazio disco.

L’amministrazione di Veeam PN si effettua via browser: le versioni più recenti di Internet Explorer, Edge, Firefox, Chrome sono tutte supportate.

Informazioni sui requisiti e le indicazioni relative all’installazione del client OpenVPN sono disponibili qui: https://openvpn.net/index.php/open-source/documentation/install.html.

Porte utilizzate da Veeam PN:

Da Verso Protocollo Porta
Site Gateway Network Hub TCP/UDP 1194
Computer client Network Hub TCP/UDP 6179
Browser Network Hub o Site Gateway HTTPS 443

Installazione del ruolo Network Hub

Il primo ruolo di Veeam PN da installare è quello di Network Hub su Azure.

Una volta fatto accesso alla sottoscrizione Azure sulla quale abbiamo privilegi amministrativi, selezionare l’opzione Create a Resource e, nella casella di testo, digitare veeam pn, poi premere Invio.

Figura 2 – Create a Resource

Nei risultati della ricerca, fare clic su Veeam PN for Microsoft Azure.

Figura 3 – Veeam PN for Microsoft Azure, trovato!

Nella pagina successiva, fare clic su Create.

Figura 4 – Avvio creazione risorsa

Viene presentata la prima delle schede di configurazione della virtual machine che ospiterà il network appliance.

Fornire un nome per la virtual machine, un nome ed una password per l’account amministrativo, selezionare la sottoscrizione Azure in cui collocare la risorsa, decidere se utilizzare un Resource Group esistente (ma privo di risorse) o se crearne uno ad hoc e la regione Azure in cui desideriamo operare.

Infine, clic su OK.

Figura 5 – Informazioni di base

Nella scheda Veeam PN Settings:

  • Selezionare la dimensione della virtual machine: una Standard A1 può essere sufficiente per sperimentazioni o piccoli carichi di lavoro; in produzione si raccomanda di selezionare almeno una Dv2;
  • Specificare o creare uno Storage Account in cui verrà creato il disco della virtual machine;
  • Dare un nome univoco alla virtual machine;
  • Selezionare la Virtual Network a cui l’appliance sarà connesso (tipicamente la stessa Virtual Network in cui si trovano le risorse che dovranno essere raggiunte tramite VPN) e la relativa Subnet;
  • Fare clic su OK.

Figura 6 – Veeam PN Settings

Nella scheda successiva, Security Settings, selezionare la lunghezza della chiave di cifratura adottata per la generazione del canale sicuro e fare clic su OK.

Figura 7 – Security Settings

Nella scheda VPN Information è possibile selezionare le funzionalità con cui sarà configurato l’appliance Veeam PN e quindi stabilire se sarà possibile consentire connessioni site-to-site o point-to-site o entrambe. È anche possibile specificare protocolli e porte non di default. I valori predefiniti sono UDP 1194 per le connessioni site-to-site e UDP 6179 per le connessioni point-to-site.

Effettuate le scelte, fare clic su OK.

Figura 8 – VPN Information

Nella scheda Summary, dopo una verifica finale dei parametri impostati, è possibile fare clic su OK.

Figura 9 – Summary

Nella scheda successiva fare clic su Create.

Il processo di creazione delle risorse e della macchina virtuale dura pochi minuti.

Figura 10 – Fasi della creazione appliance Veeam PN

Configurazione del ruolo Network Hub

Al termine della creazione della macchina virtuale Veeam PN, è necessario effettuare alcune configurazioni preliminari.

Dal portale amministrativo di Azure, fare clic su Virtual Machines, poi sul nome della macchina virtuale Veeam PN appena creata per visualizzarne le proprietà.

Figura 11 – Indirizzo pubblico appliance

Annotare il Public IP Address (nel nostro caso 40.127.163.70), avviare un browser e connettersi via https.

Effettuare il login con le credenziali amministrative specificate al momento della creazione della virtual machine.

Figura 12 – Login

Nella scheda Azure Setup, fare clic su Next.

Figura 13 – Avvio wizard

Veeam PN richiede che ci si autentichi su Microsoft Azure Active Directory. Copiare il codice di autenticazione fornito e accedere al link indicato nella scheda.

Figura 14 – Codice di autenticazione (CTRL+C)

Incollare il codice nella casella di testo della pagina Web e, se il codice fornito risulta corretto, fare clic su Continua.

Figura 15 – Codice di autenticazione (CTRL+V)

Qualora richiesto, selezionare l’account corrente o specificarne uno diverso che abbia accesso alla sottoscrizione Azure.

Figura 16 – Conferma account

Tornare alla pagina di configurazione di Veeam PN e fare clic su Next.

Figura 17 – Il wizard prosegue

Al termine della configurazione automatica, fare clic su Finish.

Figura 18 – Azure setup completato

Configurazione dell’accesso dalla rete remota

È ora necessario consentire l’accesso al Veeam PN con il ruolo Network Hub da parte del Veeam PN con il ruolo Site Gateway che sarà installato e configurato successivamente.

Nella pagina principale del portale amministrativo di Veeam PN, fare clic su Clients.

Figura 19 – Portale amministrativo Veeam PN

Fare clic su Add.

Figura 20 – Aggiunta client

Nella scheda Add Client selezionare l’opzione Entire
Site e fare clic su Next.

Figura 21 – Opzione Entire Site

Specificare un nome identificativo e la subnet (nel formato CIDR) a cui appartengono gli host on-premise che dovranno connettersi ad Azure tramite VPN. Poi fare clic su Next.

Figura 22 – Informazioni sulla subnet on-premise

Nella scheda di riepilogo, fare clic su Finish.

Figura 23 – Completamento aggiunta client

Viene proposta la finestra di dialogo per il salvataggio del file (.xml) di configurazione che sarà poi necessario importare durante la configurazione del Veeam PN con il ruolo di Site Gateway.

Salvare il file in una posizione successivamente accessibile.

Nel portale amministrativo di Veeam PN è ora presente la rete che abbiamo appena definito come client.

Figura 24 – Conferma dell’aggiunta client

Installazione del ruolo Site Gateway

Passiamo ora a configurare Veeam PN on-premise per poter connettere con un tunnel VPN la rete aziendale ad Azure.

Collocare il pacchetto .ova scaricato dal sito Veeam (https://www.veeam.com/cloud-disaster-recovery-azure-download.html) in una posizione accessibile dall’ambiente VMware.

Per istruzioni dettagliate su come effettuare il deployment di un template OVA in ambiente vSphere: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html

Figura 25 – Package OVA caricato in vSphere

Qui https://spaces.uncc.edu/display/CKB/Importing+OVA+File+into+VMware+Workstation+14 una guida su come procedere utilizzando invece VMware Workstation (scenario consigliato unicamente nel caso di laboratori o sperimentazioni).

Completato il deployment del pacchetto .ova, dal client vSphere o dalla console di VMware Workstation, ricavare l’indirizzo IP dell’appliance Veeam PN (nel nostro caso 192.168.1.94) e accedervi via browser con le credenziali di default:

  • Utente: root
  • Password: VeeamPN

Figura 26 – Login al Veeam PN on-premise

Viene immediatamente richiesto di cambiare la password di default.

Figura 27 – Cambio password

Nella scheda successiva, Initial Configuration, è possibile scegliere il ruolo che dovrà svolgere questo appliance o se ripristinare la configurazione da un precedente backup.

Nel nostro caso, selezionare l’opzione Site gateway, poiché il ruolo Network Hub è stato precedentemente collocato su Azure, e fare clic su Next.

Figura 28 – Configurazione ruolo

Occorre ora effettuare l’upload del file .xml di configurazione generato durante la configurazione del ruolo Network Hub.

Fare clic su Browse e selezionare il file. Poi fare clic su Finish.

Figura 29 – Completamento configurazione

Dopo qualche secondo, nel portale amministrativo del Veeam PN on-premise viene segnalata l’effettuata connessione con il Veeam PN collocato su Azure.

Figura 30 – Conferma connessione lato on-premise…

Connettersi con il browser al Veeam PN su Azure e verificare che anche da quel lato gli indicatori siano “verdi”,

Figura 31 – …e conferma connessione lato Azure

Test della connessione VPN

Nello schema qui dis eguito, lo scenario oggetto della verifica: il client aziendale appartenente alla sede di Roma (indirizzo IP 192.168.1.246) deve potersi connettere tramite VPN al server AZRSRV01 collocato su Azure (indirizzo IP privato 10.1.0.4).

Figura 32 – Schema scenario da verificare

Nel portale amministrativo di Azure, fare clic su Virtual Machines, poi sulla macchina virtuale Veeam PN. Infine fare clic su Networking. Prendere nota dell’indirizzo IP privato (nel nostro caso 10.1.0.5).

Figura 33 – Rilevamento IP privato appliance Veeam PN su Azure

Accedere al client aziendale collocato nella rete on-premise, aprire una sessione Command Prompt con privilegi amministrativi elevati.

Eseguire il comando:

route -p add x.x.x.x mask y.y.y.y z.z.z.z

Dove:

  • x.x.x.x è l’indirizzo della subnet Azure a cui si desidera accedere
  • y.y.y.y è la relativa Subnet Mask
  • z.z.z.z è l’indirizzo IP del Veeam PN on-premise

Nel nostro caso:

route -p add 10.1.0.0 mask 255.225.255.0 192.168.1.94

Effettuare un tracert verso l’IP privato del Veeam PN su Azure.

Figura 34 – Tracert OK!

Vogliamo ora verificare di poter accedere anche al server collocato nella subnet Azure.

Il server ha come indirizzo privato 10.1.0.4 e non è raggiungibile (per regole di firewall) tramite il suo indirizzo IP pubblico.

Figura 35 – Rilevamento IP privato VM server su Azure

Proviamo ad accedere in RDP al server AZRSRV01 attraverso il suo IP privato 10.1.0.4.

Figura 36 – RDP OK!

WOW!

Instradamento automatico

Si noti che non è stato necessario modificare la routing table del server su Azure, grazie ad uan configurazione effettuata automaticamente dal Veeam PN con il ruolo Network Hub.

Accedere al portale amministrativo di Azure, fare clic su Resource Groups e poi sul nome del Resource Group in cui è stato collocato l’appliance Veeam PN.

Tra i vari elementi presenti, ne è elencato anche uno di tipo Route table.

Figura 37 – Route table creata da Veeam PN

Facendo clic su questo elemento si evidenza come sia stata automaticamente creata una route che inoltra attraverso l’host 10.1.0.5 (il Veeam PN) il traffico indirizzato verso la rete 192.168.1.0/24 (la subnet on-premise).

Tale route è applicata alla subnet su cui sono attestati sia l’appliance Veeam PN che il server AZRSRV01.

Figura 38 – Caratteristiche route table

Magia!

Conclusioni

In questo articolo abbiamo visto, passo per passo, come sia possibile, grazie ad un appliance gratuito realizzato da Veeam, realizzare una VPN site-to-site fra una sede aziendale e una subnet su Azure senza implicare modifiche agli apparati di networking esistenti o dover configurare un VPN Gateway su Azure.

Implementare Azure AD Domain Services

Facebooktwittergoogle_plusredditlinkedin

Gli Azure AD Domain Services permettono di poter aggiungere (joinare) macchine virtuali ad un dominio gestito senza la necessità di distribuire e manutenere i domain controller. Abilitando gli Azure AD Domain Services, verranno create in Azure due macchine virtuali che diventeranno i domain controller del dominio che vorrete creare. Queste due macchine saranno collegate ad una Azure Virtual Network (VNET) e sarà possibile aggiungere computer sia ospitati in macchine virtuali Azure sia ospitati on-premises, se la vostra rete virtuale è collegata in modalità Site-to-Site alla vostra infrastruttura aziendale. Per poter accedere alle applicazioni potrete utilizzare le vostre credenziali di Azure AD.

Sfruttando le funzionalità offerte, sarà possibile utilizzare LDAP, NTLM (NT LAN Manager) e l’autenticazione Kerberos, ampiamente usate nelle aziende, per eseguire la migrazione in Azure di applicazioni legacy compatibili con le directory.

Per abilitare le funzionalità di Azure AD Domain Services è necessario prima avere una directory di Azure AD (sincronizzata con una directory locale oppure solo cloud).

Una volta abilitata la funzionalità di Azure AD Domain Services sarà possibile eseguire i seguenti compiti amministrativi:

  • Aggiungere computer al dominio gestito.
  • Configurare le Group Policy per le unità organizzative (OU) “AADDC Computers” e “AADDC Users” nel dominio gestito.
  • Amministrare il DNS nel dominio gestito.
  • Creare e amministrare unità organizzative (OU) personalizzate nel dominio gestito.
  • Ottenere l’accesso amministrativo ai computer aggiunti al dominio gestito.

Privilegi amministrativi non disponibili in un dominio gestito

Il dominio viene gestito da Microsoft, incluse le attività quali applicazione di patch, monitoraggio ed esecuzione di backup. Il dominio è bloccato e non si hanno privilegi per eseguire alcune attività amministrative. Ecco alcuni esempi di attività che non è possibile eseguire:

  • Non vengono concessi privilegi di amministratore di dominio (Domain Admin) o amministratore dell’organizzazione (Enterprise Admin) per il dominio gestito.
  • Non è possibile estendere lo Schema del dominio gestito.
  • Non è possibile connettersi ai controller di dominio per il dominio gestito usando Desktop remoto.
  • Non è possibile aggiungere controller di dominio al dominio gestito.

Configurazione della directory di Azure

In questo articolo utilizzerò una directory di Azure che utilizza un dominio personalizzato chiamato “demolab.it”. Per aggiungere un dominio personalizzato alla vostra Azure Active Directory potete seguire le indicazioni contenute nell’articolo Aggiungere un nome di dominio personalizzato ad Azure Active Directory

Figura 1: Dominio personalizzato da utilizzare per gli Azure AD Domain Services

Poiché sto utilizzando un Directory esistente, ho anche alcuni gruppi ed alcuni utenti attivi. Agli utenti ho cambiato il logon name (username) in modo tale che utilizzino il dominio personalizzato “demolab.it”.

Figura 2: Utenti già esistenti in Azure AD

Abilitazione della funzionalità di Azure AD Domain Services

Dal portale di Azure scegliete di creare una nuova risorsa di tipo Azure AD Domain Services e scegliete quale sarà il DNS Domain Name che verrà utilizzato per creare il dominio gestito. Come già anticipato, io utilizzerò il dominio “demolab.it”. Indicate la sottoscrizione, il Resource Group e la Location dove creare le risorse.

Figura 3: Scelta del nome di dominio ce dovrà utilizzare Azure AD Domain Services

Nella schermata successiva scegliete a quale Virtual Network vorrete collegare i vostri Azure AD Domain Services ed il dominio gestito. Potete utilizzare una rete esistente oppure crearne una nuova. Nel mio caso ho deciso di creare una nuova rete virtuale.

Figura 4: Creazione di una nuova VNET da utilizzare con gli Azure AD Domain Services

Alla VNET verrà associato anche un Network Security Group, ottimizzato per proteggere gli Azure AD Domain Services.

Figura 5: Scelta della VNET e creazione di un Network Security Group associato

Nel passaggio successivo dovrete aggiungere gli utenti al gruppo AAD DC Administrators, uno speciale gruppo che avrà i privilegi nel dominio gestito che verrà creato. Questo gruppo verrà aggiunto al gruppo Administrators locale di tutte le macchine che verranno aggiunte al dominio gestito, come succede ai Domain Admins in Active Directory on-premises, e potranno connettersi in Desktop remoto alle macchine che verranno successivamente aggiunte (joinate) al dominio gestito.

NOTA: In un dominio gestito con Azure AD Domain Services non ci sono né Domain Admins né Enterprise Admins.

Figura 6: Aggiunta degli utenti al gruppo degli AAD DC Administrators

Controllate le configurazioni e cliccate su OK per completare la creazione degli Azure AD Domain Services. Ci vorranno circa 30 minuti per completare la creazione dei due domain controller.

Figura 7: Configurazione completata

Dopo circa 30 minuti sarà possibile verificare l’avvenuta creazione degli Azure AD Domain Services e sarà possibile aggiornare i DNS della vostra Virtual Network in modo tale che puntino agli indirizzi IP dei due domain controller creati per il dominio gestito. Cliccate su Configure e nel giro di pochi secondi la VNET verrà configurata automaticamente con i due IP da utilizzare per la risoluzione DNS.

Figura 8: Creazione completata e configurazione dei DNS

Infatti, se controllate le configurazioni della VNET vedrete che saranno stati modificati i server DNS.

Figura 9: Modifica dei server DNS della VNET compleltata

Nota: Durante il processo di provisioning, Azure AD Domain Services crea le applicazioni “Domain Controller Services” e “AzureActiveDirectoryDomainControllerServices” all’interno della directory dell’organizzazione. Queste applicazioni sono necessarie per far funzionare il dominio gestito ed è fondamentale che non vengono mai eliminate.

Figura 10: Applicazioni create per la gestione di Azure AD Domain Services

Connessione al dominio gestito

Per utilizzare il dominio gestito e per configurarlo è possibile creare una nuova VM e collegarla alla VNET utilizzata.

Figura 11: Creazione di una nuova VM per gestire Azure AD Domain Services

Terminata la creazione della VM potete collegarvi col le credenziali di amministratore locale che avete indicato al momento della creazione. Se controllate le configurazioni di rete della VM noterete che ha ottenuto i DNS corretti e quindi sarà capace di connettersi al dominio gestito “demolab.it”

Figura 12: La macchina virtuale ha ottenuto le configurazioni di rete corrette e può risolvere il nome del dominio gestito “demolab.it”

Per poter aggiungere la macchina al dominio gestito potete utilizzare le credenziali di un utente del gruppo AAD DC Administrators, come mostrato in figura:

Figura 13: aggiunta della VM al dominio gestito utilizzando le credenziali di un utente membro del gruppo AAD DC Administrators

Per autenticare gli utenti nel dominio gestito, Azure Active Directory Domain Services necessita dell’hash delle password in un formato idoneo per l’autenticazione NTLM e Kerberos. Azure AD non genera o archivia l’hash delle password nel formato necessario per l’autenticazione NTLM o Kerberos finché non si abilita Azure Active Directory Domain Services per il tenant. Per ovvi motivi di sicurezza, Azure AD non archivia nemmeno le credenziali di tipo password in un formato non crittografato. Azure AD quindi non può generare automaticamente questi hash delle password NTLM o Kerberos in base alle credenziali esistenti degli utenti.

Se avete configurato Azure AD per avere account utente solo cloud, tutti gli utenti che devono usare Azure Active Directory Domain Services devono cambiare le proprie password.

Se Azure Ad è sincronizzata con una directory on-premises (per mezzo di Azure AD Connect), è necessario abilitare la sincronizzazione degli hash NTLM e Kerberos per usare il dominio gestito. Fate riferimento all’articolo Abilitare la sincronizzazione password nel dominio gestito per gli account utente sincronizzati con l’istanza locale di AD per abilitare la sincronizzazione degli hash delle password.

Poiché l’utente che sto utilizzando per aggiungere la macchina virtuale al dominio gestito “demolab.it” era già presente in Azure AD (nel mio caso è solo Cloud) prima della creazione degli Azure AD Domain Services, non riesco a joinare la macchina al dominio gestito e ricevo un messaggio di errore (in realtà non chiarissimo).

Figura 14:Messaggio di errore dovuto alla mancanza di un hash delle password in formato corretto

Procedo quindi al cambiamento della password per l’utente admin@demolab.it, che avevo aggiunto al gruppo AAD DC Administrators. Il processo di modifica delle password determina la generazione in Azure AD degli hash delle password richiesti da Azure Active Directory Domain Services per l’autenticazione Kerberos e NTLM. È possibile impostare come scadute le password per tutti gli utenti del tenant che devono usare Azure Active Directory Domain Services oppure richiedere a tali utenti di cambiare le proprie password.

In questo caso mi sono collegato alla pagina https://mypass.microsoft.com e ho cambiato la password dell’utente admin@demolab.it, che stavo utilizzando per joinare la VM al dominio gestito.

Figura 15: Modifica della password dell’utente del gruppo AAD DC Administrators che stavo utilizzando per joinare la VM al dominio gestito

Dopo circa 20 minuti dalla modifica, la nuova password è utilizzabile in Azure Active Directory Domain Services. Ho riprovato ad aggiungere la VM al dominio gestito e questa volta non ho ricevuto nessun errore.

Figura 16: Dopo la modifica della password e l’attesa di qualche minuto, il join al dominio gestito avviene senza problemi

Gestione di Azure AD Domain Services

Adesso che avete aggiunto la VM al dominio gestito potete installare le console per la gestione. Io ho aggiunto la Group Policy Console, tutti gli AD DS Tools ed anche la console per la gestione del DNS.

Figura 17: Aggiunta degli strumento di amministrazione

Come si può vedere nelle schermate successive, è ora possibile amministrare il dominio gestito. Potete utilizzare la console Active Directory Users and Computers, L’Active Directory Administrative Center oppure AD PowerShell.

Figura 18: Console Active Directory Users and Computers e visualizzazione dei Domain Controllers del dominio gestito

Nella OU AADDC Users potrete vedere tutti gli utenti che avere creato in Azure AD (sia che siano solo cloud, sia che siano sincronizzati con Active Directory on-premises). Si può notare che i pulsanti di creazione dei nuovi utenti e dei nuovi gruppi non sono abilitati. La gestione degli utenti dovrà continuare ad essere effettuata da Azure AD.

Figura 19: Utenti del dominio gestito, gli stessi presenti in Azure AD

Per creare un nuovo utente o un nuovo gruppo dovete collegarvi al Portale di Azure e effettuare l’operazione dal nodo Azure Active Directory. Come già detto prima, siate pazienti perché ci vorranno circa 20 minuti per sincronizzare Azure AD con Azure AD Domain Services e per vedere il nuovo utente apparire nella console di Active Directory Users and Computers.

Figura 20: Utenti di Azure AD

Per amministrare il DNS potete invece collegarvi ad uno dei domain controller che sono stati creati nel dominio gestito (recuperate i nomi nella OU dei DC)), come mostrato in figura:

Figura 21: Console di gestione del DNS

È possibile utilizzare la console Group Policy Management nella macchina virtuale aggiunta al dominio per amministrare le Group Policy (GPO) nel dominio gestito, a patto che siate membri del gruppo AAD DC Administrators.

Sono presenti diverse GPO nel dominio gestito, tra cui la Default Domain Policy, AADDC Computers GPO e AADDC users GPO. È possibile personalizzare queste GPO o crearne delle altre. Io ho creato una nuova Organizational Unit (OU) e una nuova Group policy (GPO), come mostrato in figura:

Figura 22: Console di gestione delle GPO del dominio gestito

Conclusioni

Molto spesso in azienda si usano applicazioni che usano LDAP per l’accesso in lettura o scrittura alla directory aziendale oppure usano l’autenticazione integrata di Windows (autenticazione NTLM o Kerberos) per autenticare gli utenti finali. Per spostare le applicazioni locali nel cloud, è necessario risolvere le dipendenze da Active Directory. Spesso gli amministratori adottano una delle soluzioni seguenti:

  • Creano una connessione VPN da sito a sito tra Azure e l’infrastruttura on-premises.
  • Creano un domain controller aggiuntivo dell’Active Directory aziendale in una VM di Azure
  • Creano in Azure un dominio separato, utilizzando una o più VM promosse a domain controller

Tutti questi approcci tuttavia prevedono costi elevati e un carico di lavoro amministrativo significativo. Gli amministratori devono distribuire i controller di dominio tramite macchine virtuali in Azure. In più, devono gestire, proteggere, applicare patch, monitorare, eseguire il backup e risolvere i problemi relativi a tali macchine virtuali. L’utilizzo di connessioni VPN alla directory locale rende i carichi di lavoro distribuiti in Azure suscettibili a errori o interruzioni di rete temporanee.

Azure Active Directory Domain Services è pensata per offrire un’alternativa più semplice.

Utilizzare un server RADIUS per autenticare le connessioni VPN Point-to-Site verso le Azure Virtual Network

Facebooktwittergoogle_plusredditlinkedin

Le connessioni Point-to-Site (P2S) consentono ai computer client di potersi collegare alle reti virtuali in Azure (VNET) ed sono utili per tutti quei telelavoratori che quando sono a casa o sono in trasferta da un cliente hanno necessità di accedere alle risorse su Azure o alle risorse aziendali.

Per accedere anche alle risorse aziendali è necessario però che sia stata configurata anche una connessione Site-to-Site (S2S) tra la Azure VNet e la rete on-premises.

Figura 1: Schema di una connessione Point-to-Site

Gia in passato ho scritto la procedura per Creare una connessione Point to Site in Azure Resource Manager usando Powershell, anche se l’operazione è possibile effettuarla direttamente dal portale di Azure. Per l’autenticazione del client mi sono servito dei certificati digitali, che nonostante offrano un livello di sicurezza maggiore, sono più difficili da gestire.

Da qualche mese è però possibile utilizzare anche un server RADIUS per l’autenticazione degli utenti, a patto che utilizziate un Virtual Network Gateway di tipo VpnGw1, VpnGw2 o VpnGw3.

Quali SKU del gateway supportano la connessione VPN da punto a sito?

SKU Connessioni P2S Benchmark della velocità effettiva aggregata Autenticazione RADIUS VPN da punto a sito IKEv2
VpnGw1 128 650 Mbps Supportato Supportato
VpnGw2 128 1 Gbps Supportato Supportato
VpnGw3 128 1,25 Gbps Supportato Supportato
Basic 128 100 Mbps Non supportato Non supportato

Il server RADIUS potrà trovarsi nella stessa VNET di Azure, ospitato all’interno di una VM, oppure potrà essere contattato tramite una connessione Site-to-Site nella rete on-premises.

La modalità Point-to-Site (P2S) crea una connessione VPN tramite SSTP (Secure Sockets Tunneling Protocol) o IKEv2.

  • SSTP è un tunnel VPN basato su SSL supportato solo nelle piattaforme client Windows. Può penetrare i firewall e per questo è l’opzione ideale per connettersi ad Azure ovunque. Usa solo la porta 443
  • IKEv2 è una soluzione VPN IPsec basata su standard e può essere usato per connettersi da dispositivi Mac (versioni OSX 10.11 e successive). Usa la porta UDP 500 e 4500 e il protocollo IP 50. Molti proxy e firewall bloccano queste porte.

I client supportti sono:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows 10
  • Mac OS X version 10.11 (El Capitan)
  • Mac OS X version 10.12 (Sierra)
  • Linux (StrongSwan)
  • iOS

Per configurare il Virtual Network Gateway ad utilizzare il server RADIUS per l’autenticazione degli utenti vi basterà selezionare dal portale di Azure il Virtual Network Gateway e nel ramo Point-to-site configuration sarà possibile dichiarare, oltre all’Address Pool da utilizzare, anche quale server RADIUS dovrà essere contatatto per l’autenticazione e lo Shared Secret da utilizzare per connettersi al server RADIUS.

Figura 2: Configurazione della RADIUS Authentication

Per connettersi alla VNET in Azure attraverso al connessione Point-to-Site (P2S) gli utenti dovranno inserire le proprie credenziali di dominio (o credenziali di utenti locali del server RADIUS). È anche possibile integrare un server RADIUS con la Multi-facotr Authentication (MFA) in modo tale da aumentare il livello di sicurezza dell’accesso. Per la configurazione MFa vi rimando alla lettura dell’articolo Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication

Figura 3: Schema di funzionamento dell’autenticazione con server RADIUS on-premises

Configurazione del server RADIUS

Il server RADIUS che ho utilizzato è il Network Policy Server di Windows Server. La configurazione del ruolo è molto semplice e dura pochi secondi. Al termine dell’installazione sarà necessario configurare il server per accettare le connessioni VPN e per autenticarle. Dalla console del Network Policy Server potete effettuare il wizard per la creazione di una Configurazione Standard, come quella mostrata in figura:

Figura 4: Wizard per la creazione di una configurazione per una RADIUS server per le connessioni VPN

Scegliete di configurare una connessione VPN e date un nome alle policy che verranno configurate alla fine del wizard.

Figura 5: Scelta del tipo di connessione e del nome

Nel passaggio successivo inserite i RADIUS Client, cioè il vostro Azure Virtual Network Gateway. Inserite la Gateway Subnet che avete associato al momento della creazione del Gateway e lo Shared Secret che avete configurato nella Point-to-Site configuration.

Figura 6: Configurazione del RADIUS Client

Figura 7: RADIUS Client aggiunto

È possibile utilizzare due tipi di autenticazione con la connessione Point-to-Site (P2S): EAP-MSCHAPv2 ed EAP-TLS. In questo caso ho deciso di utilizzare EAP-MSCHAPv2 e l’ho aggiunto nella pagina degli Authentication Methods, come mostrato in ffigura:

Figura 8: Aggiunta di EAP-MSCHAPv2 agli Authentication Methods

Selezionate il gruppo di utenti che potranno autenticarsi e procedete con il wizard. Io ho creato un gruppo dedicato che possa connettersi alla VNET tramite P2S.

Figura 9: Scelta del gruppo di utenti autorizzati ad autenticarsi tramite VPN

Lasciate invariate le altre configurazioni

Figura 10: Packet filtering per limitare il tipo di traffico

Figura 11: Encryption settings

Figura 12: Realm name

Completate la configurazione facendo clic su Finish.

Figura 13: Configurazione del server RADIUS completata

Download del client di connessione Point-to-Site

Terminata la configurazione del server RADIUS dovete soltanto provare a connettervi. Collegatevi al portale Azure e scaricate il client di connessione, come mostrato in figura, scegliendo anche il protocollo di autenticazione che volete utilizzare. Io ho scelto EAP-MSCHAPv2.

Figura 14: Download del client di connessione P2S

Verrà scaricato un file .zip all’interno del quale troverete gli installer per Windows 32 e 64 bit e per Mac OSx. Procedete all’installazione della connessione per il tipo di sistema operativo che state utilizzando.

Figura 15: Installazione della configurazione del client VPN per la P2S

Terminata la configurazione sarà possibile lanciare la connessione VPN P2S, inserendo le credenziali di un utente che appartenga al gruppo che avete autorizzato nel server RADIUS.

Figura 16: Connessione P2S alla VNET con le credenziali di dominio o locali del server RADIUS

Se volete personalizzare la configurazione del client e se volete aggiungere delle rotte alla connessione VPN (per esempio per raggiungere anche la rete on-premises) vi invito a leggere l’articolo Personalizzare il client di una connessione Point to Site su Azure

Conclusioni

Utilizzare un server RADIUS per autenticare i nostri utenti quando effettuano una connessione Point-to-Site è decisamente facile e vantaggioso, perché sfrutta le credenziali di dominio dell’utente e si può integrare con la Multi-Factor Authentication.

Azure Application Gateway: come monitorarlo con Log Analytics

Facebooktwittergoogle_plusredditlinkedin

L’Azure Application Gateway è un load balancer applicativo (OSI layer 7) per il traffico web, disponibile in ambiente Azure, che consente di gestire il traffico HTTP e HTTPS delle applicazioni. In questo articolo verrà approfondito come effettuare il monitor degli Azure Application Gateway utilizzando Log Anaytics.

Figura 1 – Schema di base dell’Azure Application Gateway

Utilizzando l’Azure Application Gateway è possibile usufruire delle seguenti funzionalità:

  • Routing basato su URL
  • Redirection
  • Multiple-site hosting
  • Session affinity
  • Secure Sockets Layer (SSL) termination
  • Web application firewall (WAF)
  • Supporto nativo per i protocolli WebSocket e HTTP/2

Per maggiori dettagli sugli Azure Application Gateway è possibile consultare la documentazione ufficiale Microsoft.

Configurazione Diagnostics logs dell’Application Gateway

L’Azure Application Gateway prevede l’invio dei log di diagnostica verso un workspace di Log Analytics. Questa funzionalità è molto utile per controllare le performance, per rilevare eventuali errori ed è   fondamentale per operazioni di troubleshooting, in particolare in presenza del modulo WAF.  Per abilitare la diagnostica dal portale Azure è possibile selezionare la risorsa Application Gateway specifica ed accedere alla sezione “Diagnostics logs”:

Figura 2 –  Avvio della configurazione dei Diagnostics logs
Figura 3 – Configurazione dei Diagnostics logs

Dopo aver scelto il workspace di Log Analytics dove inviare i dati di diagnostica, nella sezione Log, è possibile selezionare quale tipologia di Log collezionare tra i seguenti:

  • Access log (ApplicationGatewayAccessLog)
  • Performance log (ApplicationGatewayPerformanceLog)
  • Firewall log (ApplicationGatewayFirewallLog): questi log vengono generati solo se il Web Application Firewall è configurato sull’Application Gateway.

Oltre a questi log sono inoltre collezionati di default gli Activity Log generati da Azure. Questi log vengono mantenuti per 90 giorni nello store dell’Azure event logs. Per maggiori dettagli è possibile consultare questo documento specifico.

Solution Azure Application Gateway analytics di Log Analytics

Microsoft mette a disposizione la solution Azure Application Gateway analytics che può essere aggiunta al workspace di Log Analytics seguendo questi semplici step:

Figura 4 – Avvio della procedura di aggiunta della solution al workspace OMS
Figura 5 – Selezione della solution Azure Application Gateway analytics
Figura 6 – Aggiunta della solution nel workspace selezionato

Dopo aver abilitato l’invio dei log di diagnostica verso il workspace di Log Analytics ed aver aggiunto sullo stesso la solution, selezionando il tile Azure Application Gateway analytics presente nella pagina di Overview, si potrà visualizzare una overview dei dati di log raccolti dall’Application Gateway:

Figura 7 – Schermata di overview della solution Azure Application Gateway analytics

Sarà inoltre possibile consultare i dettagli per le seguenti categorie.

  • Application Gateway Access logs:
    • Client and server errors for Application Gateway access logs
    • Requests per hour for each Application Gateway
    • Failed requests per hour for each Application Gateway
    • Errors by user agent for Application Gateways
Figura 8 – Schermata degli Application Gateway Access logs
  • Application Gateway performance:
    • Host health for Application Gateway
    • Maximum and 95th percentile for Application Gateway failed requests
Figura 9 – Schermata delle performance degli Application Gateway

Dashboard personalizzata di Log Analytics per il monitor dell’Application Gateway

Oltre a questa solution può essere conveniente utilizzare anche una apposita dashboard di Log Analytics, specifica per il monitoring dell’Application Gateway, reperibile a questo indirizzo. Il deploy della dashboard avviene tramite template ARM e richiede anche in questo caso l’abilitazione dei Diagnostics logs dell’Application Gateway, come descritto precedentemente. Le varie query di Log Analytics, utilizzate dalla dashboard, sono documentate in questo blog. Grazie a queste query la dashboard riporta diverse informazioni aggiuntive esposte dalla diagnostica dell’Application Gateway.

Figura 10 – Dashboard custom di Log Analytics per il monitor dell’Application Gateway

Query di Log Analytics per monitorare i Firewall Log

Utilizzando la solution Azure Application Gateway analytics di Log Analytics oppure la dashboard custom (riportata nel paragrafo precedente) non sono al momento contemplati i Firewall log, generati quando risulta attivo il Web Application Firewall (WAF) sull’Application Gateway. Il WAF si basa sulle regole di OWASP Core Rule Set 3.0 o 2.2.9 per intercettare gli attacchi, alle applicazioni Web, che sfruttano le più note vulnerabilità. Per citarne alcune, troviamo ad esempio gli attacchi SQL injection e gli attacchi cross site scripting.

In questo caso, qualora si decida di verificare i Firewall log, è necessario eseguire direttamente delle query di Log Analytics, come ad esempio:

Figura 11 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI, suddivise per RuleId

Per consultare la lista delle regole del WAF, associando il RuleId alla relativa description, è possibile consultare questo documento.

Il messaggio descrittivo della rule viene riportato anche all’interno dei risultati restituiti dalla query:

Figura 12 – Query di LA per recuperare le richieste bloccate dal modulo WAF, negli ultimi 7 giorni, per uno specifico URI e per specifica RuleId

Conclusioni

Secondo la mia esperienza, nelle architetture Azure che richiedono la pubblicazione sicura di servizi Web verso internet, è spesso utilizzato il servizio Azure Application Gateway con il modulo WAF attivo. Grazie alla possibilità di inviare i log di diagnostica di questo componente verso Log Analytics si ha la possibilità di avere un monitor completo, che risulta fondamentale per analizzare eventuali condizioni di errore e per valutare lo stato del componete in tutte le sue sfaccettature.

Microsoft Azure: panoramica delle soluzioni di monitoring per la rete

Facebooktwittergoogle_plusredditlinkedin

In Microsoft Azure sono disponibili diverse soluzioni che consentono di monitorare le risorse di rete, non solo per ambienti cloud, ma anche in presenza di architetture ibride. Si tratta di funzionalità cloud-based, orientate a controllare lo stato di salute della rete e la connettività verso le proprie applicazioni. Inoltre, sono in grado di fornire informazioni dettagliate sulle performance di rete. In questo articolo verrà effettuata una panoramica delle diverse soluzioni riportandone le caratteristiche principali, necessarie per orientarsi nell’utilizzo degli strumenti di monitor della rete più opportuni per le proprie esigenze.

Network Performance Monitor (NPM) è una suite che comprende le seguenti soluzioni:

  • Performance Monitor
  • ExpressRoute Monitor
  • Service Endpoint Monitor

Oltre agli strumenti inclusi in Network Performance Monitor (NPM) è possibile utilizzare Traffic Analytics e DNS Analytics.

Performance Monitor

L’approccio sempre più frequentemente utilizzato è quello di avere ambienti ibridi con un networking eterogeneo, che consente di mettere in comunicazione la propria infrastruttura on-premises con l’ambiente implementato nel cloud pubblico. In alcuni casi si potrebbe disporre anche di differenti cloud provider, che rendono ancor più complicata l’infrastruttura di rete. Questi scenari richiedono pertanto l’utilizzo di strumenti di monitor flessibili e che possano lavorare in modo trasversale on-premises, in cloud (IaaS), e in ambienti ibridi. Performance Monitor ha tutte queste caratteristiche e grazie all’utilizzo di transazioni sintetiche, fornisce la possibilità di monitorare, pressoché in tempo reale, i parametri di rete per avere le informazioni relative alle performance, come la perdita di pacchetti e la latenza. Inoltre, questa soluzione consente di localizzare facilmente la sorgente di una problematica in uno specifico segmento di rete o identificando un determinato dispositivo. La soluzione richiede la presenza dell’agente di OMS e tenendo traccia dei pacchetti di retransmission e del tempo di roundtrip, è in grado di restituire un grafico di facile e immediata interpretazione.

Figura 1 – Diagramma Hop-by-hop fornito da Performance Monitor
Dove installare gli agenti

L’installazione dell’agente di Operations Management Suite (OMS) è necessario farla su almeno un nodo connesso a ogni sottorete dalla quale si intende monitorare la connettività verso altre sottoreti. Nel caso si intenda monitorare uno specifico link di rete è necessario installare gli agenti su entrambe gli endpoint del link. Nei casi dove non si è a conoscenza della topologia esatta di rete, un possibile approccio è quello di installare gli agenti su tutti i server che detengono workload particolarmente critici e per i quali è necessario monitorare le performance di rete.

Costo della soluzione

Il costo della funzionalità Performance Monitor in NPM è calcolato sulla base della combinazione di questi due elementi:

  • Subnet link monitorati. Per ottenere i costi per il monitoring di un singolo subnet link per un mese, è possibile consultare la sezione Ping Mesh.
  • Volume di dati.

Per maggiori dettagli a riguardo è possibile consultare la pagina ufficiale Microsoft.

ExpressRoute Monitor

Utilizzando ExpressRoute Monitor è possibile effettuare il monitor della connettività end-to-end e verificare le performance tra l’ambiente on-premises ed Azure, in presenza di connettività ExpressRoute con connessioni Azure Private peering e Microsoft peering. Le funzionalità chiave di questa soluzione sono:

  • Auto-detection dei circuit ExpressRoute associati alla propria subscription Azure.
  • Detection della topologia di rete.
  • Capacity planning e analisi dell’utilizzo di banda.
  • Monitoring e alerting sia per il primary che per il secondary path dei circuit ExpressRoute.
  • Monitoring sulla connettività verso i servizi Azure come Office 365, Dynamics 365 che utilizzano ExpressRoute come connettività.
  • Rilevamento di eventuali degradi della connettività verso le varie virtual network.
Figura 2 – Topology view di una VM su Azure (sinistra) connessa a una VM on-prem (destra), tramite connessione ExpressRoute
Figura 3 – Trend sull’utilizzo della banda e sulla latenza riscontrata sul circuit ExpressRoute
Dove installare gli agenti

Per poter utilizzare ExpressRoute Monitor è necessario installare almeno un agente di Operations Management Suite su un sistema che risiede sulla virtual network di Azure e almeno un agente su una macchina attestata sulla sottorete nell’ambiente on-premises, connessa tramite private peering di ExpressRoute.

Costo della soluzione

Il costo della soluzione ExpressRoute Monitor è calcolato in base al volume dei dati generato durante le operazioni di monitoring. Per maggiori dettagli è possibile consultare la sezione dedicata nella pagina dei costi di NPM.

Service Endpoint Monitor

Utilizzando questa soluzione si ha la possibilità di monitorare e testare la raggiungibilità dei propri servizi e delle proprie applicazioni, pressoché in tempo reale, simulando gli accessi degli utenti. Si ha inoltre la possibilità di rilevare problemi nelle prestazioni lato network e di individuare il segmento di rete problematico.

Si riportano le funzionalità principali della soluzione:

  • Effettua il monitor end-to-end delle connessioni di rete verso le proprie applicazioni. Il monitor può essere fatto di qualsiasi endpoint “TCP-capable” (HTTP, HTTPS, TCP, e ICMP), come websites, applicazioni SaaS, applicazioni PaaS, e database SQL.
  • Correla la disponibilità delle applicazioni con le performance della network, per localizzare con precisione il punto di degrado sulla rete, partendo dalla richiesta dell’utente fino al raggiungimento dell’applicativo.
  • Testa la raggiungibilità delle applicazioni da differenti location geografiche.
  • Determina le latenze di rete e i pacchetti persi per raggiungere le proprie applicazioni.
  • Rileva hot spots sulla rete che possono causare problemi di performance.
  • Effettua il monitor della raggiungibilità di applicazioni Office 365, tramite test built-in specifici per Microsoft Office 365, Dynamics 365, Skype for Business e altri servizi Microsoft.
Figura 4 – Creazione di un Service Connectivity Monitor test
Figura 5 – Diagramma che mostra la topology di rete, generata da diversi nodi, per raggiungere un Service Endpoint
Dove installare gli agenti

Per utilizzare Service Endpoint Monitor è necessario installare l’agente di Operations Management Suite su ogni nodo da cui si vuole monitorare la connettività di rete verso uno specifico service endpoint.

Costo della soluzione

Il costo per l’utilizzo di Service Endpoint Monitor è basato su questi due elementi:

  • Numero delle connessioni, dove la connessione è intesa come test di raggiungibilità di un singolo endpoint, da un singolo agente, per l’intero mese. A questo proposito è possibile consultare la sezione Connection Monitoring nella pagina dei costi.
  • Volume di dati generato dall’attività di monitor. Il costo lo si ricava dalla pagina dei costi di Log Analytics, nella sezione Data Ingestion.

Traffic Analytics

Traffic Analytics è una soluzione totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.
  • Analisi delle capacità dei gateway VPN o di altri servizi, per rilevare problemi generati da over-provisioning o sottoutilizzo.
Figura 6 – Traffic Analytics overview
Figura 7 – Map delle Region Azure attive sulla subscription

DNS Analytics

La soluzione DNS Analytics è in grado di collezionare, analizzare e correlare i log del servizio DNS e mette a disposizione degli amministratori le seguenti funzionalità:

  • Indentifica i client che tentano di risolvere domini ritenuti malevoli.
  • Rileva i record appartenenti a risorse obsolete.
  • Mette in evidenza nomi di dominio frequentemente interrogati.
  • Mostra il carico delle richieste ricevute dai server DNS.
  • Effettua il monitor delle registrazioni dinamiche sul DNS fallite.
Figura 8 – Overview della solution DNS Analytics
Dove installare gli agenti

La soluzione richiede la presenza dell’agente di OMS oppure di Operations Manager installato su ogni server DNS che si intende monitorare.

Conclusioni

All’aumentare della complessità delle architetture network in ambienti ibridi, aumenta di conseguenza la necessità di potersi avvalere di strumenti in grado di contemplare differenti topologie di rete. Azure mette a disposizione diversi strumenti cloud based e integrati nella fabric, come quelli descritti in questo articolo, che consentono di monitorare in modo completo ed efficace il networking di questi ambienti. Ricordo che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.