Deploying a Wildcard Azure Application Gateway using Powershell
Azure Application Gateway gibt es nun schon seit einigen Jahren. In den letzten Jahren hat es sich vom ursprünglichen Standard (V1) ohne Web Application Firewall-Funktionalität zum aktuellen Standard (V2) mit oder ohne WAF-Funktionalität entwickelt. Die Version V2 wurde am 30. April 2019 veröffentlicht, so dass sie wahrscheinlich die meisten Ihrer V1 inzwischen ersetzt hat (oder wenn Sie neu anfangen wollen, ist die V2 wahrscheinlich der Weg nach vorne)
Wie funktioniert ein Application Gateway?
Nur zur Erinnerung, wie funktioniert ein Azure Application Gateway genau:
Wie in der obigen Abbildung dargestellt, können Sie ein Azure Application Gateway zwischen (Web-)Clients – zum Beispiel Benutzer, die sich mit Ihrer Website verbinden wollen – und Ihren Backend-Servern platzieren. Herkömmliche Load Balancer arbeiten auf der Transportschicht (OSI-Schicht 4 – TCP und UDP) und leiten den Datenverkehr auf der Grundlage der Quell-IP-Adresse und des Ports an eine Ziel-IP-Adresse und einen Port weiter.
Das Application Gateway kann Routing-Entscheidungen auf der Grundlage zusätzlicher Attribute einer HTTP-Anfrage treffen, z. B. URI-Pfad oder Host-Header. Sie können zum Beispiel den Datenverkehr auf der Grundlage der eingehenden URL weiterleiten. Wenn also /images in der eingehenden URL enthalten ist, können Sie den Datenverkehr an eine bestimmte Gruppe von Servern (einen so genannten Pool) weiterleiten, die für Bilder konfiguriert sind. Wenn /video in der URL enthalten ist, wird der Datenverkehr an einen anderen Pool weitergeleitet, der für Videos optimiert ist.
Diese Art des Routings wird als Lastausgleich auf Anwendungsebene (OSI-Schicht 7) bezeichnet. Azure Application Gateway kann URL-basiertes Routing und mehr. Wenn Sie mehr über alle Funktionen einer Anwendung wissen möchten, besuchen Sie bitte diese Seite
Jetzt einführen: Wildcard Application Gateway
Diejenigen unter Ihnen, die in der Vergangenheit Application Gateways bereitgestellt haben, sei es durch die Verwendung von ARM-Vorlagen, Azure CLI oder Powershell, werden wahrscheinlich wissen, dass der Prozess der Bereitstellung eines AGW ziemlich mühsam ist, insbesondere wenn Sie mehrere Listener und/oder Backend-HTTP-Einstellungen definieren möchten. Ich persönlich habe in der Vergangenheit Application Gateways bereitgestellt, die aus 15 Listenern und nachfolgenden Backend-Einstellungen bestanden, die alle auf denselben Domainnamen endeten.
Zum Beispiel:
www.contoso.com;
Contoso.com;
Mein.contoso.com;
Und so weiter.
Das Problem bei einer solchen Einrichtung ist, dass es ziemlich viel Arbeit war, die Listener zu erstellen und sie mit einer Regel zu verknüpfen, die wiederum mit einem Backend und einer HTTP-Einstellung verbunden ist. Und man musste dies für jeden einzelnen Hostnamen tun, den man konfigurieren wollte, obwohl sie alle dieselbe Domäne teilten.
Aber seit dem 20. Juli 2020 hat Microsoft angekündigt, dass sie nun auch die Möglichkeit unterstützen werden, Wildcard-Hostnamen in einem Multi-Site-Listener zu definieren. Und Sie können bis zu 5 eindeutige Hostnamen pro Listener verwenden. Ist das nicht großartig?
Wie das genau funktioniert, ist unten abgebildet:
Wie Sie im obigen Bild sehen können, sind auf diesem Application Gateway mehrere ‚Multi-Site‘ Listener konfiguriert:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Diese Listener können dann an denselben oder an verschiedene Backend-Pools weitergeleitet werden.
So können Sie mit einem Platzhalterzeichen im Hostnamen mehrere Hostnamen in einem einzigen Listener abgleichen. Beispielsweise kann *.contoso.com mit ecom.contoso.com, b2b.contoso.com sowie customer1.b2b.contoso.com übereinstimmen und so weiter. Mit einem Array von Hostnamen können Sie mehr als einen Hostnamen für einen Listener konfigurieren, um Anforderungen an einen Backend-Pool weiterzuleiten. Ein Listener kann zum Beispiel contoso.com und fabrikam.com enthalten, der Anforderungen für beide Hostnamen akzeptiert.
Die Einschränkungen von Wildcard-Listenern
Da sich Wildcard-Listener derzeit noch in der Vorschau befinden, sind einige Überlegungen und Einschränkungen zu berücksichtigen:
1. Diese Funktion befindet sich in der Vorschau und ist nur für Standard_v2 und WAF_v2 SKU von Application Gateway verfügbar.
2. Diese Funktion ist derzeit nur über Azure PowerShell und Azure CLI verfügbar. Die Portalunterstützung ist in Kürze verfügbar. Bitte beachten Sie, dass die Portalunterstützung noch nicht vollständig verfügbar ist. Wenn Sie nur den Parameter „HostNames“ verwenden, wird der Listener im Portal als Basis-Listener angezeigt und die Spalte „Hostname“ der Listener-Listenansicht zeigt nicht die konfigurierten Hostnamen an. Stellen Sie sicher, dass Sie für alle Änderungen an einem Wildcard-Listener die Azure PowerShell oder CLI verwenden, bis sie im Portal unterstützt werden. Ich werde weiter unten in diesem Blog einige Screenshots dazu veröffentlichen.
3. Sie können keine Umleitungsregel mit einem Ziel-Listener erstellen, der Platzhalter oder mehrere Hostnamen verwendet. Sie können also keine HTTP-zu-HTTPS-Umleitung erstellen, wie Sie es bei einem Nicht-Wildcard-Listener-Setup können.
4. Für die Backend-Zustandsprüfung können Sie nicht mehrere benutzerdefinierte Sonden pro HTTP-Einstellungen zuordnen. Stattdessen können Sie eine der Websites am Backend prüfen oder „127.0.0.1“ verwenden, um den Localhost des Backend-Servers zu prüfen. Wenn Sie jedoch Wildcards oder mehrere Hostnamen in einem Listener verwenden, werden die Anfragen für alle angegebenen Domänenmuster je nach Regeltyp (einfach oder pfadbasiert) an den Backend-Pool weitergeleitet.
5. Sie können keinen regulären Ausdruck verwenden, um den Hostnamen anzugeben. Sie können nur Platzhalterzeichen wie Sternchen (*) und Fragezeichen (?) verwenden, um das Hostnamenmuster zu bilden.
6. Wenn mehrere Hostnamen im selben Listener erwähnt werden, müssen Sie ein SAN-Zertifikat (Subject Alternative Names) mit den CNs hochladen, die mit den erwähnten Hostnamen übereinstimmen.
7. Wenn es sich um einen Platzhalter-Hostnamen wie *.contoso.com handelt, müssen Sie ein Platzhalter-Zertifikat mit CN wie *.contoso.com hochladen
Genug der Theorie! Wie stelle ich bereit?
Wie bereits erwähnt, können Sie zum Zeitpunkt des Schreibens dieses Blogs entweder Powershell oder Azure CLI verwenden.
Ich habe ein Powershell-Beispiel erstellt, das Folgendes tut:
1. Finden Sie das passende VNET und Subnetz, in dem Sie den AGW bereitstellen möchten.
2. Erstellen Sie eine öffentliche IP-Adresse, die vom AGW verwendet werden soll
3. Erstellen Sie IP-Konfigurationen für das Gateway und das Frontend
4. Erstellen Sie Backend-Pools
5. Listener und Routing-Regeln erstellen
6. Web Application Firewall-Richtlinie erstellen
7. TLS-Richtlinieneinstellungen konfigurieren
8. Das Anwendungs-Gateway erstellen (zu diesem Zeitpunkt wird es ein reines HTTP-AGW sein)
Nachdem das AGW erfolgreich eingesetzt wurde, wird das Skript HTTPS zum Anwendungs-Gateway hinzufügen:
9. Suchen Sie die AGW und speichern Sie sie in einer Variablen
10. Fügen Sie das SSL-Zertifikat hinzu (PFX + Passwort erforderlich) und speichern Sie es in einer Variablen
11. Fügen Sie den HTTPS-Frontend-Listener-Port hinzu und speichern Sie ihn in einer Variablen
12. Ermitteln Sie die Frontend-IP-Konfiguration und speichern Sie sie in einer Variablen
13. Fügen Sie einen Frontend-Listener (HTTPS) hinzu und speichern Sie ihn in einer Variablen
14. Hole den Backendpool und speichere ihn in einer Variablen
15. Füge die Backend-HTTP-Einstellungen hinzu und speichere sie in einer Variablen
16. Binden Sie alles oben genannte in einer Routing-Regel zusammen
17. Aktualisieren Sie das Application Gateway mit allem, was in den Schritten 8-15 erstellt wurde.
Das Powershell-Skript
Bevor Sie das Powershell-Skript ausführen können, müssen Sie einige Dinge tun:
1. Melden Sie sich mit der Powershell bei Azure an (login-azAccount)
2. Suchen Sie das Abonnement, in das Sie das AGW bereitstellen möchten (get-azSubscription)
3. Wählen Sie dieses Abonnement aus (select-azsubscription -subscription „SUBSCRIPTIONNAME“)
4. Stellen Sie sicher, dass Sie ein VNET und ein Subnetz in Ihrem Abonnement erstellt haben, in das Sie das AGW bereitstellen können. Für die Größe des Subnetzes wird als Minimum ein /26-Subnetz empfohlen.
5. Wenn Sie über ein funktionierendes VNET und Subnetze verfügen, die in einer Ressourcengruppe Ihrer Wahl bereitgestellt werden, füllen Sie die folgenden Parameter mit den entsprechenden Informationen:
– Name der Ressourcengruppe des virtuellen Netzwerks ($VnetRGName)
– Name des virtuellen Netzwerks ($VnetName)
– Name des Subnetzes ($SubnetName)
6. Der Rest der Variablen ist wirklich Ihnen überlassen. Denn es könnten Dinge wie Namenskonventionen, Timeout-Einstellungen usw. eine Rolle spielen. Ich werde hier keine Empfehlungen aussprechen. Mein Skript basiert auf einem einzigen Wildcard-Listener mit einem einzigen Backend und einigen Standard-Http-Einstellungen, aber Sie können diese nach Belieben ändern.
7. Besondere Aufmerksamkeit gilt den WAF & SSL/TLS-Einstellungen. Dieses Skript aktiviert WAF für Sie und erstellt eine WAF-Richtlinie in derselben Ressourcengruppe, in der auch das Application Gateway bereitgestellt wird. Diese WAF-Richtlinie ist dann mit dem AGW verbunden. Für die SSL/TLS-Einstellungen aktiviere ich die neueste vorkonfigurierte (bewährte) Richtlinieneinstellung.
Was wird das Ergebnis sein?
Nachdem Sie das Powershell-Skript ausgeführt haben, erhalten Sie eine Ressourcengruppe mit den folgenden Ressourcen:
1. Das Application Gateway selbst
2. Eine öffentliche IP-Adresse, die an das Application Gateway gebunden ist
3. Eine benutzerdefinierte Web Application Firewall-Richtlinie, die an das Application Gateway gebunden ist
Ich hoffe, dieser Beitrag hilft Ihnen bei der Bereitstellung und Konfiguration des gewünschten Wildcard Application Gateways!
Nützliche Links:
Das Powershell-Skript auf github
Microsoft-Dokumentation
Leave a Reply