Deploying a Wildcard Azure Application Gateway using Powershell
Azure Application Gateway istnieje już od kilku lat. W ciągu ostatnich kilku lat widzieliśmy jej zmianę z oryginalnej wersji Standard (V1) bez funkcji Web Application Firewall do najnowszej wersji Standard (V2) z lub bez funkcji WAF. Wersja v2 została wydana 30 kwietnia 2019 r., więc prawdopodobnie zastąpiła już większość Twoich V1 (lub jeśli chcesz zacząć od nowa, V2 jest prawdopodobnie drogą naprzód)
Jak działa brama aplikacji?
Tytułem przypomnienia, jak dokładnie działa brama aplikacji Azure:
Jak pokazano na powyższym obrazku, możesz umieścić Azure Application Gateway pomiędzy klientami (web)- na przykład użytkownikami, którzy chcą połączyć się z twoją stroną internetową – a twoim serwerem(ami) backend. Tradycyjne load balancery działają na warstwie transportu (warstwa 4 OSI – TCP i UDP) i kierują ruch w oparciu o źródłowy adres IP i port, do docelowego adresu IP i portu.
Application Gateway może podejmować decyzje dotyczące routingu w oparciu o dodatkowe atrybuty żądania HTTP, na przykład ścieżkę URI lub nagłówki hostów. Na przykład, można kierować ruch na podstawie przychodzącego adresu URL. Więc jeśli /images jest w przychodzącym adresie URL, można kierować ruch do określonego zestawu serwerów (zwanego pulą) skonfigurowanych dla obrazów. Jeśli /video jest w adresie URL, ruch ten jest kierowany do innej puli, która jest zoptymalizowana dla filmów.
Ten typ routingu jest znany jako równoważenie obciążenia w warstwie aplikacji (warstwa 7 OSI). Azure Application Gateway może wykonywać routing oparty na adresach URL i nie tylko. Jeśli chcesz dowiedzieć się więcej o wszystkich funkcjach, jakie posiada aplikacja, sprawdź tę stronę
Teraz wprowadzenie: Wildcard Application Gateway
Więc, dla tych z was, którzy wdrażali Application Gateways w przeszłości, czy to poprzez użycie szablonów ARM, Azure CLI lub Powershell, prawdopodobnie będą wiedzieć, że proces wdrażania AGW jest dość kłopotliwy, zwłaszcza gdy chcesz zdefiniować wielu słuchaczy i / lub backendowe ustawienia HTTP. Osobiście wdrażałem bramy aplikacji w przeszłości, które składały się z 15 słuchaczy i kolejnych ustawień backendu, z których wszystkie kończyły się na tej samej nazwie domeny.
Na przykład:
www.contoso.com;
Contoso.com;
My.contoso.com;
Etc.
Problem z taką konfiguracją polegał na tym, że było sporo pracy z tworzeniem listenerów, kojarzeniem ich z regułą, która z kolei jest powiązana z backendem i ustawieniami HTTP. I musiałeś to zrobić dla każdej pojedynczej nazwy hosta, którą chciałeś skonfigurować, pomimo faktu, że wszystkie miały tę samą domenę.
Ale od 20 lipca 2020 roku Microsoft ogłosił, że teraz będą również wspierać opcję definiowania nazw hostów wieloznacznych w słuchaczu wielostanowiskowym. I możesz użyć do 5 unikalnych nazw hostów na listenera. Czyż to nie wspaniałe?
Więc jak to dokładnie działa jest przedstawione poniżej:
Jak widać na powyższym obrazku, istnieje wiele 'wielostanowiskowych’ słuchaczy skonfigurowanych na tej bramie aplikacji:
– *.contoso.com, *.fabrikam.*
– *.contos-*, frabrikam-??.com
These listeners can then be routed to the same or different backend pools.
So, using a wildcard character in the host name, you can match multiple host names in a single listener. Na przykład, *.contoso.com może pasować do ecom.contoso.com, b2b.contoso.com jak również customer1.b2b.contoso.com i tak dalej. Używając tablicy nazw hostów, możesz skonfigurować więcej niż jedną nazwę hosta dla listenera, aby kierować żądania do puli backend. Na przykład, listener może zawierać contoso.com, fabrikam.com, które będą akceptować żądania dla obu nazw hostów.
Zastrzeżenia słuchaczy wieloznacznych
Ponieważ słuchacze wieloznaczni są obecnie wciąż w wersji podglądowej, istnieją pewne uwagi i ograniczenia, które należy wziąć pod uwagę:
1. Ta funkcja jest w wersji preview i jest dostępna tylko dla Standard_v2 i WAF_v2 SKU Application Gateway.
2. Ta funkcja jest obecnie dostępna tylko poprzez Azure PowerShell i Azure CLI. Obsługa portalu będzie dostępna wkrótce. Należy pamiętać, że ponieważ wsparcie portalu nie jest w pełni dostępne, jeśli używasz tylko parametru HostNames, listener będzie wyświetlany jako Basic listener w portalu, a kolumna Host name w widoku listy listenerów nie będzie pokazywać nazw hostów, które są skonfigurowane. W przypadku jakichkolwiek zmian w listenerze wieloznacznym, upewnij się, że korzystasz z Azure PowerShell lub CLI, dopóki nie będzie to obsługiwane w portalu. Podzielę się zrzutami ekranu dotyczącymi tego w dalszej części tego bloga.
3. Nie można utworzyć reguły przekierowania z listenerem docelowym, który używa symboli wieloznacznych lub wielu nazw hostów. Nie można więc utworzyć przekierowania HTTP na HTTPS, tak jak można to zrobić w konfiguracji listenera bez symboli wieloznacznych.
4. W przypadku sprawdzania stanu backendu nie można powiązać wielu niestandardowych sond z ustawieniami HTTP. Zamiast tego możesz sondować jedną ze stron internetowych na zapleczu lub użyć „127.0.0.1” do sondowania localhost serwera zaplecza. Jednakże, gdy używasz symboli wieloznacznych lub wielu nazw hostów w listenerze, żądania dla wszystkich określonych wzorców domen będą kierowane do puli backendu w zależności od typu reguły (podstawowa lub oparta na ścieżce).
5. Nie można użyć wyrażenia regularnego do podania nazwy hosta. Możesz użyć tylko znaków wieloznacznych, takich jak gwiazdka (*) i znak zapytania (?), aby utworzyć wzór nazwy hosta.
6. Jeśli wiele nazw hostów jest wymienionych w tym samym listenerze, musisz przesłać certyfikat SAN (Subject Alternative Names) z CN odpowiadającym wymienionym nazwom hostów.
7. Jeśli jest to nazwa hosta wieloznaczna, taka jak *.contoso.com, musisz przesłać certyfikat wieloznaczny z CN takim jak *.contoso.com
Dość teorii! Jak wdrożyć?
Jak wspomniano wcześniej, w czasie pisania tego bloga, możesz użyć Powershell lub Azure CLI.
Zbudowałem przykład powershell, który wykona następujące czynności:
1. Znajdź odpowiednią sieć VNET i podsieć do wdrożenia AGW.
2. Utwórz publiczny adres IP, który będzie używany przez AGW
3. Utwórz konfiguracje IP dla bramy i frontendu
4. Utwórz pule backend
5. Utwórz listenery i reguły routingu
6. Utwórz politykę Web Application Firewall
7. Skonfiguruj ustawienia polityki TLS
8. Utwórz bramę aplikacji (w tym momencie będzie to AGW tylko HTTP)
Po pomyślnym wdrożeniu AGW, skrypt doda HTTPS do bramy aplikacji:
9. Znajdź AGW i zapisz go w zmiennej
10. Dodaj certyfikat SSL (wymagany PFX + hasło) i zapisz go w zmiennej
11. Dodaj port HTTPS frontend listener i zapisz go w zmiennej
12. Pobierz konfigurację IP frontendu i zapisz ją w zmiennej
13. Dodaj frontend listener (HTTPS) i zapisz go w zmiennej
14. Pobierz backendpool i zapisz go w zmiennej
15. Dodaj ustawienia HTTP backendu i zapisz je w zmiennej
16. Połącz wszystkie powyższe w regułę routingu
17. Zaktualizuj bramę aplikacji za pomocą wszystkiego, co zostało utworzone w krokach 8-15.
Skrypt powershell
Zanim uruchomisz skrypt powershell, musisz zrobić kilka rzeczy:
1. Zaloguj się do Azure, używając powershell (login-azAccount)
2. Znajdź subskrypcję, którą chcesz wdrożyć (get-azSubscription)
3. Wybierz tę subskrypcję (select-azsubscription -subscription „SUBSCRIPTIONNAME”)
4. Upewnij się, że masz utworzone VNET i podsieć w subskrypcji, która jest zdolna do wdrożenia AGW. Jeśli chodzi o rozmiar podsieci, zalecane jest użycie podsieci /26 jako minimum.
5. Jeśli masz działającą sieć VNET i podsieci rozmieszczone w wybranej grupie zasobów, wypełnij następujące parametry odpowiednimi informacjami:
– Nazwa grupy zasobów sieci wirtualnej ($VnetRGName)
– Nazwa sieci wirtualnej ($VnetName)
– Nazwa podsieci ($SubnetName)
6. Reszta zmiennych zależy tak naprawdę od Ciebie. Ponieważ może to być związane z takimi rzeczami jak konwencja nazewnictwa, ustawienia timeout itp. Nie będę tutaj niczego zalecał. Mój skrypt jest oparty na pojedynczym wildcard listener z pojedynczym backendem i kilkoma domyślnymi ustawieniami http, ale nie krępuj się edytować ich do swoich upodobań.
7. Szczególną uwagę poświęcam ustawieniom WAF & SSL/TLS. Ten skrypt włączy WAF dla Ciebie i utworzy politykę WAF w tej samej grupie zasobów, w której zostanie wdrożona brama aplikacji. Ta polityka WAF jest następnie powiązana z AGW. Dla ustawień SSL/TLS włączam najnowsze prekonfigurowane (najlepsze praktyki) policysetting.
Jaki będzie wynik?
Po uruchomieniu skryptu powershell otrzymasz grupę zasobów zawierającą następujące zasoby:
1. Sama brama aplikacji
2. Publiczny adres IP powiązany z bramą aplikacji
3. Niestandardowa polityka Web Application Firewall powiązana z bramą aplikacji
Mam nadzieję, że ten post pomoże Ci wdrożyć i skonfigurować bramę aplikacji Wildcard, którą chcesz!
Przydatne linki:
Skrypt Powershell na githubie
Dokumentacja Microsoftu
.
Leave a Reply