Deploying a Wildcard Azure Application Gateway using Powershell
Azure Application Gateway există deja de câțiva ani. În ultimii ani, am văzut cum s-a schimbat de la Standardul original (V1), fără nicio funcționalitate Web Application Firewall, la cel mai recent Standard (V2), cu sau fără funcționalitate WAF. Versiunea v2 a fost lansată pe 30 aprilie 2019, astfel încât probabil că a înlocuit până acum majoritatea V1-urilor dvs. (sau dacă doriți să începeți de la zero, V2 este probabil calea de urmat)
Cum funcționează un Application Gateway?
Doar ca o reamintire, cum funcționează mai exact un Azure Application Gateway:
După cum este ilustrat în imaginea de mai sus, puteți plasa un Azure Application Gateway între clienții (web) – de exemplu, utilizatorii care doresc să se conecteze la site-ul dvs. web – și serverul (serverele) dvs. backend. Balansatoarele de sarcină tradiționale funcționează la nivelul de transport (nivelul 4 OSI – TCP și UDP) și direcționează traficul pe baza adresei IP sursă și a portului, către o adresă IP de destinație și un port.
Application Gateway poate lua decizii de rutare pe baza unor atribute suplimentare ale unei cereri HTTP, de exemplu calea URI sau antetele gazdă. De exemplu, puteți ruta traficul pe baza URL-ului de intrare. Astfel, dacă /images se află în URL-ul de intrare, puteți direcționa traficul către un set specific de servere (cunoscut sub numele de pool) configurate pentru imagini. Dacă /video este în URL, traficul respectiv este direcționat către un alt pool care este optimizat pentru videoclipuri.
Acest tip de rutare este cunoscut sub numele de echilibrare a încărcăturii la nivelul aplicației (nivelul 7 OSI). Azure Application Gateway poate face rutarea bazată pe URL și nu numai. Dacă doriți să aflați mai multe despre toate caracteristicile pe care le are o aplicație, vă rugăm să consultați acest site
Acum introducem: Wildcard Application Gateway
Atunci, pentru cei care au implementat Application Gateways în trecut, fie prin utilizarea șabloanelor ARM, Azure CLI sau Powershell, vor ști probabil că procesul de implementare a unui AGW este destul de greoi, mai ales atunci când doriți să definiți mai mulți ascultători și/sau setări HTTP backend. Personal, am implementat în trecut Application Gateways care constau în 15 ascultători și setări backend ulterioare, toate terminate pe același nume de domeniu.
De exemplu:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Problema cu o astfel de configurație este că a fost destul de multă muncă pentru a crea ascultătorii, asociindu-i la o regulă care, la rândul ei, este asociată unui backend și unei setări HTTP. Și trebuia să o faceți pentru fiecare nume de gazdă pe care doreați să îl configurați, în ciuda faptului că toate împărtășeau același domeniu.
Dar începând cu 20 iulie 2020, Microsoft a anunțat că va suporta acum și opțiunea de a defini nume de gazdă wildcard într-un ascultător multi-site. Și puteți utiliza până la 5 nume de gazdă unice pentru fiecare ascultător. Nu este grozav?
Așa că modul exact în care funcționează acest lucru este ilustrat mai jos:
După cum puteți vedea în imaginea de mai sus, există mai mulți ascultători „multi-site” configurați pe acest gateway de aplicații:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-???.com
Acești ascultători pot fi apoi direcționați către aceleași pool-uri backend sau către pool-uri backend diferite.
Acum, folosind un caracter wildcard în numele de gazdă, puteți potrivi mai multe nume de gazdă într-un singur ascultător. De exemplu, *.contoso.com se poate potrivi cu ecom.contoso.com, b2b.contoso.com, precum și cu customer1.b2b.contoso.com și așa mai departe. Utilizând o matrice de nume de gazdă, puteți configura mai multe nume de gazdă pentru un ascultător, pentru a direcționa solicitările către un pool de backend. De exemplu, un ascultător poate conține contoso.com, fabrikam.com, care va accepta solicitări pentru ambele nume de gazdă.
Cerințele ascultătorilor wildcard
Din moment ce ascultătorii wildcard sunt încă în previzualizare, există câteva considerații și limitări de care trebuie să țineți cont:
1. Această caracteristică este în previzualizare și este disponibilă numai pentru SKU Standard_v2 și WAF_v2 al Application Gateway.
2. Această caracteristică este disponibilă în prezent numai prin Azure PowerShell și Azure CLI. Suportul pentru portal va fi disponibil în curând. Vă rugăm să rețineți că, deoarece suportul pentru portal nu este complet disponibil, dacă utilizați doar parametrul HostNames, ascultătorul va apărea ca un ascultător Basic în portal, iar coloana Host name (Nume gazdă) din vizualizarea listener (Ascultător) nu va afișa numele de gazdă configurate. Pentru orice modificare a unui ascultător wildcard, asigurați-vă că utilizați Azure PowerShell sau CLI până când acesta este acceptat în portal. Voi împărtăși câteva capturi de ecran referitoare la acest lucru mai jos pe acest blog.
3. Nu puteți crea o regulă de redirecționare cu un ascultător țintă care utilizează wildcard sau nume de gazdă multiple. Așadar, nu puteți crea o redirecționare de la HTTP la HTTPS, așa cum puteți face într-o configurație de ascultător fără wildcard.
4. Pentru verificarea stării de sănătate a backend-ului, nu puteți asocia mai multe sonde personalizate per setări HTTP. În schimb, puteți sonda unul dintre site-urile web din backend sau puteți utiliza „127.0.0.1” pentru a sonda localhost al serverului backend. Cu toate acestea, atunci când utilizați caractere wildcard sau mai multe nume de gazdă într-un ascultător, solicitările pentru toate modelele de domenii specificate vor fi direcționate către pool-ul backend în funcție de tipul de regulă (de bază sau bazată pe cale).
5. Nu puteți utiliza o expresie regulată pentru a menționa numele de gazdă. Puteți utiliza doar caractere wildcard, cum ar fi asterisc (*) și semnul întrebării (?) pentru a forma modelul de nume de gazdă.
6. Dacă sunt menționate mai multe nume de gazdă în același ascultător, trebuie să încărcați un certificat SAN (Subject Alternative Names) cu CN-uri care se potrivesc cu numele de gazdă menționate.
7. Dacă este un nume de gazdă wildcard, cum ar fi *.contoso.com, trebuie să încărcați un certificat wildcard cu CN-uri de tipul *.contoso.com
Suficient cu teoria! Cum implementez?
După cum am menționat anterior, la momentul scrierii acestui blog, puteți utiliza fie Powershell, fie Azure CLI.
Am construit un exemplu powershell care va face următoarele:
1. Găsiți VNET-ul și subrețeta corespunzătoare pentru a implementa AGW-ul.
2. Creați o adresă IP publică care să fie utilizată de AGW
3. Creați configurații IP pentru Gateway și frontend
4. Creați backend-pools
5. Creați ascultători și reguli de rutare
6. Creați politica Web Application Firewall
7. Configurați setările politicii TLS
8. Creați gateway-ul aplicației (în acest moment va fi un AGW numai HTTP)
Apoi, după ce AGW a fost implementat cu succes, scriptul va adăuga HTTPS la gateway-ul aplicației:
9. Găsiți AGW-ul și stocați-l într-o variabilă
10. Adăugați certificatul SSL (PFX + parola necesară) și stocați-l într-o variabilă
11. Adăugați portul HTTPS frontend listener și stocați-l într-o variabilă
12. Obțineți configurația IP frontend și stocați-o într-o variabilă
13. Adăugați un ascultător frontend (HTTPS) și stocați-l într-o variabilă
14. Obțineți backendpool și stocați-l într-o variabilă
15. Adăugați setările backend HTTP și stocați-le într-o variabilă
16. Legați toate cele de mai sus împreună într-o regulă de rutare
17. Actualizați Application Gateway cu tot ceea ce a fost creat în pașii 8-15.
Scriptul powershell
Înainte de a putea rula scriptul powershell, sunt câteva lucruri pe care trebuie să le faceți:
1. Autentificați-vă în Azure, folosind powershell (login-azAccount)
2. Găsiți abonamentul în care doriți să implementați (get-azSubscription)
3. Selectați acel abonament (select-azsubscription -subscription „SUBSCRIPTIONNAME”)
4. Asigurați-vă că ați creat în abonamentul dvs. un VNET și o subrețea, în care să puteți implementa AGW, după cum urmează. Pentru dimensionarea subrețelei, se recomandă utilizarea unei subrețele /26 ca minium.
5. Dacă aveți un VNET funcțional și subrețele implementate într-un grup de resurse ales de dumneavoastră, completați următorii parametri cu informațiile corespunzătoare:
– Virtual Network ResourceGroup name ($VnetRGName)
– Virtual Network Name ($VnetName)
– SubnetName ($SubnetName)
6. Restul variabilelor depinde de dumneavoastră. Pentru că ar putea fi implicate lucruri precum convenția de denumire, setările de timeout etc. Nu vă voi recomanda nimic aici. Scenariul meu se bazează pe un singur ascultător wildcard cu un singur backend și câteva setări http implicite, dar nu ezitați să le modificați după bunul dvs. plac.
7. O atenție deosebită se acordă setărilor WAF & SSL/TLS. Acest script va activa WAF pentru dvs. și va crea o politică WAF în același grup de resurse în care va fi implementat Application Gateway. Această politică WAF este apoi legată de AGW. Pentru setările SSL/TLS, activez cele mai recente setări de politici preconfigurate (cele mai bune practici).
Care va fi rezultatul?
După ce ați rulat scriptul powershell, vă veți trezi cu un grup de resurse care are următoarele resurse:
1. Gateway-ul de aplicații în sine
2. O adresă IP publică care este legată de Gateway-ul de aplicații
3. O politică Web Application Firewall personalizată care este legată de Gateway-ul de aplicații
Sper că această postare vă ajută să implementați și să configurați Gateway-ul de aplicații Wildcard pe care îl doriți!
Legături utile:
Scriptul Powershell la github
Documentația Microsoft
.
Leave a Reply