Sandro Reiter

vCard und IT-Blog

Azure: Hub-Spoke in Tenant-übergreifenden VNet-Peerings

In meinem Blogpost zum Thema Tenant-übergreifendes VNet-Peering habe ich aufgezeigt, wie man zwei Azure Tenants mit einem VNet Peering verbinden kann. Zum Zeitpunkt, als ich den Artikel verfasst habe, gab es noch die Einschränkung, das die zu verbindenden VNets in den zwei Tenants in der selben Azure Region laufen müssen.

 

Ich habe mir diese Woche die Thematik nochmal auf den Tisch geholt und festgestellt: Die Limitierung wurde aufgehoben.

Dadurch ist es nun möglich Hub-Spoke-Topologien über mehrere Azure Tenants und mehrere Azure Regionen aufzubauen.

Die Maus-Klick Mandelas schauen dabei aber in die Röhre, denn die Funktionen für Hub-Spoke “UseRemoteGateways” & “AllowGatewayTransit” können (derzeit) nicht über das Azure Portal, sondern nur per PowerShell oder CLI gesetzt werden.

 

Ein bereits bestehendes Peering (siehe vorheriger Blogeintrag) vorausgesetzt, wird Hub-Spoke mit folgendem Skript aktiviert:

#declare variables
$subscriptionTenantA = "subscriptionID"
$vNetTenantA = "vNet"
$vnetResourceGroupTenantA = "vNetResourceGroup"
$subscriptionTenantB = "subscriptionID"
$vNetTenantB = "vNet"
$vnetResourceGroupTenantB = "vNetResourceGroup"

#connect to AzureRM
Connect-AzAccount

#select subscription in Tenant A
Select-AzSubscription -Subscription $subscriptionTenantA

#Activate GatewayTransit on Hub network
$peerSiteA = Get-AzVirtualNetworkPeering -ResourceGroupName $vnetResourceGroupTenantA -VirtualNetworkName $vNetTenantA
$peerSiteA.AllowGatewayTransit = $true
Set-AzVirtualNetworkPeering -VirtualNetworkPeering $peerSiteA

#select subscription in Tenant B
Select-AzureRmSubscription -Subscription $subscriptionTenantB

#use Remote Gateways on Spoke network
$peerSiteB = Get-AzVirtualNetworkPeering -ResourceGroupName $vnetResourceGroupTenantB -VirtualNetworkName $vNetTenantB
$peerSiteB.UseRemoteGateways = $true
Set-AzVirtualNetworkPeering -VirtualNetworkPeering $peerSiteB

Anschließend sind Ressourcen, bspw. von OnPremises, in der Lage über das Hub-Netzwerk mit Ressourcen in den jeweiligen Spoke-Netzwerken zu kommunizieren.

Azure: Tenant-übergreifendes VNet-Peering

Peerings zwischen virtuellen Netzwerken in Azure sind eine tolle Sache: Einfach zu konfigurieren, schnell bereitgestellt und die Performance ist ebenfalls klasse!

Zum Verbinden von virtuellen Netzwerken aus verschiedenen Azure Active Directory Tenants, wie es beispielsweise in Unternehmensgruppen der Fall ist, mussten bis vor Kurzem noch VPN-Gateways bereitgestellt werden.

Jetzt ist es möglich VNet-Peerings Tenant-übergreifend zu erstellen, derzeit allerdings nur über Azure CLI, PowerShell oder als ARM-Template.

Ich zeige Euch die PowerShell Variante.

Als Voraussetzung benötigt Ihr einen Azure AD-Benutzer, welcher sowohl in Tenant A als auch Tenant B (dann als Gast) die Berechtigung “Network Contributor” auf das jeweilige virtuelle Netzwerk hat, um das VNet “auf der anderen Seite” auslesen und das Peering erstellen zu können.

 

Ist das gegeben, kann es losgehen. Folgendes Skript erledigt alles nötige für Euch, wenn Ihr die Variablen korrekt befüllt:

#declare variables
$subscriptionTenantA = "subscriptionID"
$vNetTenantA = "vNet"
$vnetResourceGroupTenantA = "vNetResourceGroup"
$peerAtoBname = "TenantA-TenantB-Peer01"
$subscriptionTenantB = "subscriptionID"
$vNetTenantB = "vNet"
$vnetResourceGroupTenantB = "vNetResourceGroup"
$peerBtoAname = "TenantB-TenantA-Peer01"

#connect to AzureRM
Connect-AzAccount

