Distribution av en Wildcard Azure Application Gateway med Powershell
Azure Application Gateway har funnits i ganska många år nu. Under de senaste åren har vi sett den förändras från den ursprungliga standarden (V1) utan funktionalitet för Web Application Firewall till den senaste standarden (V2) med eller utan WAF-funktionalitet. V2-versionen släpptes den 30 april 2019 så den har förmodligen ersatt de flesta av dina V1:or vid det här laget (eller om du vill börja om på nytt är V2 förmodligen vägen framåt)
Hur fungerar en Application Gateway?
Vi vill bara påminna om hur en Azure Application Gateway fungerar:
Som illustreras i bilden ovan kan du placera en Azure Application Gateway mellan (webb)klienter – till exempel användare som vill ansluta till din webbplats – och dina backend-servrar. Traditionella lastutjämnare arbetar på transportlagret (OSI-lager 4 – TCP och UDP) och dirigerar trafik baserat på källans IP-adress och port till en destinations-IP-adress och port.
Application Gateway kan fatta beslut om omdirigering baserat på ytterligare attribut för en HTTP-förfrågan, till exempel URI-sökväg eller värdhuvud. Du kan till exempel dirigera trafik baserat på den inkommande URL:en. Om /images finns i den inkommande URL:en kan du dirigera trafiken till en specifik uppsättning servrar (en så kallad pool) som är konfigurerade för bilder. Om /video finns i URL:n dirigeras trafiken till en annan pool som är optimerad för videor.
Den här typen av dirigering kallas lastbalansering på applikationsnivå (OSI-lager 7). Azure Application Gateway kan göra URL-baserad routning med mera. Om du vill veta mer om alla funktioner som ett program har kan du kolla in den här webbplatsen
Nu introduceras: De av er som har distribuerat Application Gateways tidigare, oavsett om det är genom användning av ARM-mallar, Azure CLI eller Powershell, vet förmodligen att processen att distribuera en AGW är ganska besvärlig, särskilt när du vill definiera flera lyssnare och/eller HTTP-inställningar för backend. Personligen har jag tidigare distribuerat Application Gateways som bestod av 15 lyssnare och efterföljande backend-inställningar, som alla slutade på samma domännamn.
Till exempel:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Problemet med en sådan inställning är att det var ganska mycket arbete att skapa lyssnarna, associera dem till en regel som i sin tur är associerad till en backend och HTTP-inställning. Och du var tvungen att göra det för varje enskilt värdnamn du ville konfigurera, trots att de alla delade samma domän.
Men sedan den 20 juli 2020 har Microsoft meddelat att de nu också kommer att stödja möjligheten att definiera värdnamn med jokertecken i en lyssnare med flera platser. Och du kan använda upp till 5 unika värdnamn per lyssnare. Är inte det fantastiskt?
Så hur det exakt fungerar visas nedan:
Som du kan se i bilden ovan finns det flera lyssnare med flera platser som är konfigurerade på den här applikationsgatewayen:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Dessa lyssnare kan sedan dirigeras till samma eller olika backendpooler.
Med hjälp av ett jokertecken i värddatornamnet kan du matcha flera värddatornamn i en enda lyssnare. Till exempel kan *.contoso.com matcha med ecom.contoso.com, b2b.contoso.com samt customer1.b2b.contoso.com och så vidare. Med hjälp av en array av värdnamn kan du konfigurera mer än ett värdnamn för en lyssnare för att dirigera förfrågningar till en backendpool. Till exempel kan en lyssnare innehålla contoso.com, fabrikam.com som kommer att acceptera förfrågningar för båda värdnamnen.
Varningar om wildcard-lyssnare
Med tanke på att wildcard-lyssnare för närvarande fortfarande är i förhandsgranskning finns det några överväganden och begränsningar att ta hänsyn till:
1. Den här funktionen är i förhandsgranskning och är endast tillgänglig för Standard_v2 och WAF_v2 SKU av Application Gateway.
2. Den här funktionen är för närvarande endast tillgänglig via Azure PowerShell och Azure CLI. Portalstöd kommer snart. Observera att eftersom portalstödet inte är helt tillgängligt, om du endast använder parametern HostNames, kommer lyssnaren att visas som en Basic-lyssnare i portalen och kolumnen Värdnamn i listvyn för lyssnaren kommer inte att visa de konfigurerade värdnamnen. För alla ändringar av en wildcard-lyssnare, se till att du använder Azure PowerShell eller CLI tills det stöds i portalen. Jag kommer att dela några skärmdumpar angående detta längre ner i den här bloggen.
3. Du kan inte skapa en omdirigeringsregel med en mållyssnare som använder wildcard eller flera värdnamn. Du kan alltså inte skapa en HTTP- till HTTPS-omdirigering som du kan göra med en lyssnar utan wildcard.
4. För hälsokontroll av backend kan du inte associera flera anpassade prober per HTTP-inställningar. I stället kan du undersöka en av webbplatserna på baksidan eller använda ”127.0.0.0.1” för att undersöka baksideserverens localhost. När du använder jokertecken eller flera värdnamn i en lyssnare kommer dock förfrågningarna för alla angivna domänmönster att dirigeras till backendpoolen beroende på regeltypen (grundläggande eller sökvägsbaserad).
5. Du kan inte använda ett reguljärt uttryck för att nämna värdnamnet. Du kan bara använda jokertecken som asterisk (*) och frågetecken (?) för att bilda värdnamnsmönstret.
6. Om flera värdnamn nämns i samma lyssnare måste du ladda upp ett SAN-certifikat (Subject Alternative Names) med CN som matchar de värdnamn som nämns.
7. Om det är ett värdnamn med jokertecken, t.ex. *.contoso.com, måste du ladda upp ett certifikat med jokertecken med CN som *.contoso.com
Slut med teorin! Hur distribuerar jag?
Som tidigare nämnts kan du när den här bloggen skrivs antingen använda Powershell eller Azure CLI.
Jag har byggt ett Powershell-exempel som gör följande:
1. Hitta det lämpliga VNET och subnätet att distribuera AGW i.
2. Skapa en offentlig IP-adress som ska användas av AGW
3. Skapa IP-konfigurationer för Gateway och frontend
4. Skapa backend-pooler
5. Skapa lyssnare och routningsregler
6. Skapa en policy för brandväggen för webbapplikationer
7. Konfigurera TLS-principinställningar
8. Skapa applikationsgatewayen (i detta skede kommer det att vara en AGW som endast är HTTP-anpassad)
När AGW:n har installerats med framgång kommer skriptet att lägga till HTTPS till applikationsgatewayen:
9. Hitta AGW och lagra den i en variabel
10. Lägg till SSL-certifikatet (PFX + lösenord krävs) och lagra det i en variabel
11. Lägg till HTTPS-frontend-lyssnarporten och lagra den i en variabel
12. Hämta IP-konfigurationen för frontenden och lagra den i en variabel
13. Lägg till en lyssnare för frontend (HTTPS) och lagra den i en variabel
14. Hämta backendpool och lagra den i en variabel
15. Lägg till Backend HTTP-inställningar och lagra den i en variabel
16. Knyt ihop allt ovanstående i en routningsregel
17. Uppdatera Application Gateway med allt som skapats i steg 8-15.
Powershellskriptet
För att du ska kunna köra powershellskriptet finns det några saker du måste göra:
1. Logga in på Azure med powershell (login-azAccount)
2. Hitta den prenumeration som du vill distribuera till (get-azSubscription)
3. Välj den prenumerationen (select-azsubscription -subscription ”SUBSCRIPTIONNAME”)
4. Kontrollera att du har skapat ett VNET och ett Subnet i din prenumeration, som du kan distribuera AGW till. När det gäller storleken på undernätet rekommenderas att använda ett /26-undernät som minimum.
5. Om du har ett fungerande VNET och undernät som distribueras i en resursgrupp som du väljer fyller du följande parametrar med lämplig information:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)
6. Resten av variablerna är egentligen upp till dig. Eftersom det kan finnas saker inblandade som namnkonvention, inställningar för timeout osv. Jag kommer inte att rekommendera något här. Mitt skript bygger på en enda wildcard-lyssnare med en enda backend och några standardinställningar för http, men du får gärna redigera dessa efter dina önskemål.
7. Särskild uppmärksamhet går till WAF & SSL/TLS-inställningarna. Det här skriptet aktiverar WAF åt dig och skapar en WAF-policy i samma resursgrupp som Application Gateway kommer att distribueras i. Denna WAF-policy är sedan knuten till AGW. För SSL/TLS-inställningar aktiverar jag den senaste förkonfigurerade (bästa praxis) policysetting.
Vad blir resultatet?
När du har kört powershellskriptet kommer du att få en resursgrupp som har följande resurser:
1. Själva applikationsgatewayen
2. En offentlig IP-adress som är knuten till applikationsgatewayen
3. En anpassad brandväggspolicy för webbapplikationer som är knuten till applikationsgatewayen
Jag hoppas att det här inlägget hjälper dig att distribuera och konfigurera Wildcard-applikationsgatewayen som du vill ha!
Användbara länkar:
Powershell-skriptet på github
Microsoftdokumentation
Leave a Reply