Deploying a Wildcard Azure Application Gateway using Powershell

Jorrit Meijer
Jorrit Meijer

Follow

19. října, 2020 – 7 minut čtení

Azure Application Gateway existuje již pěknou řádku let. Za posledních několik let jsme byli svědky její změny z původního standardu (V1) bez funkcí brány Web Application Firewall na nejnovější standard (V2) s funkcemi WAF nebo bez nich. Verze v2 byla vydána 30. dubna 2019, takže pravděpodobně již nahradila většinu vašich V1 (nebo pokud chcete začít znovu, je V2 pravděpodobně tou správnou cestou)

Logo Azure Application Gateway

Jak Application Gateway funguje?

Jen pro připomenutí, jak přesně funguje aplikační brána Azure:

Azure Application Gateway

Jak je znázorněno na obrázku výše, můžete umístit Azure Application Gateway mezi (webové)klienty – například uživatele, kteří se chtějí připojit k vašim webovým stránkám – a váš backendový server(y). Tradiční load balancery pracují na transportní vrstvě (4. vrstva OSI – TCP a UDP) a směrují provoz na základě zdrojové IP adresy a portu na cílovou IP adresu a port.

Aplikační brána může rozhodovat o směrování na základě dalších atributů požadavku HTTP, například cesty URI nebo hlavičky hostitele. Můžete například směrovat provoz na základě příchozí adresy URL. Pokud je tedy v příchozí adrese URL uvedeno /images, můžete provoz směrovat na určitou sadu serverů (tzv. pool) nakonfigurovaných pro obrázky. Pokud je v adrese URL uvedeno /video, bude tento provoz směrován na jiný pool optimalizovaný pro videa.

Tento typ směrování je známý jako vyrovnávání zátěže na aplikační vrstvě (vrstva OSI 7). Aplikační brána Azure umí provádět směrování na základě adresy URL a další funkce. Pokud se chcete dozvědět více o všech funkcích, které aplikace má, podívejte se na tuto stránku

Nyní představujeme: Pro ty z vás, kteří v minulosti nasazovali aplikační brány, ať už pomocí šablon ARM, rozhraní Azure CLI nebo prostředí Powershell, pravděpodobně víte, že proces nasazení brány AGW je poměrně těžkopádný, zejména pokud chcete definovat více posluchačů a/nebo nastavení HTTP backendu. Osobně jsem v minulosti nasazoval aplikační brány, které se skládaly z 15 posluchačů a následných nastavení backendu, přičemž všechny končily na stejném doménovém jménu.
Například:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.

Problém s takovým nastavením spočíval v tom, že bylo poměrně hodně práce s vytvářením posluchačů, jejich přiřazením k pravidlu, které je následně přiřazeno k backendu a nastavení HTTP. A to jste museli pro každý jednotlivý hostitelský název, který jste chtěli nakonfigurovat, přestože všechny sdílely stejnou doménu.

Od 20. července 2020 však Microsoft oznámil, že nyní bude podporovat také možnost definovat hostitelské názvy se zástupnými znaky ve vícemístném posluchači. A můžete použít až 5 jedinečných názvů hostitelů na jeden posluchač. Není to skvělé?“

Jak to tedy přesně funguje, je znázorněno na obrázku níže:

Wildcard Application Gateway

Jak vidíte na výše uvedeném obrázku, na této aplikační bráně je nakonfigurováno více „multi-site“ posluchačů:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Tyto posluchače pak lze směrovat na stejné nebo různé backendové pooly.
Pomocí zástupného znaku v názvu hostitele lze tedy v jednom posluchači přiřadit více názvů hostitelů. Například *.contoso.com může odpovídat ecom.contoso.com, b2b.contoso.com i customer1.b2b.contoso.com atd. Pomocí pole názvů hostitelů můžete nakonfigurovat více než jeden název hostitele pro posluchače a směrovat tak požadavky do backendového fondu. Posluchač může například obsahovat contoso.com, fabrikam.com, který bude přijímat požadavky pro oba názvy hostitelů.

Úskalí poslouchání se zástupnými znaky

Protože poslouchání se zástupnými znaky je v současné době stále v předběžném náhledu, je třeba vzít v úvahu některá hlediska a omezení:
1. Tato funkce je ve fázi předběžného náhledu a je dostupná pouze pro SKU aplikační brány Standard_v2 a WAF_v2.

2. Tato funkce je v současné době dostupná pouze prostřednictvím prostředí Azure PowerShell a Azure CLI. Podpora portálu se objeví již brzy. Upozorňujeme, že vzhledem k tomu, že podpora portálu není plně k dispozici, pokud používáte pouze parametr HostNames, bude se posluchač na portálu zobrazovat jako základní posluchač a ve sloupci Host Name v zobrazení seznamu posluchačů se nebudou zobrazovat nakonfigurované názvy hostitelů. Při jakýchkoli změnách v posluchači se zástupnými znaky se ujistěte, že používáte prostředí Azure PowerShell nebo CLI, dokud nebude portál tuto funkci podporovat. O snímky obrazovky týkající se této záležitosti se podělím dále v tomto blogu.

3. Nelze vytvořit pravidlo přesměrování s cílovým posluchačem, který používá zástupný znak nebo více názvů hostitelů. Nemůžete tedy vytvořit přesměrování z HTTP na HTTPS, jako to můžete udělat v nastavení posluchače bez divokých karet.

