Cos'è una rete virtuale azzurra? La maggior parte delle persone sente questo termine e pensa sia solo un'impostazione da attivare quando si distribuisce. Una macchina virtuale è qualcosa da spuntare e dimenticare, ma la verità è un'altra. Una rete virtuale azzurra non è solo un'impostazione, è il fondamento di tutto ciò che costruisci in azzurra. Ogni macchina virtuale, ogni database, ogni servizio app, ogni funzione che distribuisci risiedono tutti al suo interno. Se non capisci come funziona, non stai procedendo alla cieca. Alla fine di questo episodio capirai cosa sia realmente una v-net, come funzioni e perché ogni singola risorsa che distribuisci dipende da essa. Tratteremo cos'è una v-net, come funzionano gli indirizzi IP, le subnet, la sicurezza e il routing e come connette le v-net tra loro. Prendi il tuo caffè e iniziamo. Cos'è una v-net? La rete cloud privata. Partiamo dalla definizione più semplice. Una rete virtuale azzurra o v-net in breve è la tua rete privata all'interno di azzurra. Tensala come un edificio privato. Solo le persone che autorizzi possono entrare. Controlli chi entra dalla porta, chi arriva a quale piano e chi resta completamente fuori. Prima dell'esistenza delle v-net le cose erano diverse. Distribuisci una macchina virtuale nel cloud ed era praticamente esposta a internet per impostazione predefinita. Nessuna rete privata attorno ad essa. Chiunque conoscesse gli indirizzi IP poteva provare a connette. Era un incubo per la sicurezza. Cos'è cambiato? Azzurra ti ha dato la possibilità di creare spazi di rete privati isolati. Definisci un confine. Decidi cosa inserire al suo interno. Nulla al di fuori di quel confine può entrare a meno che tu non lo permetta esplicitamente. Una cosa da sapere subito è che la tua v-net vive in una specifica area geografica di Azzurra. Non è globale. Crea una v-net in Europa occidentale e lì rimane. Le risorse in un'altra area non possono semplicemente inserirsi. Avrebbero connetterli in seguito. Quando crea una v-net definisci tu stesso lo spazio degli indirizzi IP.

Azzurra non lo sceglie per te. Decidi tu l'intervallo di indirizzi IP che le tue risorse utilizzeranno. È una grande responsabilità e parleremo di come farlo correttamente nella prossima sezione. Ecco il punto chiave. Le v-net sono le fondamenta. Ogni macchina virtuale, ogni database, ogni funzione Azure che distribuisci risiede al loro interno. Senza una v-net le tue risorse non hanno alcun contesto di rete privata. Fluttuano semplicemente nel cloud senza confini, isolamento o sicurezza. Quindi cosa significa questo per te? Se stai creando qualcosa in Azure parti prima da una v-net, non dopo aver distribuito le tue risorse, prima? La tua v-net è il terreno su cui stai costruendo. Non costruiresti una casa senza aver prima comprato il terreno, giusto? Stessa idea. Indirizzamento IP e CDR è scegliere il proprio spazio di indirizzamento. Quindi tuffiamoci. Quando crea una v-net la prima grande decisione è scegliere un intervallo IP. Lo fai usando la notazione CDR. CDR sta per Classless Interdomain Routing, ma in realtà significa solo dire ho bisogno di questo numero di indirizzi IP. Perché è importante? Perché l'intervallo che scegli determina quante risorse puoi inserire nella tua rete virtuale. Ecco come funziona. Il CDR usa una barra o numero come 16 o 24. Quel numero ti indica la dimensione dello spazio di indirizzamento. Un 16 ti offre circa 65 mila indirizzi IP. Sono molti. Un 24 te ne offre circa 250 e che è perfetto per un piccolo team o un singolo livello applicativo. Quindi quando progetti la tua v-net devi pensare a quante risorse avrai e come vuoi raggrupparle. Ora non puoi scegliere un intervallo IP qualsiasi.

