Networking considerations for an App Service Environment (Zagadnienia dotyczące sieci w środowisku App Service Environment)
Ważne
Ten artykuł dotyczy środowiska App Service Environment w wersji 2, który jest używany z planami izolowanej usługi App Service. Środowisko App Service Environment w wersji 2 zostanie wycofane 31 sierpnia 2024 r. Jest dostępna nowa wersja środowiska App Service Environment, która jest łatwiejsza do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej o nowej wersji, zacznij od wprowadzenia do środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 2, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.
Od 29 stycznia 2024 r. nie można już tworzyć nowych zasobów środowiska App Service Environment w wersji 2 przy użyciu dowolnej z dostępnych metod, w tym szablonów usługi ARM/Bicep, witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Aby zapobiec usunięciu zasobów i utracie danych, musisz przeprowadzić migrację do środowiska App Service Environment w wersji 3 przed 31 sierpnia 2024 r.
App Service Environment to wdrożenie usługi aplikacja systemu Azure Service w podsieci w sieci wirtualnej platformy Azure. Istnieją dwa typy wdrożeń dla środowiska App Service Environment:
- Zewnętrzne: ten typ wdrożenia uwidacznia hostowane aplikacje przy użyciu adresu IP dostępnego w Internecie. Aby uzyskać więcej informacji, zobacz Tworzenie zewnętrznego środowiska App Service Environment.
- Wewnętrzny moduł równoważenia obciążenia: ten typ wdrożenia uwidacznia hostowane aplikacje na adresIE IP wewnątrz sieci wirtualnej. Wewnętrzny punkt końcowy jest wewnętrznym modułem równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Tworzenie i używanie wewnętrznego środowiska App Service Environment modułu równoważenia obciążenia.
Uwaga
Ten artykuł dotyczy środowiska App Service Environment w wersji 2, który jest używany z izolowanymi planami usługi App Service.
Niezależnie od typu wdrożenia wszystkie środowiska App Service Environment mają publiczny wirtualny adres IP (VIP). Ten adres VIP jest używany na potrzeby ruchu przychodzącego zarządzania i jako adres podczas wykonywania wywołań ze środowiska App Service Environment do Internetu. Takie wywołania opuszczają sieć wirtualną za pośrednictwem adresu VIP przypisanego dla środowiska App Service Environment.
Jeśli aplikacje tworzą wywołania do zasobów w sieci wirtualnej lub w sieci VPN, źródłowy adres IP jest jednym z adresów IP w podsieci. Ponieważ środowisko App Service Environment znajduje się w sieci wirtualnej, może również uzyskiwać dostęp do zasobów w sieci wirtualnej bez dodatkowej konfiguracji. Jeśli sieć wirtualna jest połączona z siecią lokalną, aplikacje mają również dostęp do zasobów bez dodatkowej konfiguracji.
Jeśli masz środowisko App Service Environment z wdrożeniem zewnętrznym, publiczny adres VIP jest również punktem końcowym, dla którego aplikacje rozpoznają następujące kwestie:
- HTTP/S
- FTP/S
- Wdrożenie w sieci Web
- Debugowanie zdalne
Jeśli masz środowisko App Service Environment z wewnętrznym wdrożeniem modułu równoważenia obciążenia, adres adresu wewnętrznego jest punktem końcowym protokołu HTTP/S, FTP/S, wdrożenia internetowego i zdalnego debugowania.
Rozmiar podsieci
Po wdrożeniu środowiska App Service Environment nie można zmienić rozmiaru podsieci używanej do jej hostowania. Środowisko App Service Environment używa adresu dla każdej roli infrastruktury, a także dla każdego izolowanego wystąpienia planu usługi App Service. Ponadto sieć platformy Azure używa pięciu adresów dla każdej utworzonej podsieci.
Środowisko App Service Environment bez planów usługi App Service w ogóle będzie używać 12 adresów przed utworzeniem aplikacji. Jeśli używasz wewnętrznego wdrożenia modułu równoważenia obciążenia, użyje 13 adresów przed utworzeniem aplikacji. Podczas skalowania w poziomie należy pamiętać, że role infrastruktury są dodawane w każdej wielokrotności 15 i 20 wystąpień planu usługi App Service.
Ważne
Nic innego nie może znajdować się w podsieci, ale w środowisku App Service Environment. Pamiętaj, aby wybrać przestrzeń adresową, która umożliwia przyszły wzrost. Nie można później zmienić tego ustawienia. Zalecamy rozmiar /24 256 adresów.
Podczas skalowania w górę lub w dół dodawane są nowe role odpowiedniego rozmiaru, a następnie obciążenia są migrowane z bieżącego rozmiaru do rozmiaru docelowego. Oryginalne maszyny wirtualne są usuwane dopiero po migracji obciążeń. Jeśli na przykład masz środowisko App Service Environment z 100 wystąpieniami planu usługi App Service, istnieje okres, w którym wymagana jest dwukrotna liczba maszyn wirtualnych.
Zależności przychodzące i wychodzące
W poniższych sekcjach omówiono zależności, o których należy pamiętać w środowisku App Service Environment. W innej sekcji omówiono ustawienia DNS.
Zależności przychodzące
Aby usługa App Service Environment działała, muszą być otwarte następujące porty:
| Używanie | od | do |
|---|---|---|
| Zarządzanie | Adresy zarządzania usługą App Service | Podsieć środowiska App Service Environment: 454, 455 |
| Komunikacja wewnętrzna środowiska App Service Environment | Podsieć środowiska App Service Environment: wszystkie porty | Podsieć środowiska App Service Environment: wszystkie porty |
| Zezwalaj na ruch przychodzący modułu równoważenia obciążenia platformy Azure | Moduł równoważenia obciążenia platformy Azure | Podsieć środowiska App Service Environment: 16001 |
Porty 7564 i 1221 mogą być wyświetlane jako otwarte podczas skanowania portów. Odpowiadają za pomocą adresu IP i nic więcej. Możesz je zablokować, jeśli chcesz.
Ruch związany z zarządzaniem przychodzącym zapewnia również kontrolę nad środowiskiem App Service Environment oraz monitorowaniem systemu. Adresy źródłowe dla tego ruchu są wymienione w adresach zarządzania środowiska App Service Environment. Konfiguracja zabezpieczeń sieci musi zezwalać na dostęp z adresów zarządzania środowiska App Service Environment na portach 454 i 455. Jeśli zablokujesz dostęp z tych adresów, środowisko App Service Environment stanie się w złej kondycji, a następnie zostanie zawieszone. Ruch TCP, który znajduje się na portach 454 i 455, musi wrócić z tego samego adresu VIP lub występuje problem z routingiem asymetrycznym.
W podsieci istnieje wiele portów używanych do komunikacji składników wewnętrznych i mogą ulec zmianie. Wymaga to, aby wszystkie porty w podsieci były dostępne z podsieci.
W przypadku komunikacji między modułem równoważenia obciążenia platformy Azure a podsiecią App Service Environment minimalne porty, które muszą być otwarte, to 454, 455 i 16001. Jeśli używasz wewnętrznego wdrożenia modułu równoważenia obciążenia, możesz zablokować ruch tylko do portów 454, 455, 16001. Jeśli używasz wdrożenia zewnętrznego, musisz wziąć pod uwagę normalne porty dostępu do aplikacji. W szczególności są to:
| Używanie | Porty |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Zdalne debugowanie programu Visual Studio | 4020, 4022, 4024 |
| Usługa web deploy | 8172 |
Jeśli zablokujesz porty aplikacji, środowisko App Service Environment nadal może działać, ale aplikacja może nie działać. Jeśli używasz adresów IP przypisanych do aplikacji z wdrożeniem zewnętrznym, musisz zezwolić na ruch z adresów IP przypisanych do aplikacji do podsieci. W portalu środowiska App Service Environment przejdź do adresu IP i zobacz porty, z których chcesz zezwolić na ruch.
Zależności wychodzące
W przypadku dostępu wychodzącego środowisko App Service Environment zależy od wielu systemów zewnętrznych. Wiele z tych zależności systemowych jest zdefiniowanych przy użyciu nazw DNS i nie mapuje na stały zestaw adresów IP. W związku z tym środowisko App Service Environment wymaga dostępu wychodzącego z podsieci do wszystkich zewnętrznych adresów IP na różnych portach.
Środowisko App Service Environment komunikuje się z adresami dostępnymi w Internecie na następujących portach:
| Użycie | Porty |
|---|---|
| DNS | 53 |
| NTP | 123 |
| Lista CRL, aktualizacje systemu Windows, zależności systemu Linux, usługi platformy Azure | 80/443 |
| Azure SQL | 1433 |
| Monitorowanie | 12000 |
Zależności wychodzące są wyświetlane w temacie Blokowanie środowiska App Service Environment. Jeśli środowisko App Service Environment utraci dostęp do jego zależności, przestanie działać. Jeśli tak się stanie przez wystarczająco długi czas, zostanie on zawieszony.
Dns klienta
Jeśli sieć wirtualna jest skonfigurowana przy użyciu serwera DNS zdefiniowanego przez klienta, obciążenia dzierżawy używają go. Środowisko App Service Environment używa usługi Azure DNS do celów zarządzania. Jeśli sieć wirtualna jest skonfigurowana z wybranym przez klienta serwerem DNS, serwer DNS musi być dostępny z podsieci.
Uwaga
Instalacja magazynu lub ściąganie obrazu kontenera w środowisku App Service Environment w wersji 2 nie może używać zdefiniowanego przez klienta systemu DNS w sieci wirtualnej ani za pośrednictwem WEBSITE_DNS_SERVER ustawienia aplikacji.
Aby przetestować rozpoznawanie nazw DNS z poziomu aplikacji internetowej, możesz użyć polecenia nameresolverkonsoli . Przejdź do okna debugowania w scm witrynie aplikacji lub przejdź do aplikacji w portalu i wybierz pozycję konsola. W wierszu polecenia powłoki możesz wydać polecenie nameresolver, wraz z nazwą DNS, którą chcesz wyszukać. Otrzymany wynik jest taki sam jak otrzymana aplikacja podczas tworzenia tego samego wyszukiwania. Jeśli używasz metody nslookup, zamiast tego wykonujesz wyszukiwanie przy użyciu usługi Azure DNS.
Jeśli zmienisz ustawienie DNS sieci wirtualnej, w której znajduje się środowisko App Service Environment, konieczne będzie ponowne uruchomienie. Aby uniknąć ponownego uruchamiania, warto skonfigurować ustawienia DNS dla sieci wirtualnej przed utworzeniem środowiska App Service Environment.
Zależności portalu
Oprócz zależności opisanych w poprzednich sekcjach należy pamiętać o kilku dodatkowych zagadnieniach związanych z środowiskiem portalu. Niektóre funkcje w witrynie Azure Portal zależą od bezpośredniego dostępu do witryny menedżera kontroli źródła (SCM). Dla każdej aplikacji w usłudze aplikacja systemu Azure istnieją dwa adresy URL. Pierwszym adresem URL jest uzyskanie dostępu do aplikacji. Drugi adres URL to uzyskiwanie dostępu do witryny SCM, która jest również nazywana konsolą Kudu. Funkcje korzystające z witryny SCM obejmują:
- Zadania WebJob
- Funkcje
- Przesyłanie strumieniowe dzienników
- Kudu
- Rozszerzenia
- Eksplorator procesów
- Konsola
W przypadku korzystania z wewnętrznego modułu równoważenia obciążenia lokacja SCM nie jest dostępna spoza sieci wirtualnej. Niektóre funkcje nie działają w portalu aplikacji, ponieważ wymagają one dostępu do witryny SCM aplikacji. Możesz nawiązać bezpośrednie połączenie z witryną SCM zamiast przy użyciu portalu.
Jeśli wewnętrzny moduł równoważenia obciążenia to nazwa contoso.appserviceenvironment.netdomeny , a nazwa aplikacji to testapp, aplikacja zostanie osiągnięta pod adresem testapp.contoso.appserviceenvironment.net. Witryna SCM, z którą pochodzi, jest osiągana pod adresem testapp.scm.contoso.appserviceenvironment.net.
Adresy IP
Środowisko App Service Environment ma kilka adresów IP, o których należy pamiętać. Są to:
- Publiczny adres IP dla ruchu przychodzącego: używany do ruchu aplikacji we wdrożeniu zewnętrznym i ruchu zarządzania zarówno we wdrożeniach wewnętrznych, jak i zewnętrznych.
- Wychodzący publiczny adres IP: używany jako adres IP "from" dla połączeń wychodzących, które opuszczają sieć wirtualną. Te połączenia nie są kierowane w dół sieci VPN.
- Wewnętrzny adres IP modułu równoważenia obciążenia: ten adres istnieje tylko we wdrożeniu wewnętrznym.
- Adresy TLS/SSL oparte na adresach IP przypisane przez aplikację: te adresy są możliwe tylko w przypadku wdrożenia zewnętrznego, a po skonfigurowaniu powiązania TLS/SSL opartego na protokole IP.
Wszystkie te adresy IP są widoczne w witrynie Azure Portal z poziomu interfejsu użytkownika środowiska App Service Environment. Jeśli masz wdrożenie wewnętrzne, zostanie wyświetlony adres IP wewnętrznego modułu równoważenia obciążenia.
Uwaga
Te adresy IP nie zmieniają się, o ile środowisko App Service Environment jest uruchomione. Jeśli środowisko App Service Environment zostanie zawieszone i zostanie przywrócone, używane adresy zmienią się. Normalną przyczyną zawieszenia jest zablokowanie dostępu do zarządzania przychodzącego lub zablokowanie dostępu do zależności.
Adresy IP przypisane przez aplikację
Wdrożenie zewnętrzne umożliwia przypisywanie adresów IP do poszczególnych aplikacji. Nie można tego zrobić przy użyciu wdrożenia wewnętrznego. Aby uzyskać więcej informacji na temat konfigurowania aplikacji pod kątem własnego adresu IP, zobacz Zabezpieczanie niestandardowej nazwy DNS przy użyciu powiązania TLS/SSL w usłudze aplikacja systemu Azure.
Gdy aplikacja ma własny adres SSL oparty na adresie IP, środowisko App Service Environment rezerwuje dwa porty do mapowania na ten adres IP. Jeden port jest przeznaczony dla ruchu HTTP, a drugi port jest przeznaczony dla protokołu HTTPS. Te porty są wymienione w sekcji Adresy IP portalu środowiska App Service Environment. Ruch musi mieć możliwość dotarcia do tych portów z adresu VIP. W przeciwnym razie aplikacje są niedostępne. To wymaganie jest ważne, aby pamiętać podczas konfigurowania sieciowych grup zabezpieczeń.
Sieciowe grupy zabezpieczeń
Sieciowe grupy zabezpieczeń umożliwiają kontrolowanie dostępu do sieci w sieci wirtualnej. W przypadku korzystania z portalu istnieje niejawna reguła odmowy o najniższym priorytetzie, aby odmówić wszystkiego. To, co tworzysz, to reguły zezwalania.
Nie masz dostępu do maszyn wirtualnych używanych do hostowania samego środowiska App Service Environment. Są one w subskrypcji zarządzanej przez firmę Microsoft. Jeśli chcesz ograniczyć dostęp do aplikacji, ustaw sieciowe grupy zabezpieczeń w podsieci. W ten sposób należy zwrócić szczególną uwagę na zależności. Jeśli zablokujesz jakiekolwiek zależności, środowisko App Service Environment przestanie działać.
Sieciowe grupy zabezpieczeń można skonfigurować za pośrednictwem witryny Azure Portal lub programu PowerShell. W tym miejscu przedstawiono witrynę Azure Portal. Sieciowe grupy zabezpieczeń można tworzyć i zarządzać nimi w portalu jako zasób najwyższego poziomu w obszarze Sieć.
Wymagane wpisy w sieciowej grupie zabezpieczeń mają zezwalać na ruch:
Przychodzące
- TCP z tagu
AppServiceManagementusługi IP na portach 454, 455 - PROTOKÓŁ TCP z modułu równoważenia obciążenia na porcie 16001
- Z podsieci Środowiska App Service Environment do podsieci środowiska App Service Environment na wszystkich portach
Wychodzące
- UDP do wszystkich adresów IP na porcie 53
- UDP do wszystkich adresów IP na porcie 123
- Tcp do wszystkich adresów IP na portach 80, 443
- TCP do tagu
Sqlusługi IP na porcie 1433 - Tcp do wszystkich adresów IP na porcie 12000
- Do podsieci środowiska App Service Environment na wszystkich portach
Te porty nie zawierają portów, których aplikacje wymagają do pomyślnego użycia. Załóżmy na przykład, że aplikacja musi wywołać serwer MySQL na porcie 3306. Protokół NTP (Network Time Protocol) na porcie 123 to protokół synchronizacji czasu używany przez system operacyjny. Punkty końcowe NTP nie są specyficzne dla usługi App Service, mogą się różnić w zależności od systemu operacyjnego i nie znajdują się na dobrze zdefiniowanej liście adresów. Aby zapobiec problemom z synchronizacją czasu, należy zezwolić na ruch UDP do wszystkich adresów na porcie 123. Ruch wychodzący TCP do portu 12000 jest przeznaczony do obsługi i analizy systemu. Punkty końcowe są dynamiczne i nie znajdują się w dobrze zdefiniowanym zestawie adresów.
Normalne porty dostępu do aplikacji to:
| Używanie | Porty |
|---|---|
| HTTP/HTTPS | 80, 443 |
| FTP/FTPS | 21, 990, 10001-10020 |
| Zdalne debugowanie programu Visual Studio | 4020, 4022, 4024 |
| Usługa Web Deploy | 8172 |
Reguła domyślna umożliwia adresom IP w sieci wirtualnej rozmowę z podsiecią. Inna reguła domyślna umożliwia modułowi równoważenia obciążenia, znanemu również jako publiczny adres VIP, komunikowanie się ze środowiskiem App Service Environment. Aby wyświetlić reguły domyślne, wybierz pozycję Reguły domyślne (obok ikony Dodaj ).
Jeśli umieścisz regułę odmowy wszystkiego innego przed regułami domyślnymi, uniemożliwisz ruch między adresem VIP i środowiskiem App Service Environment. Aby zapobiec ruchowi pochodzącemu z sieci wirtualnej, dodaj własną regułę, aby zezwolić na ruch przychodzący. Użyj źródła równego AzureLoadBalancerwartości , z lokalizacją docelową dowolnej i zakresem portów .* Ponieważ reguła sieciowej grupy zabezpieczeń jest stosowana do podsieci, nie musisz być specyficzna w miejscu docelowym.
Jeśli przypisano adres IP do aplikacji, upewnij się, że porty są otwarte. Aby wyświetlić porty, wybierz pozycję Adresy IP środowiska App Service Environment>.
Po zdefiniowaniu sieciowych grup zabezpieczeń przypisz je do podsieci. Jeśli nie pamiętasz sieci wirtualnej lub podsieci, możesz zobaczyć ją w portalu App Service Environment. Aby przypisać sieciową grupę zabezpieczeń do podsieci, przejdź do interfejsu użytkownika podsieci i wybierz sieciową grupę zabezpieczeń.
Trasy
Wymuszone tunelowanie odbywa się po ustawieniu tras w sieci wirtualnej, aby ruch wychodzący nie przechodził bezpośrednio do Internetu. Zamiast tego ruch przechodzi gdzie indziej, na przykład brama usługi Azure ExpressRoute lub urządzenie wirtualne. Jeśli musisz skonfigurować środowisko App Service Environment w taki sposób, zobacz Konfigurowanie środowiska App Service Environment przy użyciu wymuszonego tunelowania.
Podczas tworzenia środowiska App Service Environment w portalu automatycznie tworzy się zestaw tabel tras w podsieci. Trasy te mówią po prostu, aby wysyłać ruch wychodzący bezpośrednio do Internetu.
Aby ręcznie utworzyć te same trasy, wykonaj następujące kroki:
Przejdź do witryny Azure Portal i wybierz pozycję Sieciowe>tabele tras.
Utwórz nową tabelę tras w tym samym regionie co sieć wirtualna.
W interfejsie użytkownika tabeli tras wybierz pozycję Trasy>Dodaj.
Ustaw typ Następnego przeskoku na Internet, a prefiks adresu na 0.0.0.0/0. Wybierz pozycję Zapisz.
Następnie zobaczysz coś podobnego do następującego:
Po utworzeniu nowej tabeli tras przejdź do podsieci. Wybierz tabelę tras z listy w portalu. Po zapisaniu zmiany powinna zostać wyświetlona sieciowa grupa zabezpieczeń i trasy zanotowany w podsieci.
Punkty końcowe usługi
Punkty końcowe usługi umożliwiają ograniczenie dostępu do usług wielodostępnych do zestawu sieci wirtualnych i podsieci platformy Azure. Aby uzyskać więcej informacji, zobacz Punkty końcowe usługi dla sieci wirtualnej.
Po włączeniu punktów końcowych usługi w zasobie istnieją trasy utworzone z wyższym priorytetem niż wszystkie inne trasy. Jeśli używasz punktów końcowych usługi w dowolnej usłudze platformy Azure z wymuszonym tunelem App Service Environment, ruch do tych usług nie jest wymuszany.
Gdy punkty końcowe usługi są włączone w podsieci z wystąpieniem usługi Azure SQL, wszystkie wystąpienia usługi Azure SQL połączone z tą podsiecią muszą mieć włączone punkty końcowe usługi. Jeśli chcesz uzyskać dostęp do wielu wystąpień usługi Azure SQL z tej samej podsieci, musisz włączyć punkty końcowe usługi na każdym wystąpieniu usługi Azure SQL. Żadna inna usługa platformy Azure nie zachowuje się tak jak usługa Azure SQL w odniesieniu do punktów końcowych usługi. Po włączeniu punktów końcowych usługi za pomocą usługi Azure Storage możesz zablokować dostęp do tego zasobu z podsieci. Nadal możesz uzyskać dostęp do innych kont usługi Azure Storage, jednak nawet jeśli nie mają one włączonych punktów końcowych usługi.