4. Pro kontrolu stavu backendu nelze přiřadit více vlastních sond na nastavení HTTP. Místo toho můžete sondovat jednu z webových stránek na backendu nebo použít „127.0.0.1“ pro sondování localhostu backendového serveru. Pokud však v posluchači používáte zástupný znak nebo více názvů hostitelů, budou požadavky pro všechny zadané vzory domén směrovány do backendového fondu v závislosti na typu pravidla (základní nebo založené na cestě).

5. Při použití zástupného symbolu nebo více názvů hostitelů v posluchači budou požadavky pro všechny zadané vzory domén směrovány do backendového fondu. Pro uvedení názvu hostitele nelze použít regulární výraz. Pro vytvoření vzoru názvu hostitele můžete použít pouze zástupné znaky, jako je hvězdička (*) a otazník (?).

6. Pokud je ve stejném posluchači uvedeno více názvů hostitelů, musíte nahrát certifikát SAN (Subject Alternative Names) s CN odpovídajícími uvedeným názvům hostitelů.

7. Pokud se jedná o zástupný název hostitele, například *.contoso.com, musíte nahrát zástupný certifikát s CN, například *.contoso.com

Dost bylo teorie! Jak nasadit certifikát?

Jak již bylo zmíněno, v době psaní tohoto blogu můžete použít buď prostředí Powershell, nebo Azure CLI.

Sestavil jsem příklad prostředí Powershell, který provede následující:
1. Najděte vhodnou síť VNET a podsíť pro nasazení zařízení AGW.
2. Vytvořte veřejnou adresu IP, kterou bude používat zařízení AGW
3. Vytvořte konfigurace IP pro bránu a frontend
4. Vytvořte backend-pooly
5. Vytvořte konfigurace IP pro bránu a frontend. Vytvoření posluchačů a směrovacích pravidel
6. Vytvoření zásad brány Web Application Firewall
7. Konfigurace nastavení zásad TLS
8. Vytvoření aplikační brány (v tomto okamžiku to bude AGW pouze pro HTTP)

Poté, co bude AGW úspěšně nasazen, skript přidá do aplikační brány HTTPS:

9. Vytvoření aplikační brány. Najděte AGW a uložte jej do proměnné
10. Přidejte certifikát SSL (vyžaduje se PFX + heslo) a uložte jej do proměnné
11. Přidejte port frontendového posluchače HTTPS a uložte jej do proměnné
12. Získejte konfiguraci IP adresy frontend a uložte ji do proměnné
13. Přidejte frontendový posluchač (HTTPS) a uložte jej do proměnné
14. Získejte backendpool a uložte jej do proměnné
15. Přidejte nastavení backendu HTTP a uložte jej do proměnné
16. Svažte vše výše uvedené dohromady do směrovacího pravidla
17. Aktualizujte aplikační bránu se vším, co bylo vytvořeno v krocích 8-15.

Skript prostředí powershell

Před spuštěním skriptu prostředí powershell je třeba udělat několik věcí:

1. Zkontrolujte, zda je skript prostředí powershell v pořádku. Přihlaste se do Azure pomocí prostředí powershell (login-azAccount)

2. Najděte odběr, do kterého chcete nasadit (get-azSubscription)

3. Vyberte tento odběr (select-azsubscription -subscription „SUBSCRIPTIONNAME“)

4. Ujistěte se, že máte v odběru vytvořeny následující položky VNET a Subnet, do kterých je možné nasadit AGW. Pro určení velikosti podsítě se doporučuje jako minium použít podsíť /26.

5. V případě, že se jedná o podsíť s velikostí /26, doporučujeme použít podsíť s velikostí /26. Pokud máte funkční VNET a podsítě nasazené do vámi zvolené skupiny prostředků, vyplňte následující parametry příslušnými informacemi:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)

6. Zbytek proměnných je opravdu na vás. Protože s tím mohou být spojeny věci jako konvence pojmenování, nastavení časového limitu atd. Nebudu zde nic doporučovat. Můj skript je založen na jednom wildcard listeneru s jedním backendem a několika výchozími nastaveními http, ale klidně si je upravte podle svých představ.

7. Zvláštní pozornost věnuji nastavení WAF & SSL/TLS. Tento skript vám povolí WAF a vytvoří politiku WAF ve stejné skupině prostředků, v jaké bude nasazena aplikační brána. Tato zásada WAF je pak svázána s AGW. Pro nastavení SSL/TLS povolím nejnovější předkonfigurované (best-practice) nastavení politik.

Jaký bude výsledek?

Po spuštění skriptu prostředí powershell skončíte se skupinou prostředků, která bude obsahovat následující prostředky:

Přidělené prostředky

1. Samotná aplikační brána
2. Veřejná IP adresa, která je svázána s aplikační bránou
3. Vlastní zásady brány firewall pro webové aplikace, které jsou svázány s aplikační bránou

Doufám, že vám tento příspěvek pomůže nasadit a nakonfigurovat požadovanou aplikační bránu Wildcard!

Užitečné odkazy:
Skript Powershell na githubu
Dokumentace společnosti Microsoft

.

Leave a Reply