Azure segue lo standard RFC 1918 che riserva intervalli IP privati per le reti interne. Hai tre opzioni. L'intervallo 10.x.x o grande ti offre molto spazio per crescere. L'intervallo 172.x.x è un po' più piccolo ma comunque utile. L'intervallo 192.68.x.x è quello che probabilmente hai a casa sul tuo router. Ecco il punto. Lo spazio di indirizzamento della tua v-net non può sovrapporsi a nessun'altra rete a cui intendi connetterti. Questo è un errore comune. Molti scelgono un intervallo che sembra familiare solo per scoprire poi che entra in conflitto con la rete aziendale. Quindi se la rete del tuo ufficio usa 10.0.0.0.0.0.16 non usare lo stesso intervallo in Azure. Se provi a collegarle in seguito entreranno in conflitto e il traffico non saprà dove andare. Lascia che ti faccio un esempio concreto. Immagina di creare una configurazione ibrida dove Azure si connette al tuo data center locale che usa 10.0.0.0.0.0.0.0.16. Se crei una v-net con lo stesso intervallo avrai due reti che si contendono gli stessi IP. Pensaci bene. Due reti che usano lo stesso intervallo IP non possono comunicare correttamente. È come due case con lo stesso indirizzo. La posta si confonde. È un problema che non vorrai dover risolvere a posteriori. Quindi pianifica in anticipo e scegli un intervallo. D'acqua un consiglio per la pianificazione. Scegli un intervallo più grande di quello che pensi ti serve. Potresti pensare di aver bisogno solo di una 24 ore man mano che la tua applicazione cresce vorrai avere una 16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 ed è, non puoi semplicemente scaricare tutto all'unico grande. È qui che entri in gioco le subnets le subnets sono uno dei blocchi costitutivi fondamentali della tua v-net. Ti permettono di organizzare e proteggere le tue risorse. Una subnet è una sezione più piccola dello spazio indirizzi della tua v-net. Se la tua v-net è l'edificio le subnets sono le singole stanze non metteressi la sala server, la reception e la pausa a caffè tutta nello stesso spazio aperto, giusto?

Stasi da qui. È un concetto semplice ma fa un'enorme differenza nel modo in cui gestisci la tua rete. Risorse diverse vanno in subnets diverse. I tuoi server web vanno in una subnet, i tuoi database in un'altra e la logica dell'applicazione è una terza. Due ragioni. Sicurezza e organizzazione. Parliamo prima della sicurezza perché di solito è la più importante. Prima la sicurezza. Se qualcuno entra nel tuo server web non vuoi che abbia accesso diretto al tuo database. Le subnets separate creano una barriera naturale. L'attaccante dovrebbe attraversare quel confine e tu puoi controllare esattamente cosa passa. Puoi anche usare i gruppi di sicurezza di rete per controllare il traffico tra le subnets. È un argomento per un altro video ma vale la pena sapere che le subnets sono la base per tale sicurezza. Poi l'organizzazione. Quando tutto ha il suo posto gestirlo è più facile. Sai quale subnet contiene le tue risorse front-end e quale contiene i tuoi dati back-end?

Puoi applicare policy e regola all'intera subnet in una volta sola invece di configurare ogni risorsa singolarmente. Ciò fa risparmiare tempo e riduce gli errori. Ecco un dettaglio che coglie le persone in sorpresa. Azure riserva 5 indirizzi IP in ogni subnet per i propri scopi interni come il routing e il DNS. Quindi se crei una subnet con un range 24 che ti dà 256 indirizzi in realtà ne ottieni solo 251 utilizzabili. Un trabocchetto comune. Pianifichi per 256 ma ne ottieni solo 200. Aggiungi sempre un po' di margine quando dimensioni le tue sub. La buona notizia è che puoi aggiungere subnet dopo aver creato la vine non sei vincolato a quelle impostate durante la creazione. Quindi se ti rendi conto di aver bisogno una subnet separata per strumenti di gestione e monitoraggio aggiungila dopo. Nessun problema. Tuttavia è sempre meglio pianificare in anticipo. Aggiungere subnet in seguito è possibile ma potresti dover spostare le risorse il che può causare interruzioni.

