Deployering af en Wildcard Azure Application Gateway ved hjælp af Powershell
Azure Application Gateway har eksisteret i en del år nu. I løbet af de sidste par år har vi set den ændre sig fra den oprindelige standard (V1) uden nogen Web Application Firewall-funktionalitet til den seneste standard (V2) med eller uden WAF-funktionalitet. V2-versionen er blevet frigivet den 30. april 2019, så den har sikkert erstattet de fleste af dine V1’er nu (eller hvis du vil starte på en frisk, er V2 nok vejen frem)
Hvordan fungerer en Application Gateway?
Som en påmindelse om, hvordan en Azure Application Gateway præcist fungerer:
Som illustreret i billedet ovenfor kan du placere en Azure Application Gateway mellem (web)klienter – f.eks. brugere, der ønsker at oprette forbindelse til dit websted – og dine backend-server(e). Traditionelle load balancers opererer på transportlaget (OSI-lag 4 – TCP og UDP) og dirigerer trafik baseret på kilde-IP-adresse og -port til en destinations-IP-adresse og -port.
Application Gateway kan træffe routing-beslutninger baseret på yderligere attributter for en HTTP-forespørgsel, f.eks. URI-sti eller værtsheadere. Du kan f.eks. dirigere trafik baseret på den indgående URL. Så hvis /images er i den indgående URL, kan du videresende trafikken til et bestemt sæt servere (kendt som en pulje), der er konfigureret til billeder. Hvis /video er i URL’en, dirigeres trafikken til en anden pool, der er optimeret til videoer.
Denne type routing er kendt som belastningsbalancering i applikationslaget (OSI-lag 7). Azure Application Gateway kan foretage URL-baseret routing og meget mere. Hvis du vil vide mere om alle de funktioner, som et program har, kan du tjekke dette websted
Nu introduceres: De af jer, der tidligere har implementeret Application Gateways, uanset om det er ved hjælp af ARM-skabeloner, Azure CLI eller Powershell, vil sandsynligvis vide, at processen med at implementere en AGW er ret besværlig, især når du ønsker at definere flere lyttere og/eller backend HTTP-indstillinger. Personligt har jeg tidligere implementeret Application Gateways, der bestod af 15 lyttere og efterfølgende backend-indstillinger, der alle endte på det samme domænenavn.
For eksempel:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Problemet med en opsætning som denne er, at det var ret meget arbejde at oprette lytterne, knytte dem til en regel, som igen er knyttet til en backend og HTTP-indstilling. Og du skulle gøre det for hvert enkelt hostnavn, du ville konfigurere, på trods af at de alle delte det samme domæne.
Men siden den 20. juli 2020 har Microsoft annonceret, at de nu også vil understøtte muligheden for at definere wildcard-hostnavne i en lytter med flere websteder. Og du kan bruge op til 5 unikke værtsnavne pr. lytter. Er det ikke fantastisk?
Så hvordan det præcist fungerer er afbilledet nedenfor:
Som du kan se på ovenstående billede, er der konfigureret flere “multi-site”-lyttere på denne applikationsgateway:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Disse lyttere kan derefter videresendes til de samme eller forskellige backend-pools.
Så ved hjælp af et wildcard-tegn i værtsnavnet kan du matche flere værtsnavne i en enkelt lytter. F.eks. kan *.contoso.com matche med ecom.contoso.com, b2b.contoso.com samt customer1.b2b.contoso.com og så videre. Ved hjælp af et array af værtsnavne kan du konfigurere mere end ét værtsnavn for en lytter for at videresende anmodninger til en backend-pool. En lytter kan f.eks. indeholde contoso.com, fabrikam.com, som vil acceptere anmodninger for begge værtsnavne.
Begrænsningerne ved wildcard-lyttere
Da wildcard-lyttere i øjeblikket stadig er i forhåndsvisning, er der nogle overvejelser og begrænsninger, der skal tages i betragtning:
1. Denne funktion er i forhåndsvisning og er kun tilgængelig for Standard_v2 og WAF_v2 SKU af Application Gateway.
2. Denne funktion er i øjeblikket kun tilgængelig via Azure PowerShell og Azure CLI. Portalunderstøttelse er snart på vej. Bemærk venligst, at eftersom portalunderstøttelse ikke er fuldt ud tilgængelig, vil lytteren, hvis du kun bruger parameteren HostNames, blive vist som en Basic-lytter i portalen, og kolonnen Host name i listen over lytterlisten vil ikke vise de værtsnavne, der er konfigureret. For alle ændringer af en wildcard-lytter skal du sørge for at bruge Azure PowerShell eller CLI, indtil det understøttes i portalen. Jeg vil dele nogle skærmbilleder vedrørende dette længere nede på denne blog.
3. Du kan ikke oprette en omdirigeringsregel med en mållytter, der bruger wildcard eller flere værtsnavne. Så du kan ikke oprette en HTTP- til HTTPS-omdirigering, som du kan i en ikke-wildcard-lytteropsætning.
4. For backend-helbredskontrol kan du ikke tilknytte flere brugerdefinerede prober pr. HTTP-indstillinger. I stedet kan du undersøge et af webstederne på backend-serveren eller bruge “127.0.0.0.1” til at undersøge backend-serverens localhost. Når du bruger jokertegn eller flere værtsnavne i en lytter, vil anmodningerne for alle de angivne domænemønstre dog blive videresendt til backend-puljen afhængigt af regeltypen (grundlæggende eller stibaseret).
5. Du kan ikke bruge et regulært udtryk til at nævne værtsnavnet. Du kan kun bruge jokertegn som asterisk (*) og spørgsmålstegn (?) til at danne værtsnavnsmønsteret.
6. Hvis flere værtsnavne er nævnt i den samme lytter, skal du uploade et SAN-certifikat (Subject Alternative Names) med CN’er, der matcher de nævnte værtsnavne.
7. Hvis det er et jokertegnsværtsnavn som *.contoso.com, skal du uploade et jokertegnscertifikat med CN som *.contoso.com
Så er det nok med teorien! Hvordan implementerer jeg?
Som nævnt tidligere, kan du på tidspunktet for at skrive denne blog enten bruge Powershell eller Azure CLI.
Jeg har bygget et powershell-eksempel, der vil gøre følgende:
1. Find det passende VNET og Subnet til at implementere AGW’en i.
2. Opret en offentlig IP-adresse, der skal bruges af AGW’en
3. Opret IP-konfigurationer for Gateway og frontend
4. Opret backend-pools
5. Opret lyttere og routingregler
6. Opret politik for webapplikationsfirewall
7. Konfigurer TLS-politikindstillinger
8. Opret applikationsgatewayen (på dette tidspunkt vil det kun være en HTTP AGW)
Når AGW’en er blevet implementeret med succes, vil scriptet tilføje HTTPS til applikationsgatewayen:
9. Find AGW’en, og gem den i en variabel
10. Tilføj SSL-certifikatet (PFX + adgangskode påkrævet), og gem det i en variabel
11. Tilføj HTTPS frontend-lytterporten, og gem den i en variabel
12. Hent frontend-IP-konfigurationen, og gem den i en variabel
13. Tilføj en frontend-lytter (HTTPS), og gem den i en variabel
14. Hent backendpool, og gem den i en variabel
15. Tilføj backend HTTP-indstillinger, og gem den i en variabel
16. Bind alt det ovenstående sammen i en rutineregel
17. Opdater Application Gateway med alt det, der er oprettet i trin 8-15.
Powershell-scriptet
Hvor du kan køre powershell-scriptet, er der et par ting, du skal gøre:
1. Log ind på Azure ved hjælp af powershell (login-azAccount)
2. Find det abonnement, som du vil distribuere til (get-azSubscription)
3. Vælg det abonnement (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Sørg for, at du har følgende oprettet et VNET og et Subnet i dit abonnement, som er i stand til at distribuere AGW’en til. Med hensyn til subnetdimensionering anbefales det at bruge et /26-subnet som minium.
5. Hvis du har et fungerende VNET og undernet, der er implementeret i en ressourcegruppe efter eget valg, skal du udfylde følgende parametre med de relevante oplysninger:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)
6. Resten af variablerne er egentlig op til dig. Fordi der kan være ting involveret som navngivningskonvention, timeout-indstillinger osv. Jeg vil ikke anbefale noget her. Mit script er baseret på en enkelt wildcard listener med en enkelt backend og nogle standard http-indstillinger, men du er velkommen til at redigere disse efter din smag.
7. Særlig opmærksomhed går ud på WAF & SSL/TLS indstillingerne. Dette script vil aktivere WAF for dig, og det vil oprette en WAF-politik i samme ressourcegruppe som Application Gateway’en vil blive implementeret i. Denne WAF-politik er derefter bundet til AGW. For SSL/TLS indstillinger aktiverer jeg den seneste forudkonfigurerede (best-practice) policysetting.
Hvad vil resultatet være?
Når du har kørt powershell-scriptet, vil du ende op med en ressourcegruppe, der har følgende ressourcer:
1. Selve applikationsgatewayen
2. En offentlig IP-adresse, der er knyttet til applikationsgatewayen
3. En brugerdefineret politik for webapplikationsfirewall, der er knyttet til applikationsgatewayen
Jeg håber, at dette indlæg hjælper dig med at implementere og konfigurere den Wildcard-applikationsgateway, som du ønsker!
Nyttige links:
Powershell-scriptet på github
Microsoft-dokumentation
Leave a Reply