Virtuelle Maschinen mit Windows Server in der Azure Cloud werde üblicherweise per RDP (Remote Desktop Protokoll) oder PowerShell-Remoting administriert. In produktiven Umgebungen wo Sicherheit eine Relevanz hat, sollte dies nicht über eine öffentliche IP-Adresse erfolgen. Oft genug habe ich dies in Kundenumgebungen schon vorgefunden. Daher zeige ich hier eine super einfache Möglichkeit einen sicheren Azure IPSEC Tunnel zu Azure mit der Windows Server RRAS-Rolle über eine Consumer Fritzbox aufzubauen.

Netzwerk-Design

Hinweis: Dies ist keine stumpfe Klickanleitung. Der Leser soll nachher verstehen, wie es grundsätzlich funktioniert. Eine Klickanleitung ist hier abrufbar.

Zuerst skizziere ich den grundsätzlichen Aufbau. Dieser besteht aus drei Zonen.

1. Auf der linken Seite befindet sich mein Heimnetz, welches mit einer Fritzbox ans Internet gekoppelt ist. Dort befindet sich auch der Windows Server 2016 mit der RRAS Rolle und einem Subnetz welches die Fritzbox managed.

2. In der Mitte „Das Internet“ 😉

3. Auf der rechten Seite ist ein Azure VNET mit zwei Subnetzen dargestellt. Zum einen wird ein Gateway-Subnetz benötigt, welches den Azure IPSEC VPN-Verkehr abwickelt. Und zusätzlich das eigentliche Subnetz mit der VM drin, die von remote administriert werden soll. Im VPN-Gateway-Subnetz ist eine VPN Gateway deployed.

 

 

 

 

 

Konfiguration Zone 1

1. Zunächst muss die Fritzbox einige Ports an den Windows-Server weiterleiten. Diese Ports dienen dem IPSEC-Tunnel. Und weil der Windows Server den Tunnel halten soll, müssen die Datenpakete dorthin geroutet werden.
   1. UDP Port 500
   2. UDP Port 4500
   3. ESP
   4. TCP 10000
2. Dann muss auf der Fritzbox eine statische Route eingerichtet werden. Die Pseudo-Syntax lautet: Wenn ein Datenpaket das Azure-Subnetz erreichen will, dann schicke das Paket an das Netzwerk-Interface des Windows-Servers. Der weiß schon was er damit machen soll. Nämlich durch den Tunnel schicken. Dies dient dazu, dass auch alle andere Netzwerk-Teilnehmer aus der Zone 1 Ihre IP-Pakete an das Azure-Netzwerk schicken können.
3. Auf dem Windows-Server wird die RRAS Rolle benötigt. Diese muss entsprechend konfiguriert werden.
4. Dann muss auf dem Windows-Server eine S2S-Schnittstelle eingerichtet werden, die auf den Azure IPSEC Endpunkt zeigt. Dies ist die eigentliche Verbindung zum VPN-Gateway auf der Azure-Seite.
5. Auf dem Windows-Server wird ebenfalls eine Statische Route benötigt. Pseudo-Syntax: Wenn ein Datenpaket für Azure im Anmarsch ist, dann schicke dies durch die neue S2S-Schnittstelle.

Voilá, das lokale Netzwerk ist vorbereitet.

Konfiguration Zone 2

1. Die Fritzbox hat eine öffentlich „routbare“ IP-Adresse im Internet. Eine „genattete“ Adresse (Carrier grade NAT), wie sie die Provider neuerdings immer mehr verteilen, ist dafür nicht geeignet.
2. In Azure wird eine normale Dynamic Public IP erzeugt, die den Azure IPSEC Datenverkehr annimmt.

Konfiguration Zone 3

1. Zuerst benötigt man ein Azure VNET. Dies ist wie ein Subnetz der Fritzbox zu sehen. Dort wird ein ein eigener von anderen Kundenumgebungen getrennter IP-Adressbereich definiert. Doku
2. Dieses VNET wird in zwei Subnetze unterteilt. Ein Subnetz für den VPN-Transfer-Verkehr und ein Subnetz für die VM selbst.
3. Dann wird eine Öffentliche IP benötigt. Es ist eine dynamische IP vorgegeben. Keine Angst, die IP wird sich nicht ändern, solange das Gateway läuft. Doku
4. Nun wird eine Virtual Network Gateway benötigt. In diesem Fall wird ein Route based Gateway benötigt. Route based bedeutet, dass die VPN-Router eine bestimmte Methode nutzen, um zu entscheiden welche Datenpakete durch den Tunnel dürfen und welche nicht. Doku
5. Dann wird mit einem Local Network Gateway in Azure definiert, unter welcher öffentllichen IP die Fritzbox erreichbar ist.
6. Mit einer Connection werden die beiden Gateways dann virtuell verbunden. Dort wird auch der PSK vergeben.

Fazit

Wie ist der konkrete Datenverkehr, zwischen einem lokalen Client und einer Azure VM?

1. Der Client (z. B.: Ein Windows PC) schickt ein Datenpaket an das Standard-Gateway, da die zu erreichende IP-Adresse nicht im Subnetz des Clients liegt. Das Standard-Gateway ist die Fritzbox.
2. Die Fritzbox kennt anhand der statischen Route, wie das Datenpaket zu behandeln ist und leitet dies weiter zum Windows Server.
3. Der Windows Server (mit RRAS) nimmt das Paket an und weiß auch anhand der statischen Route, wie mit dem Paket verfahren werden soll. Nämlich in die S2S-Schnittstelle schicken. Die S2S-Schnittstelle zeigt auf die öffentliche IP in Azure. Der RRAS-Dienst verpackt also nun das Packet entsprechend den konfigurierten Sicherheitseinstellungen in ein VPN-Paket.
4. Das VPN-Paket geht nun auf der öffentlichen IP in Azure ein. Das Azure SDN (Software Defined Network) weiß wem die öffentliche IP zugeordnet ist. Nämlich dem Virtual Network Gateway (VPN-Gateway) und leitet es weiter.
5. Das Virtual Network Gateway kennt die Sicherheitseinstellungen (PSK, etc.) und packt das VPN-Paket aus.
6. Anhand der Header, kann das Gateway die Ziel-IP auslesen. Dann schickt das Gateway das IP-Paket wieder ans das Azure VNET.
7. Das Azure VNET kennt alle konfigurierten Subnetze und schickt das IP-Paket an die VM.

Voilá, Ziel erreicht.

Einschränkungen von Azure IPSEC in dieser Konstellation

Natürlich ändert sich die öffentliche IP-Adresse der Fritzbox einmal täglich. Dann muss die Connection gelöscht werden, die neue IP im Local Gateway eingetragen werden und die Connection wieder erzeugt werden.

Wie das automatisiert werden kann beschreibe ich in einem folgenden Beitrag.

Komplettanleitung

Wer das Prinzip verstand hat, kann mit dieser  Anleitung gleich in die Konfiguration einsteigen.

Viel Spaß beim Nachbauen.

Über mich