Ecco invece la best practice. Usa subnet separate per i diversi livelli della tua applicazione fin dall'inizio. Rifletti sull'architettura applicazione. Di solito hai un livello front-end che gestisce le richieste e un livello back-end per la logica aziendale e un livello dati. Ognuno di questi dovrebbe avere la propria soluzione. Non aspettare di essere in produzione per capire che devi separare le cose. È molto più difficile quando le risorse sono già distribuite. Cosa significa questo per te? Le subnet servono a mantenere la rete organizzata e sicura. Sono come le stanze dei tuoi wifi. Pianificali in anticipo dai ogni livello dell'applicazione e il suo spazio. È così che mantieni la rete pulita e sicura. IP pubblici contro privati. Chi può vedere cosa? Parliamo di indirizzi IP perché non tutti gli indirizzi IP sono uguali. Quando distribuisci una risorsa in una v-net questa riceve un indirizzo IP privato di default.

È l'indirizzo che usa per comunicare con le altre risorse all'interno della v-net. Pensalo come un interno telefonico aziendale. Solo chi è nell'edificio può raggiungerlo? Gli IP privati sono accessibili solo dall'interno della v-net o da reti ad essa connesse. Se sei a casa col tuo portatile non puoi raggiungere un IP privato in Azure né su internet. È all'interno della tua rete privata. Quindi come rendi una risorsa raggiungibile da internet? Le assegni un indirizzo IP pubblico. È l'indirizzo visibile al mondo esterno come avere un numero di telefono pubblico invece di un interno. Ecco il punto fondamentale. Gli IP pubblici sono facoltati. Li assegni esplicitamente perché Azure non dà mai IP pubblici alle risorse a meno che tu non lo chieda. È una scelta progettuale. Il default dovrebbe essere privato e il pubblico una scelta deliberata. È qui che molti principianti fanno un errore. Danno IP pubblici a tutto.

Il loro server web, il database e l'API backend ne ricevono tutti uno. È un rischio per sé. Il tuo database non deve essere raggiungibile da internet e nemmeno la tua API backend. Solo le risorse frontend con cui gli utenti interagiscono direttamente dovrebbero avere IP pubblici. Gli IP pubblici sono disponibili in due versioni statici e dinamici. Un IP pubblico statico rimane invariato anche se arresti e riavvii la risorsa. Un IP pubblico dinamico può cambiare. Se stai eseguendo un'applicazione in produzione probabilmente ti servono IP statici affinché gli utenti trovino sempre. Se stai solo facendo dei test quelli dinamici possono andare bene. Puoi anche usare il cosiddetto prefisso IP pubblico che ti permette di riservare un blocco di indirizzi. Invece di crearli uno alla volta riservi un intervallo e poi assegni i singoli indirizzi da quello. Utile se sai che ti serviranno più IP pubblici per un progetto.

Che cosa significa questo per te? Gli privati sono impostazioni predefinite. Sono come il numero di un interno telefonico. Gli IP pubblici sono una scelta deliberata da fare solo quando serve che qualcosa sia raggiungibile dall'esterno. E quando servono valuta se ti serve statico o dinamico e se un prefisso ha senso gruppi di sicurezza di rete per il controllo del traffico. Quindi hai configurato la tua v-net le sub-net e gli indirizzi IP. Ma come controlli effettivamente il traffico in entrata e in uscita? Qui che entrano in gioco i gruppi di sicurezza di rete. Un NSG, il guardiano che controlla il traffico che entra ed esce dalle tue risorse? Immaginalo come butta fuori all'ingresso di un locale. Controlla i documenti guarda la lista degli ospiti e respinge chi non dovrebbe entrare. Ogni flusso di traffico che tenta di raggiungere la tua risorsa deve prima passare da questo butta fuori.

