hallo@ops365.de
Ops365
  • Home
  • Blog
  • Patches
  • Autoren

Veröffentlichung von Azure VMs mit dem Azure Application Gateway

Freitag, 19. Mai 2017Denis Holtkamp

Heute möchte ich über einen relativ neuen Dienst von Azure schreiben, das Azure Application Gateway. Dieser Azure PaaS Dienst fungiert als Reverse-Proxy und dient der Veröffentlichung von Ressourcen, die in Azure liegen. Das Application Gateway verfügt über einige coole Features wie eine zuschaltbare Web Application Firewall, SSL Offloading, URL-based content routing oder multi-site routing.

Hinweis: Trotz dieser Features ist das Azure Application Gateway noch ein sehr junger Dienst. Man merkt an einigen Stellen, dass er noch nicht ganz fertig ist. Daher gehe ich davon aus, dass die hier dargestellten Screenshots keine lange Halbwertszeit haben werden. Es ist auf jeden Fall empfehlenswert, die FAQs vorab durchzulesen.

In diesem Blogpost möchte ich mit dem Azure Application Gateway ‚nur‘ eine SSL-Website veröffentlichen, die von zwei Windows Azure VMs gehostet wird. So sieht meine Zielkonfiguration aus:

Dabei möchte ich den Dienst hierbei nicht in voller Tiefe beschreiben, gehe aber hier und da auf einige Optionen ein, wenn die Screenshots beispielsweise zu Kommentaren einladen.

Als erstes müssen wir eine neue Instanz des Azure Application Gateway Services erstellen. Ich verwende für die Einrichtung das Azure Portal, es funktioniert aber auch per Azure Ressource Manager oder PowerShell. Hierzu ein paar Hinweise für die erste Seite der Konfiguration im Azure Portal:AppGW Erstellung Seite 1

Auf der zweiten Seite zur Konfiguration des Application Gateways sind ebenfalls einige Angaben erwähnenswert:

Subnet configuration: Das Application Gateway verfügt über zwei Netzwerkverbindungen. Für die Verbindung ins interne Netzwerk muss ein leeres Subnet angegeben werden. In diesem Subnet holt sich das Application Gateway eine IP-Adresse und kommuniziert darüber mit den ‚internen‘ Azure VMs. Über diese GUI kann man kein neues Subnet erzeugen, falls man gerade kein leeres Subnet zur Hand hat. Für den Fall empfehle ich übrigens diesen Dialog geöffnet zu lassen und ein leeres Subnet mit einer anderen Instanz des Browsers zu erzeugen. Nach dem Erzeugen kann man das Subnet dann im Dialog auswählen.

Public IP address: Derzeit unterstützt das Application Gateway nur die Verwendung einer einzigen public IP-Adresse. Für die Unterstützung mehrerer Domänennamen mit SSL wird daher zwangsweise Server Name Indication (SNI) verwendet. SNI wird inzwischen von den meisten Browsern und Anwendungen unterstützt. Diese IP-Adresse ist nicht statisch! Auch wenn sie sich wahrscheinlich nur selten ändert, muss man mit DNS CNAME Einträgen arbeiten. Der DNS Name wird nach der Erstellung angezeigt und ändert sich natürlich nicht mehr.

Listener configuration: Bei der Auswahl HTTPS muss ein Zertifikat inklusive privatem Schlüssel hochgeladen werden. Dieses Zertifikat wird den Benutzern dann im Browser präsentiert. Daher sollte ein ‚öffentlich vertrautes‘ Zertifikat verwendet werden. Nachträglich können auch noch weitere SSL-Zertifikate für andere Domains hinterlegt werden. Ebenso können nachträglich HTTP Listener erzeugt werden.AppGW Erstellung Seite 2

Die Erstellung des Application Gateways dauerte bei mir etwa 20 Minuten. Das Ergebnis sieht dann so aus:AppGW Übersicht nach Erstellung

Im Hintergrund wurden einige Elemente automatisch erstellt. Unter Rules sieht man ganz gut, wie das Regelwerk des Application Gateways funktioniert. Die einzelnen Elemente schauen wir uns im Folgenden an.AppGW Rules

Ganz Mutige können unter Ignorierung sämtlicher Warnungen dann auch gleich die Public IP im Browser aufrufen. Natürlich wird eine SSL Warnung angezeigt, weil die URL noch nicht zum Zertifikat passt. 

Um die SSL-Warnung zu beseitigen, erstelle ich einen passenden DNS CNAME Eintrag für srv.msdeployment.org der auf 49ba7616-3d29-46c4-88b7-899c46843fea.cloudapp.net verweist. Damit verschwindet die SSL Warnung im Browser und es bleibt nur noch die Fehlerseite vom Application Gateway.

Dieser Fehler wird zu Recht angezeigt, weil ich bisher nur die Frontend Konfiguration durchgeführt habe und noch keine Azure VMs als Backend Pools konfiguriert habe. Dies ist jedoch schnell erledigt. Nach einem Klick auf Backend pools habe ich die Möglichkeit, entweder direkt eine Azure VM und zugehörige IP-Adresse auszuwählen, oder nur eine IP-Adresse oder FQDN anzugeben. In beiden Fällen ist es erforderlich, dass das Application Gateway Subnet das Ziel erreichen kann.

