Nutzung von Azure Service Endpoints aus der On-Premise-Umgebung mit VPN über eine NVA

In einem aktuellen Kundenprojekt werden Microsoft Azure SaaS-Dienste, wie Azure File Shares und Azure MySQL-Instanzen genutzt.

Der Zugriff auf diese Dienste erfolgt über einen DNS Namen, wie z.B. https://testfileshare.file.core.windows.net. Die Hostnamen lösen dabei auf Public IPs auf.

Konfiguriert man nun nichts weiter außer dem SaaS-Dienst, so erfolgt der Zugriff auf die Dienste aus der Azure-Umgebung des Kunden über das Internet. Möchte man jedoch aus Performance- oder Sicherheitsgründen keinen Zugriff über das Internet auf die Ressourcen nehmen, so kann man innerhalb seiner Azure-VNets bzw. Subnetze sogenannte Service Endpoints konfigurieren.

Ein solcher Service Endpoint ist im Prinzip eine direkte Route im Azure-Netzwerk zwischen dem VNet und dem Service, wobei der Zugriff dann nicht mehr über das Internet erfolgt. Zudem kann der Dienst dann so konfiguriert werden, dass nur noch ein Zugriff aus (bestimmten) Azure VNets möglich ist.

Soweit so gut. Was ist aber, wenn man aus der On-Premise-Umgebung, also z.B. von den Fat Clients des Unternehmens, auf diese SaaS-Dienste zugreifen möchte?

Die von Microsoft empfohlene Best-Practice ist hierbei, zusätzlich zu den Azure VNets auch die öffentliche IP des Unternehmens für den Dienst freizuschalten. Ein Zugriff über VPN auf SaaS-Dienste bzw. Service Endpoints ist von Microsoft nicht vorgesehen.

Im konkreten Projekt war dies kein gangbarer Weg, da die Security-Abteilung des Kunden diesen Zugriff auf sensible Unternehmensdaten über das Internet abgelehnt hat.

Glücklicherweise kommen in der Azure-Umgebung des Kunden jedoch sogenannte NVAs (Network Virtual Appliances), also Firewalls, zum Einsatz. Konkret werden FortiNet NVAs verwendet, das hier beschriebene Setup ist aber prinzipiell auch mit allen anderen Herstellern einsetzbar.

Wir haben die Limitation bzw. das fehlende Feature in Azure über NAT (Network Address Translation) umgangen.

Hierzu haben wir einen freien IP Bereich aus dem Hub-VNet (also dem VNet, in dem die NVAs provisioniert sind) auf die NVAs geroutet, z.B. 10.90.0.128/26.

Für den entsprechenden SaaS-Dienst wurde eine NAT IP-Adresse aus dem Bereich vergeben, 10.90.0.129, und im On-Premise DNS mit dem Hostnamen testfileshare.file.core.windows.net eingetragen.

Somit erfolgen Zugriffe auf den SaaS-Dienst nicht mehr über das Internet, sondern über den VPN Tunnel und werden in der Azure-Umgebung auf die NVAs geleitet.

Auf den NVAs wurde anschließend folgende NAT-Regel konfiguriert:

Original Source Original Destination Original Service Translated Source Translated Destination Translated Service
Any 10.90.0.129 445/tcp Interface IP 52.239.100.123 445/tcp

Im Subnetz der Inside-Interfaces der NVAs wurde der Service Endpoint für den SaaS-Dienst aktiviert und auf den NVAs eine statische Route zur Public IP 52.239.100.123 über das Azure-Gateway dieses Subnetzes eingerichtet.

Die NAT-Konfiguration sorgt nun dafür, dass ein Zugriff von z.B. 10.1.2.100 auf die NAT IP 10.90.0.129 auf den NVAs so umgeschrieben wird, dass der Traffic die NVAs so verlässt, dass er in der Azure-Umgebung so aussieht, als käme er von den NVAs und würde zur Public IP des SaaS-Dienstes gehen. Dies erlaubt eine Nutzung des Service Endpoints, um einen Zugriff auf den Dienst über das Internet zu verhindern. Durch das Source NAT kommen Antwortpakete vom Dienst wieder an der NVA an und werden dort wieder auf die originalen IP-Adressen umgeschrieben und anschließend über den VPN Tunnel wieder zum On-Premise Client geroutet.

Florian Wiethoff

Florian Wiethoff

CEO

Der Beweis das Schwaben auch hochdeutsch können liefert der Co-Gründer von Braintower jeden Tag aufs Neue. Wenn nicht auf der Suche nach unassignten Jira-Tasks, frönt dieser Code Enthusiast einer unnatürlichen Liebe für alles Digitale. Träumt bestimmt von elektrischen Schafen und würde ganz sicher auch Kobayashi Maru bestehen. Für Braintower bloggt er über IOT, SMS Gateway und Next Generation Technologien.

Gefällt dir der Artikel? Bitte teile ihn!
Share on Facebook
Facebook
9Share on Google+
Google+
0Share on LinkedIn
Linkedin
Email this to someone
email
Tweet about this on Twitter
Twitter