Gli NSG funzionano tramite regola. Ogni regola consente o nega il traffico basandosi su quattro elementi IP sorgente IP destinazione numero di porta e protocollo. Puoi ad esempio consentire il traffico dal tuo IP aziendale sulla porta 4443 o negare tutto il traffico da internet sulla porta 22. Questo è il tipo di controllo. Ora ecco una funzionalità molto potente. Puoi collegare un NSG a una subnet o direttamente all'interfaccia di rete di una singola VM. Se lo colleghi a una subnet quell'NSG si applica a tutto ciò che contiene. Ogni VM ogni database ogni risorsa è una policy generale. Se lo colleghi all'interfaccia di rete di una VM specifica si applica solo a quella macchina. Puoi persino fare entrambe le cose. Un NSG a livello di subnet per regole ampie e uno a livello di scheda di rete per le eccezioni. Le regole predefinite create da Azure sono piuttosto sensate. Consentono tutto il traffico all'interno della vinetta finché le tue risorse possono comunicare tra loro e bloccano tutto il traffico da internet impedendo a chiunque dall'esterno di raggiungere le tue risorse a meno che tu non lo consente esplicitamente.

È un buon punto di partenza. Lascia che ti faccia un esempio comune. Supponiamo che tu stia gestendo una macchina virtuale Linux e che tu debba accedervi via SSH. Creeresti una regola NSG che consenta il traffico in entrata sulla porta 22 ma non vuoi consentire l'accesso SSH da ovunque. Sarebbe cercarsi di guai. Quindi lo limiti al tuo indirizzo IP così solo tu puoi accedere via SSH e tutti gli altri vengono bloccati. Stessa idea per l'IP sulla porta 3.89 per le macchine Windows. Cosa significa questo per te? Gli NSG sono la prima linea di difesa e la parte migliore è che sono gratuiti. Non ci sono costi aggiuntivi per usarli quindi non ci sono scuse per non configurare. Ogni subnet e ogni risorsa dovrebbe avere un NSG associato. Inizia negando tutto e apri solo ciò che ti serve. Tabelle di routing e stradamento per dirigere i trappi. Ora parliamo di routing perché una volta deciso quale traffico è consentito devi decidere dove deve andare effettivamente.

Ecco il punto Azure crea automaticamente route di sistema per ogni subnet. Non devi fare nulla. Immaginalo come un navigatore predefinito che conosce le strade principali. Traffico all'interno della vnet verso vnet peered verso internet. Funziona tutto immediatamente ma a volte il navigatore predefinito non ti porta dove vuoi andare. E' qui che ti servono le route definite dall'utente UDR. Queste ti permettono di ignorare le route di sistema di Azure e di prendere il controllo del percorso del traffico. Come funziona? Crea una tabella di routing. Aggiungi le tue route personalizzate. Poi associ quella tabella di routing a una subnet. Da quel momento in poi il traffico che lascia quella subnet seguirà le tue regole invece di quelle predefinite. Lascia che ti faccia un esempio concreto. Supponiamo che tu voglia che tutto il traffico internet dalla tua vnet passi prima attraverso un firewall.

Magari devi spezionarlo, registrarlo o bloccare i siti malevoli. La route di sistema predefinita invia il traffico internet all'esterno. Non è quello che vuoi quindi crea una route che dice che qualsiasi traffico diretto a 0.0.0.0 ovvero ovunque su internet deve passare invece dal firewall. Questa è una route definita da lui. Le tabelle di routing usano un concetto chiamato next app. E' la destinazione verso cui il traffico viene inviato successivamente. Hai alcune opzioni. Puoi inviarlo a un appliance virtuale come un firewall. Puoi inviarlo a un gateway di rete virtuale che è il modo in cui ti connetti alle reti on-premise. Puoi inviarlo direttamente a internet oppure puoi non inviarlo a nessuno che sostanzialmente elimina il traffico. La cosa fondamentale da capire è che il routing è il modo in cui controlli il percorso che il traffico segue nella tua rete. Le route di sistema sono una buona impostazione predefinita ma non sempre adatte alla tua situazione.

