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:
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.
Die Erstellung des Application Gateways dauerte bei mir etwa 20 Minuten. Das Ergebnis sieht dann so aus:
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.
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.