#select subscription in Tenant A
Select-AzSubscription -Subscription $subscriptionTenantA

#peer vnet in tenant A to vnet in tenant B
$vNet = Get-AzVirtualNetwork -Name $vNetTenantA -ResourceGroupName $vnetResourceGroupTenantA
Add-AzVirtualNetworkPeering -Name $peerAtoBname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantB/resourceGroups/$vnetResourceGroupTenantB/providers/Microsoft.Network/virtualNetworks/$vNetTenantB"

#select subscription in Tenant B
Select-AzSubscription -Subscription $subscriptionTenantB

#peer vnet in tenant B to vnet in tenant A
$vNet = Get-AzVirtualNetwork -Name $vNetTenantB -ResourceGroupName $vnetResourceGroupTenantB
Add-AzVirtualNetworkPeering -Name $peerBtoAname -VirtualNetwork $vNet -RemoteVirtualNetworkId "/subscriptions/$subscriptionTenantA/resourceGroups/$vnetResourceGroupTenantA/providers/Microsoft.Network/virtualNetworks/$vNetTenantA"

Läuft, oder? 😉

 

Der Vollständigkeit halber noch folgender Hinweis zum Schluss:

Die Optionen “Allow gateway transit” und “Use remote gateway” stehen nur zur Verfügung, wenn sich die virtuellen Netzwerke in der selben Azure Region befinden. Bei einer Verbindung bspw. zwischen Westeuropa und Frankreich-Mitte funktioniert das derzeit leider noch nicht.

Azure: S2S-VPN und die IPSec-Policy

Wer kennt es nicht: Eingefleischte Netzwerkadmins, womöglich sogar angestellt bei einem Rechenzentrums-Dienstleister, die alles rund um die Cloud als total unsicher und sowieso überflüssig einschätzen (und in Wahrheit vermutlich nur Angst um den Ast haben, auf dem sie sitzen) meckern über alles wo Microsoft dran steht oder drin ist.

Da ist es doch ein willkommener Aufhänger, wenn eine VPN Verbindung zu Azure nicht die Anforderungen abbilden kann, welche das NOC gern hätte.

Aber falsch gedacht! Was viele nicht wissen: Es ist möglich die Site-to-Site IPSec-Richtlinie einer VPN-Verbindung mithilfe des Azure CLI und des AzureRM PowerShell-Moduls an die gewünschten Anforderungen anzupassen.

 

Um die Richtlinie zu konfigurieren, müssen wir uns zunächst in den Azure Resource Manager einloggen, das gelingt uns wie folgt:

$credentials = Get-Credential

Login-AzureRmAccount -Credential $credentials

$subscriptionId = ( Get-AzureRmSubscription | Out-GridView -Title "Select an Azure Subscription ..." -PassThru).SubscriptionId
Select-AzureRmSubscription -SubscriptionId $subscriptionId

 

Anschließend können wir mit dem nachfolgenden Skript die Parameter der IPSecPolicy festlegen und damit die VPN Verbindung zum VPN-Gateway auf “der anderen Seite” aufbauen.

$rg = "GatewayResourceGroup"

$policy = New-AzureRmIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA1 -DhGroup DHGroup2 -IpsecEncryption AES256 -IpsecIntegrity SHA1 -PfsGroup None -SALifeTimeSeconds 27000 -SADataSizeKilobytes 1024000

$vpngw = Get-AzureRmVirtualNetworkGateway -Name "GW1"  -ResourceGroupName $rg
$localvpngw = Get-AzureRmLocalNetworkGateway  -Name "Local-GW1" -ResourceGroupName $rg

New-AzureRmVirtualNetworkGatewayConnection -Name "MyConnection" -ResourceGroupName $rg -VirtualNetworkGateway1 $vpngw -LocalNetworkGateway2 $localvpngw -Location "Azure Region" -ConnectionType IPsec -IpsecPolicies $policy -SharedKey 'PSK' -RoutingWeight 0

Welche Werte von Azure unterstützt werden, können wir unter folgendem Link in den Microsoft Docs nachlesen:

https://docs.microsoft.com/de-de/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell

 

Um zu prüfen, ob die Einstellungen korrekt übernommen wurden, führen wir  folgendes Code-Snippet aus:

$rg = "GatewayResourceGroup"
$con = Get-AzureRmVirtualNetworkGatewayConnection -Name "MyConnection" -ResourceGroupName $rg

Write-Output $con.IpSecPolicies

 

Nach ein paar Augenblicken und korrekter Konfiguration auf beiden Seiten, steht der VPN Tunnel.