Se devi far passare il traffico attraverso un punto di ispezione verso un gateway specifico o bloccarlo completamente ti serve un route definita dall'utente. Cosa significa questo per te? Il modo in cui dici al traffico dove andare. Hai il potere di sovrascrivere le impostazioni predefinite di Azure quando ne bisogna. Inizia con le route di sistema comprendi cosa fanno e poi aggiungi route personalizzate quando la tua architettura lo richiede. Vinet Peering Connettere le reti Finora abbiamo parlato di una singola vanette un edificio o una rete privata ma cosa succede quando hai più vinette? Magari ne hai una per il tuo ambiente di produzione e un'altra per i test oppure stai eseguendo applicazioni in diverse regioni Azure. Per impostazione predefinita queste vinette sono come da me non possono comunicare tra le loro. Sono come edifici separati senza strade tra loro e qui che entra in gioco il vinette Peering ti consente di riconnettere due vinette privatamente intendo privatamente il traffico tra vinette e peering rimane sulla rete backbone di Microsoft non tocca mai la rete internet pubblica ciò significa bassa latenza larghezza di bande elevate nessuna esposizione a minaccia esterna.

Ecco qualcosa che sorprende le persone Peering funziona anche tra le regioni questo è chiamato peering globale puoi avere una vinette in Europa occidentale in peering con una vinette nel sud-est asiatico e il traffico tra loro rimane sulla rete privata di Microsoft nessun gateway VPN nessun è più pubblico sono una connessione privata diretta ma c'è una regola che non puoi assolutamente infrangere le vinette in peering devono avere spazi in indirizzi non sovrapposti se entrambi le vinette tentano di utilizzare l'intervallo 10.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6 non possono essere messe in P gli indirizzi P andrebbero in conflitto e Azure non saprebbe a quale rete appartiene un pacchetto quindi ricordi quel consiglio sulla pianificazione di scegliere attentamente il tuo spazio di indirizzamento è per questo motivo se pensi di poter mettere in peering le vinette in futuro assicurati che i loro intervalli non si sovrappongano fin da lì. Ora ecco un dettaglio che mette in difficoltà le persone. Peering non è transitivo. Cosa significa? Supponiamo che la vignetta A sia un peering con la vignette B e la vignette B con la vignette C. La vignetta A non raggiunge automaticamente la vignette C attraverso B. Non sono connessa. Ogni peering è un collegamento diretto tra esattamente due vignette. Se vuoi che A comunichi con C serve un peering separato tra A e C, quindi come gestisci questo aspetto su larga scala. Si utilizza un'architettura hub and spoke.

Una vignette centrale, l'hub, è connessa tramite peering con molte altre vignette di spook. L'hub può contenere servizi condivisi come un firewall, un gateway VPN o strumenti di monitoraggio. Gli spook contengono i tuoi carichi di lavoro individuali. Ogni spook si collega direttamente al l'hub, ma gli spook non si collegano tra loro. Se uno spook deve raggiungere un altro spook, il traffico passa attraverso l'hub. Ciò mantiene l'ordine e offre un punto centrale per applicare le policy di sicurezza. Cosa significa questo per te? Il peering è il modo in cui costruisci reti che coprano più vignette regioni. È il ponte tra i tuoi edifici. Pianifica i tuoi spazi di indirizzamento in modo che non si sovrapponga. Ricorda che il peering non è transitivo e considera un design hub and spoke quando inizia a crescere oltre una singola vignette. Come si collega tutto il quadro generale. Quindi facciamo un passo indietro e vediamo come questi pezzi si incastrano davanti. È lì che risiede il vero potenziale. Inizi con Ovenet e il tuo spazio privato in azzurro. Pensalo come il tuo terreno.

