Effettuare la connessione tra due VNET (Peering) in differenti sottoscrizioni di Microsoft Azure
Il peering di reti virtuali consente di connettere facilmente due reti virtuali (VNET) di Azure. Dopo avere eseguito il peering, le reti possono comunicare tra di loro ed il traffico tra le macchine virtuali connesse alle due VNET viene instradato tramite l’infrastruttura backbone Microsoft e solo tramite indirizzi IP privati. È possibile effettuare due tipi di peering:
- Peering reti virtuali – Connessione di reti virtuali entro la stessa Region di Azure
- Peering reti virtuali globali – Connessione di reti virtuali in diverse Region di Azure
I vantaggi offerti dal peering delle VNET sono notevoli:
- Il traffico di rete tra reti virtuali di cui è stato eseguito il peering è privato e viene mantenuto nella rete backbone Microsoft. Nella comunicazione tra le reti virtuali non sono necessari gateway.
- Connessione a bassa latenza e larghezza di banda elevata tra le risorse in reti virtuali diverse.
- Capacità delle risorse presenti in una rete virtuale di comunicare con le risorse in una rete virtuale diversa.
- Capacità di trasferire dati tra sottoscrizioni di Azure e Region diverse di Azure.
In questa guida esamineremo come effettuare il peering (cioè la connessione) tra due reti virtuali di Azure che si trovano in sottoscrizioni differenti.
In questo scenario prenderemo in considerazione reti virtuali create tramite il Resource Manager. Non è possibile creare un peering di rete virtuale tra due reti virtuali distribuite tramite il modello di distribuzione classica. Se è necessario connettere due reti virtuali, entrambe create tramite il modello di distribuzione classica, è possibile usare un VPN Gateway di Azure.
Creare un peering tra reti virtuali che si trovano in sottoscrizioni diverse ma associate allo STESSO tenant di Azure Active Directory
Se avete sottoscrizioni diverse ma associate allo stesso tenant di Azure Active Directory allora la procedura da usare prevede l’utilizzo di account diversi per ogni sottoscrizione. Se si usa un account dotato di autorizzazioni per entrambe le sottoscrizioni, è possibile usare lo stesso account per tutti i passaggi.
Per effettuare un peering gli account devono avere il permesso di Network Administrator per la rete virtuale.
Figura 1: Schema del peering da realizzare
Creazione della prima rete virtuale nella prima sottoscrizione
Ho creato una nuova rete virtuale, chiamata VNET-A, nella sottoscrizione Lab e nel Resource Group chiamato RG-A. Come Location ho scelto West Europe.
Figura 2: Creazione della prima rete nella prima sottoscrizione
Creazione della seconda rete nella seconda sottoscrizione
Ho creato una nuova rete virtuale, chiamata VNET-B, nella sottoscrizione Professional e nel Resource Group chiamato RG-B. Come Location ho scelto France Central.
Figura 3: Creazione della seconda rete nella seconda sottoscrizione
Attenzione: è importante sottolineare che per effettuare il peering le due VNET non devo andare in overlap, cioè devono avere un address space diverso. Nel mio caso ho utilizzato 10.0.0.0/16 per la VNET-A e 10.1.0.0/16 per la VNET-B.
Peering tra le due reti
Per effettuare il peering tra le due reti mi sono loggato come utente che ha privilegi in entrambi i Resource Group creati in entrambe le sottoscrizioni. Per comodità mi sono servito di un Microsoft Account. Sono partito dalla rete VNET-A e dalla Sottoscrizione Lab.
Figura 4: Aggiunta del peering partendo dalla rete VNET-A
Nella schermata relativa all’aggiunta del peering ho dato un nome al collegamento (VNET-A-VNET-B) e ho indicato la sottoscrizione (Professional) e la virtual network (VNET-B) con cui effettuare il collegamento.
Figura 5: Aggiunta del peering dalla VNET-A verso la VNET-B
Dopo pochi secondi, il peering sarà completato e si troverà nello stato di Initiated. È necessario infatti ripetere la stessa operazione anche nell’altro verso, dalla VNET-B verso la VNET-A
Figura 6: Il peering è in modalità Initiated, in attesa del collegamento nell’altro verso
Ripeto quindi la stessa operazione di peering collegandomi alla Sottoscrizione B con un account che abbia i privilegi anche nella prima sottoscrizione. Come detto prima, per comodità ho utilizzato un Microsoft Account che ho aggiunto ad entrambe le sottoscrizioni. Nella schermata relativa all’aggiunta del peering ho dato un nome al collegamento (VNET-B-VNET-A) e ho indicato la sottoscrizione (Lab) e la virtual network (VNET-A) con cui effettuare il collegamento.
Figura 7: Aggiunta del peering dalla VNET-B alla VNET-A
Come potete vedere dalla figura sotto, sono riuscito a connettere tra di loro due reti che si trovano in due sottoscrizioni Azure diverse e che si trovano anche in due Region diverse (West Europe e France Central)
Figura 8: Peering tra due VNET in region diverse e in sottoscrizioni diverse
Creare un peering tra reti virtuali che si trovano in sottoscrizioni diverse e associate a tenant DIVERSI di Azure Active Directory
Nel caso le reti che volete collegare si trovino in sottoscrizioni che sono associate a due tenant diversi di Azure Active Directory è necessario effettuare alcuni passaggi aggiuntivi. Ho creato una nuova rete virtuale, chiamata VNET-C, nella sottoscrizione MVP e nel Resource Group chiamato RG-C. Come Location ho scelto UK South. Per comodità mi sono servito dello stesso Microsoft Account utilizzato per gestire le altre due sottoscrizioni.
Figura 9: Creazione della VNET in una sottoscrizione associata ad un’altra Azure AD
Dopo aver atteso la creazione della VNET, cliccate su Properties e copiate il RESOURCE ID, come mostrato in figura:
Figura 10: REOSURCE ID della VNET
Sono tornato nella sottoscrizione A, mi sono loggato con il solito Microsoft Account e ho effettuato il peering tra VNET-A (Sottoscrizione Lab e Tenant A) e VNET-C (Sottoscrizione MVP e Tenant C) utilizzando il RESOURCE ID della VNET-C, come mostrato in figura:
Figura 11: Connessione tra due VNET in sottoscrizioni diverse utilizzando il REOSURCE ID
Purtroppo subito dopo aver lanciato il peering ho ricevuto un messaggio di errore che mi avvisava che l’account che stavo utilizzando non aveva i permessi necessari per effettuare il collegamento con la VNET remota. In realtà ero sicuro che l’account avesse i permessi su entrambe le sottoscrizioni.
Figura 12: La creazione del vnet peering effettuata dal portale fallisce
Ho provato ad eseguire PowerShell per effettuare la stessa operazione, lanciando i seguenti comandi
1 2 3 4 5 6 7 8 9 10 11 12 |
#Connessione ad Azure Connect-AzureRmAccount #Enumerazione delle sottoscrizioni gestibili dall'acoount con cui vi siete autenticati Get-AzureRmSubscription #Selezione della sottoscrizione corretta Select-AzureRmSubscription -Subscription Lab # Peer VNET-A con VNET-C $vNetA=Get-AzureRmVirtualNetwork -Name VNET-A -ResourceGroupName RG-A Add-AzureRmVirtualNetworkPeering -Name 'VNET-A-VNET-C' -VirtualNetwork $vNetA -RemoteVirtualNetworkId "/subscriptions/<id della sottoscrizione di destinazione>/resourceGroups/RG-C/providers/Microsoft.Network/virtualNetworks/VNET-C" |
Anche con PowerShell l’operazione fallisce.
Figura 13: La creazione del peering tramite PowerShell fallisce
A questo punto, ho provato ad usare Azure CLI. Se non lo avete già fatto, installate Azure CLI utilizzando la guida Install Azure CLI on Windows e lanciate i seguenti comandi da un command prompt oppure da PowerShell:
1 2 3 4 5 6 7 8 9 10 11 |
#Login ad Azure az login #Enumerazione delle sottoscrizioni gestibili dall'account con cui vi siete autenticati az account list --output table #Selezione della sottoscrizione corretta az account set --subscription Lab # Peering tra VNET-A e VNET-C az network vnet peering create --name VNET-A-VNET-C --resource-group RG-A --vnet-name VNET-A --remote-vnet-id /subscriptions/<ID della sottoscrizione di destinazione>/resourceGroups/RG-C/providers/Microsoft.Network/virtualNetworks/VNET-C --allow-vnet-access |
Dopo pochi secondi il peering si sarà creato.
Figura 14: Creazione del peering utilizzando Azure CLI
Figura 15: Peerign tra VNET in differenti sottoscrizioni completato
Ovviamente ripetete la stesse operazione anche nell’altro verso, dopo esservi procurati il RESOURCE ID della VNET-A.
Sono riuscito quindi a connettere tra di loro due reti che si trovano in due sottoscrizioni Azure diverse, associate a due Tenant di Azure Ad diversi e che si trovano anche in due Region diverse (West Europe e UK South)
Utilizzo di Account diversi per la creazione del Peering
Utilizzando lo stesso Microsoft Account per collegarmi alle 3 sottoscrizioni è stato certamente molto comodo. Se si usa un account dotato di autorizzazioni per entrambe le sottoscrizioni, è possibile usare lo stesso account per tutti i passaggi. Ma come comportarsi nel caso questo non fosse possibile?
Se le reti virtuali si trovano in sottoscrizioni diverse e le sottoscrizioni sono associate a tenant di Azure Active Directory diversi, è necessario eseguire i seguenti passaggi:
- Aggiungere l’utente di ogni tenant di Active Directory come utente guest nel tenant di Azure Active Directory opposto.
- Ogni utente deve accettare l’invito per l’utente guest dal tenant di Active Directory opposto.
Aggiunta di un utente guest al Tenant A di Active Directory
Selezionate il nodo Azure Active Directory del Tenant A nella Sottoscrizione A e cliccate su Users. Cliccate sul pulsante New guest user e seguite le indicazioni riportate. Ho inserito un utente che abbia permessi amministrativi sul Tenant C della Sottoscrizione C. L’utente riceverà un messaggio di posta elettronica con l’invito ad aggiungersi al Tenant A.
Figura 16: Aggiunta di un nuovo guest user al Tenant A
Figura 17: Invito ad aggiungersi al Tenant
Controllate che l’utente sia stato aggiunto al Tenant A. Se l’utente non possiede una casella di posta elettronica associata all’account e quindi non può confermare l’invito ricevuto è possibile cliccare sul pulsante Resend Invitation, che creerà un Invitation URL da utilizzare per confermare l’invito.
Figura 18: URL utilizzato per accettare l’invito dal Tenant A
Poiché il mio utente [email protected] non ha una casella di posta elettronica, ho incollato l’url in un browser e mi sono autenticato con le credenziali dell’utente [email protected]
Figura 19: Autenticazione con le credenziali di [email protected] del Tenant C
Dopo l’autenticazione ho provveduto a confermare l’invito cliccando su Accetto.
Figura 20: Conferma dell’invito ricevuto
Ritornando nel Tenant A noterete che l’utente ha Invitation Accepted
Yes.
Figura 21: L’utente del Tenant C ha accettato l’invito
Autorizzazioni
L’account usato per il peering della rete virtuale deve essere assegnato ai ruoli seguenti:
- Network Contributor: per una rete virtuale distribuita tramite Resource Manager.
- Classic Network Contributor: per una rete virtuale distribuita tramite il modello di distribuzione classica.
Concediamo quindi all’utente [email protected] del Tenant C il ruolo di Network Contributor per la VNET-A, come mostrato in figura:
Figura 22:All’utente del Tenant C viene assegnato il ruolo di Network Contributor
Figura 23: L’utente del Tenant C adesso può amministrare la rete VNET-A
Aggiunta di un utente guest al Tenant C di Active Directory
Effettuate le stesse operazioni nel Tenant C, per permettere poi la creazione del peering da VNET-C verso VNET-A. Selezionate il nodo Azure Active Directory del Tenant C e cliccate su Users. Cliccate sul pulsante New guest user e seguite le indicazioni riportate. Inserite un utente che abbia permessi amministrativi sul Tenant A della Sottoscrizione A. L’utente riceverà un messaggio di posta elettronica con l’invito ad aggiungersi al Tenant C, come ho mostrato prima.
Creazione del Peering
Terminata la creazione degli utenti guest nei due Tenant e date le dovute autorizzazioni, loggatevi ai diversi Tenant con i rispettivi Account ed effettuare il peering delle reti virtuali uno alla volta, utilizzando i comandi di Azure CLI che avete visto.
Conclusioni
Il peering di reti virtuali consente di connettere facilmente due reti virtuali di Azure e le risorse di una delle due reti virtuali possono connettersi direttamente alle risorse dell’altra rete virtuale. Tutto questo può essere fatto senza la necessità di configurare un Virtual Network Gateway e senza essere vincolati alla stessa Region di Azure.