Deploying a Wildcard Azure Application Gateway using Powershell
Azure Application Gateway már jó néhány éve létezik. Az elmúlt évek során az eredeti, webalkalmazás-tűzfal funkciót nem tartalmazó Standardtól (V1) a legfrissebb Standard (V2) WAF-funkcióval vagy anélkül változott. A v2 verzió 2019. április 30-án jelent meg, így valószínűleg mostanra már a legtöbb V1-et lecserélte (vagy ha újrakezdené, valószínűleg a V2 a megfelelő megoldás)
Hogyan működik egy Application Gateway?
Emlékeztetésképpen: hogyan is működik pontosan egy Azure Application Gateway:
A fenti képen látható módon egy Azure Application Gateway-t helyezhet el a (web)ügyfelek – például a webhelyéhez csatlakozni kívánó felhasználók – és a backend-kiszolgáló(k) között. A hagyományos terheléselosztók a szállítási szinten (OSI 4. réteg – TCP és UDP) működnek, és a forgalmat a forrás IP-cím és port alapján egy cél IP-címre és portra irányítják.
Az Application Gateway képes a HTTP-kérés további attribútumai, például az URI-útvonal vagy az állomás fejlécek alapján útválasztási döntéseket hozni. A forgalmat például a bejövő URL-cím alapján is továbbíthatja. Így ha a bejövő URL-ben a /images szerepel, akkor a forgalmat a képekhez konfigurált kiszolgálók egy meghatározott csoportjára (ún. pool) irányíthatja. Ha az URL-ben a /video szerepel, akkor a forgalom egy másik, videókra optimalizált poolra kerül átirányításra.
Ez a fajta átirányítás az alkalmazási réteg (OSI 7. réteg) terheléselosztásaként ismert. Az Azure Application Gateway többek között URL-alapú útválasztást is végezhet. Ha többet szeretne megtudni egy alkalmazás összes funkciójáról, kérjük, nézze meg ezt az oldalt
Most bevezetjük: Wildcard Application Gateway
Azok, akik korábban már telepítettek Application Gatewayeket, akár ARM sablonok, Azure CLI vagy Powershell segítségével, valószínűleg tudják, hogy egy AGW telepítésének folyamata meglehetősen nehézkes, különösen akkor, ha több hallgatót és/vagy backend HTTP-beállításokat akarnak definiálni. Személy szerint én a múltban olyan alkalmazáskapukat telepítettem, amelyek 15 hallgatóból és az azt követő backend-beállításokból álltak, és mind ugyanarra a domainnévre végződtek.
Például:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
A probléma egy ilyen beállítással az volt, hogy elég sok munkát jelentett a listenerek létrehozása, a szabályhoz való társításuk, ami viszont a backendhez és a HTTP-beállításhoz kapcsolódik. És ezt minden egyes hosztnévnél meg kellett tenned, amit be akartál állítani, annak ellenére, hogy mindegyik ugyanazt a tartományt használta.
De 2020. július 20-tól a Microsoft bejelentette, hogy mostantól támogatni fogja a vadkártyás hosztnevek definiálásának lehetőségét is egy többhelyszínes listenerben. És hallgatónként legfeljebb 5 egyedi hostnevet használhat. Hát nem nagyszerű?
Az, hogy ez pontosan hogyan működik, az alábbi képen látható:
Amint a fenti képen látható, ezen az alkalmazáskapun több “multi-site” listener van konfigurálva:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Ezek a hallgatók azután ugyanazon vagy különböző backend-poolokhoz irányíthatók.
Az állomásnévben szereplő joker karakter használatával tehát egyetlen hallgatóban több állomásnevet is egyeztethet. Például a *.contoso.com megfeleltethető az ecom.contoso.com, b2b.contoso.com, valamint a customer1.b2b.contoso.com és így tovább. Az állomásnevek tömbjének használatával egynél több állomásnevet is beállíthat egy hallgatóhoz, hogy a kéréseket egy háttértárkészlethez irányítsa. Például egy figyelő tartalmazhatja a contoso.com, fabrikam.com címeket, amely mindkét állomásnévre vonatkozó kéréseket elfogadja.
A vadkártyás figyelők fenntartásai
Mivel a vadkártyás figyelők jelenleg még csak előnézetben vannak, figyelembe kell venni néhány megfontolást és korlátozást:
1. Ez a funkció előnézetben van, és csak az Application Gateway Standard_v2 és WAF_v2 SKU-hoz érhető el.
2. Ez a funkció jelenleg csak az Azure PowerShell és Azure CLI segítségével érhető el. A portáltámogatás hamarosan megjelenik. Felhívjuk figyelmét, hogy mivel a portáltámogatás még nem érhető el teljes mértékben, ha csak a HostNames paramétert használja, a figyelő Basic figyelőként fog megjelenni a portálon, és a figyelőlista nézetének Host name oszlopa nem fogja mutatni a konfigurált hostneveket. A wildcard listener bármilyen módosításához mindenképpen használja az Azure PowerShellt vagy a CLI-t, amíg a portál nem támogatja azt. A blog további részében megosztok néhány képernyőképet ezzel kapcsolatban.
3. Nem hozhat létre átirányítási szabályt olyan célhallgatóval, amely vadkártyát vagy több állomásnevet használ. Így nem hozhat létre HTTP-ről HTTPS-re történő átirányítást, mint egy nem vadkártyás figyelő beállításánál.
4. A backend állapotellenőrzéshez nem társíthat több egyéni szondát HTTP-beállításonként. Ehelyett a backend egyik webhelyét vizsgálhatja meg, vagy a “127.0.0.1” használatával a backend-kiszolgáló localhostját vizsgálhatja meg. Ha azonban egy figyelőben wildcardot vagy több állomásnevet használ, akkor a megadott tartományminták összes kérése a szabály típusától függően (alap vagy útvonal alapú) a backend-poolba kerül átirányításra.
5. Az állomásnév megemlítésére nem használhat reguláris kifejezést. A hosztnévminta megformálásához csak helyettesítő karaktereket, például csillagot (*) és kérdőjelet (?) használhat.
6. Ha több hosztnév szerepel ugyanabban a hallgatóban, akkor SAN-tanúsítványt (Subject Alternative Names) kell feltöltenie az említett hosztneveknek megfelelő CN-ekkel.
7. Ha ez egy helyettesítő hosztnév, például *.contoso.com, akkor egy helyettesítő tanúsítványt kell feltöltenie CN-vel, például *.contoso.com
Elég az elméletből! Hogyan kell telepíteni?
Mint már említettem, a blog írásának idején vagy a Powershell vagy az Azure CLI felhasználója lehet.
Elkészítettem egy powershell példát, amely a következőket teszi:
1. Keresse meg a megfelelő VNET-et és alhálózatot az AGW telepítéséhez.
2. Hozzon létre egy nyilvános IP-címet, amelyet az AGW használhat
3. Hozzon létre IP-konfigurációkat az átjáróhoz és a frontendhez
4. Hozzon létre backend-poolokat
5. Hallgatók és útválasztási szabályok létrehozása
6. Webalkalmazás-tűzfal házirend létrehozása
7. TLS házirend beállításainak konfigurálása
8. Az alkalmazás-átjáró létrehozása (ezen a ponton ez egy csak HTTP-s AGW lesz)
Az AGW sikeres telepítése után a szkript hozzáadja a HTTPS-t az alkalmazás-átjáróhoz:
9. Keresse meg az AGW-t és tárolja egy változóban
10. Adja hozzá az SSL-tanúsítványt (PFX + jelszó szükséges), és tárolja egy változóba
11. Adjuk hozzá a HTTPS frontend listener portját, és tároljuk egy változóban
12. Szerezze be a frontend IP-konfigurációját, és tárolja egy változóba
13. Adjunk hozzá egy frontend listenert (HTTPS), és tároljuk egy változóba
14. Szerezzük meg a backendpoolt és tároljuk egy változóba
15. Backend HTTP beállítások hozzáadása és tárolása egy változóba
16. Kössük össze a fentieket egy útválasztási szabályban
17. Frissítse az alkalmazás-átjárót mindazzal, amit a 8-15. lépésben létrehozott.
A powershell-szkript
A powershell-szkript futtatása előtt néhány dolgot el kell végeznie:
1. Jelentkezzen be az Azure-ra a powershell segítségével (login-azAccount)
2. Keresse meg azt az előfizetést, amelybe telepíteni szeretne (get-azSubscription)
3. Válassza ki ezt az előfizetést (select-azsubscription -subscription “SUBSCRIPTIONNAME”)
4. Győződjön meg róla, hogy az alábbiakban létrehozott egy VNET-et és Subnetet az előfizetésében, amely alkalmas az AGW telepítésére. Az alhálózat méretezéséhez minimumként egy /26-os alhálózat használata ajánlott.
5. Ha rendelkezik egy működő VNET-tel és alhálózatokkal, amelyeket egy Ön által választott erőforráscsoportba telepített, töltse ki a következő paramétereket a megfelelő információkkal:
– Virtuális hálózat erőforráscsoport neve ($VnetRGName)
– Virtuális hálózat neve ($VnetName)
– alhálózat neve ($SubnetName)
6. A többi változót valójában Önre bízza. Mert lehetnek olyan dolgok, mint a névadási konvenció, timeout beállítások stb. Itt nem fogok ajánlani semmit. Az én szkriptem egyetlen wildcard listenerre épül egyetlen backenddel és néhány alapértelmezett http beállítással, de ezeket nyugodtan szerkesztheted tetszésed szerint.
7. Külön figyelmet érdemel a WAF & SSL/TLS beállítások. Ez a szkript engedélyezi a WAF-ot az Ön számára, és létrehoz egy WAF-házirendet ugyanabban az erőforráscsoportban, amelyben az alkalmazáskapu telepítve lesz. Ez a WAF házirend ezután az AGW-hez van kötve. Az SSL/TLS beállításokhoz engedélyezem a legújabb előre konfigurált (legjobb gyakorlatnak megfelelő) házirendbeállításokat.
Mi lesz az eredmény?
A powershell szkript futtatása után egy olyan erőforráscsoportot kapunk, amely a következő erőforrásokat tartalmazza:
1. Maga az alkalmazáskapu
2. Az alkalmazáskapuhoz kötött nyilvános IP-cím
3. Az alkalmazáskapuhoz kötött egyéni webalkalmazás-tűzfal házirend
Remélem, ez a bejegyzés segít a kívánt Wildcard alkalmazáskapu telepítésében és konfigurálásában!
Hasznos linkek:
A Powershell-szkript a githubon
Microsoft dokumentáció
.
Leave a Reply