All'interno di quel terreno crei le subnets. Queste sono le tue stanze. Una per i server web, una per i database, una per gli strumenti di gestione. Ogni subnet ottiene il proprio blocco di indirizzi ricavato dallo spazio di indirizzamento. Poi aggiungi la sicurezza. I gruppi di sicurezza di rete si collegano alle tue subnet. Controllano quale traffico è consentito l'entrata e l'uscita. La tua subnet web consente il traffico da internet sulla porta 4.3. La tua subnet database consente solo il traffico dalla subnet web sulla porta 14.3. Il butta fuori ogni porta se esattamente chi può entrare. Successivamente imposti routing. Forse vuoi che tutto il traffico internet in uscita passi attraverso un firewall per l'ispezione. Crei una tabella di routing, aggiungi una route personalizzata e la colleghi alle tue subnet. Ora il traffico segue il percorso che hai progettato invece di quello predefinito di Azure. E infine colleghi tutto insieme. Colleghi la tua vnet tramite peering con altre vnet, magari una vnet hub che ospita il tuo firewall e i servizi condiviti. Ora la tua applicazione copre più reti ma funziona come un unico sistema connesso. Ecco il momento della rivelazione. Nessuno di questi pezzi funziona esattamente. Una vnet senza subnet è solo spazio vuoto. Le subnet e NSG sono completamente aperte. Routing senza una progettazione chiara in via di traffico nel posto sbagliato. Il peering senza pianificazione crea conflitti di indirizzo. Sono un sistema.

Ogni pezzo dipende dagli altri. Lascia che ti faccia un esempio concreto. Immagina un'applicazione web. I tuoi server web si trovano in una subnet pubblica con un NSG che consente il traffico HTTPS da internet. I tuoi server applicativi si trovano in una subnet privata che accetta solo traffico dalla subnet web. Il tuo database si trova in un'altra subnet privata che accetta traffico solo dalla subnet dell'applicazione. Una tabella di routing forza tutto il traffico in uscita attraverso un firewall nella vnet hub per il login e l'ispezione. E l'intero sistema è in peering con la tua rete aziendale così il tuo team interno può gestirlo. Questo è il vero valore, non una singola funzionalità. È il modo in cui lavorano tutti insieme. 20 anni fa avresti comprato server separati, configurato router fisici e gestito firewall per ogni dispositivo per ogni dispositivo. Era tutto manuale, lento e costoso. Azure ti offre tutto questo come servizio. Lo definisci con pochi clic o uno script e funziona semplicemente. Cosa significa questo per te? Una volta hai capito come questi pezzi si incastrano, la rete azzurra diventa prevedibile. Non stai tirando in due nè, stai progettando. Quando qualcosa si rompe sai esattamente dove guardare perché capisci il sistema? Ecco cosa voglio che tu porti a casa da questo episodio. Primo, il passo più importante che puoi fare. Crea una vnet con uno spazio indirizzi ben pianificato prima di distribuire qualsiasi cosa. Quella singola decisione influenza tutto ciò che viene dopo. Secondo, usa le subnet per separare i livelli della tua applicazione.

Web server, app server, database, dai a ognuno il proprio spazio. E terzo, inizia con gli NSG. Sono gratuiti, sono potenti e migliorano drasticamente la tua sicurezza fin dal primo giorno. La tua vnet è la base di tutto ciò che costruisci in azzurra. Te la configuri bene e tutto il resto diventa più facile. Se sbagli passerai tutto il tempo a combattere con la tua rete. Iscriviti sulla tua piattaforma podcast preferita e condividi questo episodio con chi sta iniziando il suo percorso in azzurra. Lascia un commento se qualcosa ti è stato utile. Ci vediamo nel prossimo episodio.