Wildcard Azure Application Gatewayn käyttöönotto Powershellin avulla
>
Azure Application Gateway on ollut olemassa jo muutaman vuoden ajan. Viime vuosina olemme nähneet sen muuttuvan alkuperäisestä Standardista (V1) ilman Web Application Firewall -toiminnallisuutta uusimpaan Standardiin (V2), jossa on tai ei ole WAF-toiminnallisuutta. V2-versio on julkaistu 30.4.2019, joten se on todennäköisesti jo korvannut suurimman osan V1:stä (tai jos haluat aloittaa alusta, V2 lienee oikea vaihtoehto)
Miten Application Gateway toimii?
Muistutuksena, miten Azure Application Gateway tarkalleen ottaen toimii:
Kuten yllä olevassa kuvassa havainnollistetaan, voit sijoittaa Azure-sovellusyhdyskäytävän (verkko)asiakkaiden – esimerkiksi käyttäjien, jotka haluavat muodostaa yhteyden verkkosivustollesi – ja backend-palvelimen (-palvelimien) väliin. Perinteiset kuormantasaajat toimivat kuljetuskerroksella (OSI-kerros 4 – TCP ja UDP) ja reitittävät liikenteen lähde-IP-osoitteen ja portin perusteella kohde-IP-osoitteeseen ja -porttiin.
Application Gateway voi tehdä reitityspäätöksiä HTTP-pyynnön lisäominaisuuksien, esimerkiksi URI-polun tai isäntäotsikoiden perusteella. Voit esimerkiksi reitittää liikennettä saapuvan URL-osoitteen perusteella. Jos saapuvassa URL-osoitteessa on siis /images, voit reitittää liikenteen tiettyyn palvelinjoukkoon (ns. pooliin), joka on määritetty kuvia varten. Jos URL-osoitteessa on /video, liikenne ohjataan toiseen pooliin, joka on optimoitu videoita varten.
Tätyyppinen reititys tunnetaan sovelluskerroksen (OSI-kerros 7) kuormanjakona. Azure Application Gateway voi tehdä URL-pohjaista reititystä ja muuta. Jos haluat tietää lisää kaikista sovelluksen ominaisuuksista, tutustu tähän sivustoon
Nyt esitellään: Ne teistä, jotka ovat aiemmin ottaneet käyttöön Application Gatewayjä joko ARM-mallien, Azure CLI:n tai Powershellin avulla, tietävät luultavasti, että AGW:n käyttöönottoprosessi on melko hankala, varsinkin kun haluat määritellä useita kuuntelijoita ja/tai backendin HTTP-asetuksia. Itse olen aiemmin ottanut käyttöön sovellusportteja, jotka koostuivat 15 kuuntelijasta ja myöhemmistä backend-asetuksista, jotka kaikki päättyivät samaan verkkotunnukseen.
Esimerkiksi:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Ongelma tämänkaltaisessa kokoonpanossa on se, että kuuntelijoiden luominen, niiden liittäminen sääntöön, joka puolestaan liittyy backendiin ja HTTP-asetukseen, on ollut melkoisen työlästä. Ja sinun piti tehdä se jokaiselle isäntänimelle, jonka halusit määrittää, huolimatta siitä, että ne kaikki jakoivat saman verkkotunnuksen.
Mutta 20. heinäkuuta 2020 lähtien Microsoft on ilmoittanut tukevansa nyt myös mahdollisuutta määritellä jokerimerkkisiä isäntänimiä usean sivuston kuuntelijassa. Ja voit käyttää enintään 5 uniikkia isäntänimeä kuuntelijaa kohden. Eikö olekin hienoa?
Kuten tuo tarkalleen ottaen toimii, on kuvattu alla:
Kuten yllä olevasta kuvasta näkyy, tähän sovellusyhdyskäytävään on määritetty useita ’multi-site’ -kuuntelijoita:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
Nämä kuuntelijat voidaan sitten reitittää samoihin tai eri backend-pooleihin.
Käyttämällä isäntänimen jokerimerkkiä voit siis sovittaa useita isäntänimiä yhteen kuuntelijaan. Esimerkiksi *.contoso.com voi vastata ecom.contoso.com, b2b.contoso.com sekä customer1.b2b.contoso.com ja niin edelleen. Käyttämällä isäntänimien joukkoa voit määrittää kuuntelijalle useamman kuin yhden isäntänimen reitittääksesi pyynnöt backend-poolille. Kuuntelija voi esimerkiksi sisältää contoso.com, fabrikam.com, joka hyväksyy molempien isäntänimien pyynnöt.
Wildcard-kuuntelijoiden varoitukset
Koska wildcard-kuuntelijat ovat tällä hetkellä vielä esikatseluvaiheessa, on otettava huomioon joitakin näkökohtia ja rajoituksia:
1. Tämä ominaisuus on esikatseluvaiheessa ja käytettävissä vain Application Gatewayn Standard_v2- ja WAF_v2 SKU:ssa.
2. Tämä ominaisuus on tällä hetkellä käytettävissä vain Azure PowerShellin ja Azure CLI:n kautta. Portaalituki on tulossa pian. Huomaa, että koska portaalituki ei ole täysin käytettävissä, jos käytät vain HostNames-parametria, kuuntelija näkyy portaalissa Basic-kuuntelijana eikä kuuntelijaluettelonäkymän Host name -sarakkeessa näy määritettyjä isäntänimiä. Varmista, että käytät jokerimerkkikuuntelijan muutoksiin Azure PowerShelliä tai CLI:tä, kunnes se on tuettu portaalissa. Jaan joitakin tätä koskevia kuvakaappauksia jäljempänä tässä blogissa.
3. Et voi luoda uudelleenohjaussääntöä kohdekuuntelijalla, joka käyttää jokerimerkkejä tai useita isäntänimiä. Et siis voi luoda HTTP:stä HTTPS:ään tapahtuvaa uudelleenohjausta, kuten ei-wildcard-kuuntelija-asetuksessa.
4. Backendin terveystarkastusta varten et voi liittää useita mukautettuja koettimia HTTP-asetuksia kohti. Sen sijaan voit koestaa yhden taustapalvelimen verkkosivuston tai käyttää ”127.0.0.1” -kohtaa taustapalvelimen localhost-palvelimen koestamiseen. Kun kuitenkin käytät kuuntelijassa jokerimerkkejä tai useita isäntänimiä, kaikkien määritettyjen verkkotunnusmallien pyynnöt ohjataan backend-poolille sääntötyypistä (perus- tai polkupohjainen) riippuen.
5. Et voi käyttää säännöllistä lauseketta isäntänimen mainitsemiseen. Voit käyttää vain jokerimerkkejä, kuten tähteä (*) ja kysymysmerkkiä (?), isäntänimikuvion muodostamiseen.
6. Jos samassa kuuntelijassa mainitaan useita isäntänimiä, sinun on ladattava SAN-varmenne (Subject Alternative Names), jonka CN:t vastaavat mainittuja isäntänimiä.
7. Jos kyseessä on jokerimerkki-isäntänimi, kuten *.contoso.com, sinun on ladattava jokerimerkkivarmenne, jossa on CN, kuten *.contoso.com
Teoriaa riittää! Miten otan käyttöön?
Kuten aiemmin mainittiin, tätä blogia kirjoitettaessa voit käyttää joko Powershelliä tai Azure CLI:tä.
Olen rakentanut powershell-esimerkin, joka tekee seuraavat asiat:
1. Etsi sopiva VNET ja aliverkko, johon AGW voidaan ottaa käyttöön.
2. Luo julkinen IP-osoite AGW:n käyttöön
3. Luo IP-konfiguraatiot yhdyskäytävälle ja frontendille
4. Luo backend-poolit
5. Valitse IP-osoite. Luo kuuntelijat ja reitityssäännöt
6. Luo Web Application Firewall -käytäntö
7. Määritä TLS-käytännön asetukset
8. Luo sovellusyhdyskäytävä (tässä vaiheessa se on vain HTTP:tä käyttävä AGW)
Sen jälkeen, kun AGW on onnistuneesti otettu käyttöön, skripti lisää HTTPS:n sovellusyhdyskäytävään:
9. Etsi AGW ja tallenna se muuttujaan
10. Lisää SSL-sertifikaatti (PFX + salasana vaaditaan) ja tallenna se muuttujaan
11. Lisää HTTPS frontend -kuuntelijan portti ja tallenna se muuttujaan
12. Hae frontendin IP-konfiguraatio ja tallenna se muuttujaan
13. Lisää frontend-kuuntelija (HTTPS) ja tallenna se muuttujaan
14. Hae backendpool ja tallenna se muuttujaan
15. Lisää backendin HTTP-asetukset ja tallenna se muuttujaan
16. Yhdistä kaikki edellä mainitut asiat reitityssääntöön
17. Päivitä sovellusyhdyskäytävään kaikki vaiheissa 8-15 luodut asiat.
Powershell-skripti
Ennen kuin voit suorittaa powershell-skriptin, sinun on tehtävä muutama asia:
1. Kirjaudu sisään Azureen powershellin avulla (login-azAccount)
2. Etsi tilaus, johon haluat ottaa käyttöön (get-azSubscription)
3. Valitse kyseinen tilaus (select-azsubscription -subscription ”SUBSCRIPTIONNAME”)
4. Varmista, että olet luonut seuraavat luomasi VNET:n ja Subnet:in tilauksessasi oleviin VNET:iin ja SUBNET:iin, jotka kykenevät ottamaan AGW:n käyttöön. Aliverkon mitoituksessa suositellaan käytettäväksi vähintään aliverkkoa /26.
5. Jos sinulla on toimiva VNET ja aliverkot, jotka on asennettu haluamaasi resurssiryhmään, täytä seuraavat muuttujat asianmukaisilla tiedoilla:
– Virtuaaliverkon resurssiryhmän nimi ($VnetRGName)
– Virtuaaliverkon nimi ($VnetName)
– Aliverkon nimi ($SubnetName)
6. Loput muuttujista ovat oikeastaan sinun päätettävissäsi. Koska siihen saattaa liittyä asioita, kuten nimeämiskäytäntö, aikakatkaisuasetukset jne. En suosittele tässä mitään. Skriptini perustuu yhteen jokerimerkkikuuntelijaan, jossa on yksi backend ja joitakin oletusarvoisia http-asetuksia, mutta voit vapaasti muokata näitä mieleiseksesi.
7. Erityistä huomiota kiinnitetään WAF & SSL/TLS-asetuksiin. Tämä skripti ottaa WAF:n käyttöön puolestasi ja se luo WAF-käytännön samaan resurssiryhmään, johon Application Gateway otetaan käyttöön. Tämä WAF-käytäntö on sitten sidottu AGW:hen. SSL/TLS-asetusten osalta otan käyttöön viimeisimmän valmiiksi konfiguroidun (parhaan käytännön) policysettingin.
Mikä on tulos?
Kun olet ajanut powershell-skriptin, päädyt resurssiryhmään, jossa on seuraavat resurssit:
1. Itse sovellusyhdyskäytävä
2. Sovellusyhdyskäytävään sidottu julkinen IP-osoite
3. Sovellusyhdyskäytävään sidottu mukautettu web-sovelluspalomuurikäytäntö
Toivottavasti tämä viesti auttaa sinua ottamaan käyttöön ja konfiguroimaan haluamasi Wildcard-sovellusyhdyskäytävän!
Hyödyllisiä linkkejä:
Powershell-skripti githubissa
Microsoftin dokumentaatio
.
Leave a Reply