Nach dem Speichern und Übernehmen der Konfiguration kann der im Backend pool angegebene Webserver dann über das Application Gateway erreicht werden.

Die aktuelle Konfiguration des Application Gateways sieht jetzt wie folgt aus:

 

Um einen zweiten Webserver als Ziel hinzuzufügen, kann im Backend pool einfach eine weitere VM oder IP-Adresse hinzugefügt werden:

Jetzt werden beide Webserver vom Application Gateway angesprochen. Zur Überprüfung der Verfügbarkeit und ein automatisches Failover sollten noch Health Probes hinzugefügt werden. Darauf verzichte ich an dieser Stelle.

Als nächstes möchte ich noch konfigurieren, dass die Webserver per HTTPS angesprochen werden. In der aktuellen Konfiguration werden sie nur per HTTP angesprochen.

Um die Verbindung zu den Backend servern auf SSL umzustellen muss unter HTTP settings der automatisch erstellte Eintrag appGatewayBackendHttpSettings geändert werden. Um HTTPS zu aktivieren muss das Zertifikat, welches auf den Backend servern installiert wurde, hochgeladen werden. Bei dieser Zertifikatsdatei (.cer) wird jedoch nur der öffentliche Schlüssel benötigt. Durch das hochladen der Zertifikatsdatei ist es insbesondere möglich ein self-signed Zertifikat zu verwenden. Das Application Gateway benötigt hier kein ‚öffentlich vertrautes‘ Zertifikat. Allerdings müssen alle Webserver dieses Backend pools das gleiche SSL Zertifikat verwenden. Ich verwende hier das gleiche Zertifikat wie bei der Erstellung des Application Gateways. Wie aber schon geschrieben, hier nur den öffentlichen Schlüssel.

Nach Übernahme der Konfiguration wird dann auch zu den Backendservern eine Verbindung per SSL hergestellt. Dies sieht man als Benutzer der Webseite aber nicht. Lediglich aus den IIS-Logs ist es ersichtlich:

Jetzt ist die Konfiguration wie gewünscht abgeschlossen:

Wie schon Eingangs geschrieben, ist dieser Dienst noch sehr jung und wird sich bestimmt noch weiter entwickeln. Der Hauptvorteil dieses Dienstes liegt meines Erachtens darin, dass er ein PaaS Dienst ist und die Verwender sich nicht um die darunterliegenden Server und Software Gedanken machen müssen. Ich bin gespannt, wie sich dieser Dienst weiter entwickelt.

Tags: Application Gateway, Azure
Denis Holtkamp
Denis Holtkamp
Denis Holtkamp arbeitet seit 2002 bei itacs und hat sich im laufe der Zeit mit vielen verschiedenen Microsoft Technologien wie Security, Exchange, SharePoint etc... beschäftigt. Und nun vereint Office 365 und Azure fast alle diese Technologien.
Vorheriger Beitrag Cloud & Datacenter Conference Germany in München Tag 2 Nächster Beitrag 2017: Neues von Microsoft – Teil 2

Ähnliche Beiträge

Foyer Microsoft München

Cloud & Datacenter Conference Germany in München Tag 2

Mittwoch, 10. Mai 2017Tobias Fiebeler
CodeSalat

Azure AD Sync schlägt nach Änderung des UPN zu einer anderen Verbunddomäne fehl

Freitag, 6. Januar 2017Peter Ciasto

Microsoft Operations Management Suite – Monitoring aus der Cloud

Freitag, 17. März 2017Tobias Fiebeler

Neueste Beiträge

  • itacs Office 365 Backup und Archivierung
  • SharePoint Workflows starten nach Installation des .NET-Updates für CVE-2018-8421 nicht mehr
  • Office 365 DE – Nutzung der iOS Outlook App
  • Office 365 – Vergleich der Authentifizierungsoptionen
  • Office 365 DE – Anzeigefehler bei Multifaktorauthentifizierung

Themen

Active Directory AD AD FS Authentifizierung Azure Azure AD Connect Azure Stack Basic CDCGermany Compliance CU Cumulative Update DE-Cloud Digest DirSync Exchange Exchange Online Feature Pack GPO Gruppenrichtlinien Kennwortrücksetzung Lizenzierung Lizenzmodell Microsoft Monitoring NTLM OAuth Office Office 365 Office365 Office Blog OMS Operations Management Suite OutlookWebApp OWA Password Patches Reset S/Mime SAML SharePoint SharePoint 2016 System Center 2016 TMG Windows Server 2016

Ops365 – Ein Blog der itacs GmbH

Die itacs GmbH ist ein deutschlandweit tätiges IT-Beratungsunternehmen mit Hauptsitz in Berlin, das sich auf IT-Lösungen auf Basis von Microsoft Technologien spezialisiert hat.

Neueste Beiträge

  • itacs Office 365 Backup und Archivierung
  • SharePoint Workflows starten nach Installation des .NET-Updates für CVE-2018-8421 nicht mehr
  • Office 365 DE – Nutzung der iOS Outlook App

Durchsuche Ops365.de

HomeImpressumKontaktHaftungsausschlussDatenschutzLogin
itacs GmbH