Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł pomaga zrozumieć bieżące znane problemy i ograniczenia w usłudze Azure Firewall. Aktualizujemy te informacje w miarę rozwiązywania problemów, dlatego regularnie sprawdzamy najnowszy stan.
Przed wdrożeniem usługi Azure Firewall lub rozwiązaniu problemów z istniejącymi wdrożeniami zapoznaj się z tymi znanymi problemami, aby uniknąć typowych problemów i zaplanować odpowiednie obejścia.
Aby uzyskać informacje o limitach usługi Azure Firewall, zobacz Limity, przydziały i ograniczenia subskrypcji i usług platformy Azure.
Bieżące ograniczenia pojemności
Obecnie występują ograniczenia pojemności w następujących strefach:
| Region/strefy techniczne | SKU | Ograniczenia | Zalecenie |
|---|---|---|---|
| Strefa fizyczna 1 i strefa 4 w regionie Wschodnie stany USA 2 EUAP | Basic, Standard i Premium | — Nie można wdrożyć nowej usługi Azure Firewall w strefie 1 i strefie 4. | Zalecamy wdrożenie nowej usługi Azure Firewall w pozostałych strefach dostępności lub użycie innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu? |
|
-
Strefa fizyczna 2 w Europie Północnej - Strefa fizyczna 3 w Azji Południowo-Wschodniej |
Standardowa i Premium | — Nie można wdrożyć nowej usługi Azure Firewall w strefie 3 w Azji Południowo-Wschodniej lub strefie 2 w Europie Północnej.
— Jeśli zatrzymasz istniejącą usługę Azure Firewall wdrożona w tej strefie, nie można jej ponownie uruchomić. Aby uzyskać więcej informacji, zobacz Strefy dostępności fizycznej i logicznej. |
Zalecamy wdrożenie nowej usługi Azure Firewall w pozostałych strefach dostępności lub użycie innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu? |
| Strefa fizyczna 3 w południowo-środkowych stanach USA | Basic, Standard i Premium | — Nie można wdrożyć nowej usługi Azure Firewall w strefie 3.
Szacowana data dostępna: 31 marca 2026 r. |
Zalecamy wdrożenie nowej usługi Azure Firewall w pozostałych strefach dostępności lub użycie innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu? |
| Strefa fizyczna 2 w Hiszpanii Środkowej | Basic, Standard i Premium | — Nie można wdrożyć nowej usługi Azure Firewall w strefie 2.
Szacowana data dostępna: 31 grudnia 2026 r. |
Zalecamy wdrożenie nowej usługi Azure Firewall w pozostałych strefach dostępności lub użycie innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu? |
| US Gov Wirginia | Premium | — Brak pojemności dla SKU Premium usługi Azure Firewall w regionie US Gov Virginia, zarówno wdrożenia strefowe, jak i niestrefowe są blokowane. | Wdróż jednostkę SKU usługi Azure Firewall w warstwie Standardowa lub wdróż jednostkę SKU w warstwie Premium w innym regionie. |
| Strefa fizyczna 3 w US Gov Virginia | Podstawowa i Standardowa | - Wdrożenia strefowe są zablokowane w fizycznej strefie 3 w Rządzie USA w Wirginii.
— Musisz ręcznie wybrać dostępne strefy, aby pomyślnie wdrożyć, co tworzy suboptymalne doświadczenie wdrażania. |
Wybierz strefy 1 i 2 dla wdrożeń strefowych lub użyj innego regionu. |
| Strefa fizyczna 2 w regionie Zachodnie stany USA 2 | Basic, Standard i Premium | — Nie można wdrożyć nowej usługi Azure Firewall w strefie 2. | Zalecamy wdrożenie nowej usługi Azure Firewall w pozostałych strefach dostępności lub użycie innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu? |
Ostrzeżenie
Jeśli zatrzymasz istniejące wdrożenie usługi Azure Firewall w dowolnym z tych regionów z ograniczeniami pojemności, możesz nie być w stanie uruchomić go ponownie z powodu bieżących ograniczeń pojemności. Zaplanuj odpowiednio przed zatrzymaniem wystąpień zapory w tych regionach.
Znane problemy usługi Azure Firewall Standardowa
Usługa Azure Firewall w warstwie Standardowa ma następujące znane problemy:
| Problematyka | Opis | Ograniczanie ryzyka |
|---|---|---|
| Obsługa DNAT prywatnych adresów IP ograniczona do wersji Standardowa i Premium | Obsługa protokołu DNAT na prywatnym adresie IP usługi Azure Firewall jest dostępna tylko w wersjach Zapory w warstwie Standardowa i Premium, a nie w wersji Podstawowa. | Żaden |
| Proces dealokacji i alokacji usługi Azure Firewall nie jest obsługiwany, gdy skonfigurowano prywatne reguły DNAT IP. | Proces alokacji usługi Azure Firewall kończy się niepowodzeniem po skonfigurowaniu prywatnych reguł DNAT | 1. Cofnięcie przydziału usługi Azure Firewall 2. Usuń wszystkie reguły DNAT prywatnych adresów IP 3. Przydziel Azure Firewall i czekaj, aż prywatny adres IP się wypełni 4. Ponownie skonfiguruj reguły DNAT prywatnych adresów IP przy użyciu odpowiedniego prywatnego adresu IP |
| Reguły filtrowania dla protokołów innych niż TCP/UDP (na przykład ICMP) nie działają dla ruchu powiązanego z Internetem | Reguły filtrowania sieci dla protokołów innych niż TCP/UDP nie działają z protokołem SNAT do publicznego adresu IP. Obsługiwane są protokoły inne niż TCP/UDP pomiędzy podsieciami typu spoke a sieciami VNet. | Usługa Azure Firewall korzysta ze standardowego modułu równoważenia obciążenia, który obecnie nie obsługuje funkcji SNAT dla protokołów IP. Eksplorujemy opcje obsługi protokołów innych niż TCP/UDP dla ruchu powiązanego z Internetem w przyszłej wersji. |
| Po cofnięciu przydziału usługi Azure Firewall, a następnie przydzieleniu go ponownie, może zostać przypisany nowy prywatny adres IP | Po zakończeniu procesu dealokacji i alokacji usługi Azure Firewall, prywatny adres IP jest przypisywany dynamicznie z podsieci Azure Firewall. Po przypisaniu nowego prywatnego adresu IP, który różni się od poprzedniego, powoduje problemy z routingiem. | Należy ponownie skonfigurować istniejące trasy zdefiniowane przez użytkownika (UDR) przy użyciu nowego prywatnego adresu IP. Poprawka jest badana w celu zachowania prywatnego adresu IP po procesie alokacji. |
| Polityki zapory podrzędnej nie dziedziczą ustawień DNS od polityk nadrzędnych. | Po zmianie ustawień DNS w nadrzędnych zasadach zapory zasady podrzędne połączone z nią mogą nie rozpoznać nazw domen w ich regułach. | Skonfiguruj ustawienia DNS bezpośrednio na poszczególnych zasadach podrzędnych zamiast polegać na zasadach nadrzędnych. Pracujemy nad poprawką umożliwiającą dziedziczenie ustawień DNS. |
| Brak obsługi protokołu ICMP w programie PowerShell i interfejsie wiersza polecenia | Program Azure PowerShell i interfejs wiersza polecenia nie obsługują protokołu ICMP jako prawidłowego protokołu w regułach sieciowych. | Nadal można używać protokołu ICMP jako protokołu za pośrednictwem portalu i interfejsu API REST. Pracujemy nad dodaniem protokołu ICMP w programie PowerShell i interfejsie wiersza polecenia wkrótce. |
| Tagi FQDN wymagają ustawienia protokołu i portu | Reguły aplikacji z tagami FQDN wymagają określenia portu i protokołu. | Jako wartości portu i protokołu można użyć wartości https. Pracujemy nad tym, aby port: pole protokołu było opcjonalne, gdy są używane tagi FQDN. |
| Przenoszenie firewalla do innej grupy zasobów lub subskrypcji nie jest obsługiwane | Przenoszenie firewalla do innej grupy zasobów lub subskrypcji nie jest obsługiwane. | Obsługa tej funkcji jest w naszym harmonogramie działania. Aby przenieść zaporę do innej grupy zasobów lub subskrypcji, musisz usunąć bieżący obiekt i utworzyć go ponownie w nowej grupie zasobów lub subskrypcji. |
| Alerty dotyczące analizy zagrożeń mogą zostać zamaskowane | Zasady sieciowe z przeznaczeniem 80/443 dla filtrowania wychodzącego maskują alerty o wywiadzie zagrożeń, gdy są skonfigurowane w trybie wyłącznie alertowania. | Utwórz filtrowanie ruchu wychodzącego dla 80/443 przy użyciu reguł aplikacji. Możesz też zmienić tryb analizy zagrożeń na Alert i Odmów. |
| W przypadku zabezpieczonych koncentratorów wirtualnych strefy dostępności można konfigurować tylko podczas wdrażania. | Nie można skonfigurować stref dostępności po wdrożeniu zapory z zabezpieczonymi koncentratorami wirtualnymi. | Zgodnie z projektem. |
| SNAT dla połączeń przychodzących | Reguły przychodzące DNAT zawsze zmieniają źródłowy adres IP dla ruchu powrotnego. | Aby śledzić oryginalny adres IP klienta dla ruchu internetowego, skonfiguruj klientów lub serwery proxy, aby uwzględnić oryginalny adres IP w nagłówkach XFF . Usługa Azure Firewall zachowuje te adresy IP w nagłówku XFF i dodaje adres IP zapory do nagłówka XFF podczas przetwarzania reguł ruchu internetowego. |
| Filtrowanie FQDN dla SQL jest obsługiwane tylko w trybie proxy (port 1433) | W przypadku usług Azure SQL Database, Azure Synapse Analytics i Azure SQL Managed Instance: Filtrowanie FQDN SQL jest obsługiwane wyłącznie w trybie proxy (port 1433). W przypadku usługi Azure SQL IaaS: Jeśli używasz niestandardowych portów, możesz określić te porty w regułach aplikacji. |
Dla SQL w trybie przekierowania (domyślny, jeśli trwa połączenie z Azure), możesz zamiast tego filtrować dostęp, używając tagu usługi SQL jako części reguł sieciowych Azure Firewall. |
| Ruch wychodzący SMTP na porcie TCP 25 jest zablokowany | Platforma Azure blokuje wychodzące wiadomości e-mail wysyłane bezpośrednio do domen zewnętrznych (takich jak outlook.com i gmail.com) na porcie TCP 25. Blokowanie wychodzącego ruchu SMTP na porcie 25 jest domyślnym zachowaniem platformy na platformie Azure. Usługa Azure Firewall nie wprowadza żadnych bardziej szczegółowych ograniczeń. |
Użyj uwierzytelnionych usług przekazywania SMTP, które zwykle łączą się za pośrednictwem portu TCP 587, ale także obsługują inne porty. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z łącznością wychodzącą SMTP na platformie Azure. Inną opcją jest wdrożenie Azure Firewall w standardowej subskrypcji Enterprise Agreement (EA). Usługa Azure Firewall w subskrypcji EA może komunikować się z publicznymi adresami IP przy użyciu wychodzącego portu TCP 25. Może działać w innych typach subskrypcji, ale nie jest gwarantowana. W przypadku prywatnych adresów IP, takich jak sieci wirtualne, sieci VPN i usługa Azure ExpressRoute, usługa Azure Firewall obsługuje połączenie wychodzące na porcie TCP 25. |
| wyczerpanie portów SNAT. | Usługa Azure Firewall obsługuje obecnie 2496 portów na publiczny adres IP na instancję zaplecza zestawu skalowania maszyn wirtualnych. Domyślnie istnieją dwa wystąpienia zestawu skalowania maszyn wirtualnych. W związku z tym istnieje 4992 porty na przepływ (docelowy adres IP, port docelowy i protokół (TCP lub UDP). Zapora może być skalowana do maksymalnie 20 wystąpień. | Wyczerpanie portów SNAT jest ograniczeniem platformy. Możesz obejść te limity, konfigurując wdrożenia usługi Azure Firewall z co najmniej pięcioma publicznymi adresami IP dla wdrożeń podatnych na wyczerpanie portów SNAT. Dodanie większej liczby publicznych adresów IP zwiększa liczbę dostępnych portów SNAT o pięć razy. Przypisz z prefiksu adresu IP, aby uprościć uprawnienia na końcowym etapie. Aby uzyskać bardziej trwałe rozwiązanie, można wdrożyć bramę NAT, aby przezwyciężyć limity portów SNAT. Wdrażanie bramy NAT jest obsługiwane w przypadku wdrożeń sieci wirtualnych. Aby uzyskać więcej informacji, zobacz Skalowanie portów SNAT z użyciem NAT usługi Azure Virtual Network na platformie Azure. |
| DNAT nie jest obsługiwane przy włączonym tunelowaniu wymuszonemu | Zapory wdrożone z włączonym wymuszonym tunelowaniem nie mogą obsługiwać dostępu przychodzącego z Internetu z powodu routingu asymetrycznego. | Brak obsługi DNAT przy wymuszonym tunelowaniu jest celowy ze względu na routing asymetryczny. Ścieżka powrotna dla połączeń przychodzących przechodzi przez zaporę lokalną, która nie widzi ustanowionego połączenia. |
| Wychodzący pasywny protokół FTP może nie działać w przypadku zapór z wieloma publicznymi adresami IP w zależności od konfiguracji serwera FTP. | Pasywny protokół FTP ustanawia różne połączenia dla kanałów kontroli i danych. Gdy zapora ogniowa z wieloma publicznymi adresami IP wysyła dane wychodzące, losowo wybiera jeden ze swoich publicznych adresów IP dla źródłowego adresu IP. Ftp może zakończyć się niepowodzeniem, gdy dane i kanały sterowania używają różnych źródłowych adresów IP, w zależności od konfiguracji serwera FTP. | Planowana jest jawna konfiguracja SNAT. W międzyczasie można skonfigurować serwer FTP tak, aby akceptował kanały danych i kontroli z różnych źródłowych adresów IP (zobacz przykład dla usług IIS). Alternatywnie rozważ użycie jednego adresu IP w przypadku problemów z łącznością FTP. |
| Przychodzący pasywny protokół FTP może nie działać w zależności od konfiguracji serwera FTP | Pasywny protokół FTP ustanawia różne połączenia dla kanałów kontroli i danych. Połączenia przychodzące w usłudze Azure Firewall są SNATowane do jednego z prywatnych adresów IP zapory sieciowej, aby zapewnić symetryczny routing. Ftp może zakończyć się niepowodzeniem, gdy dane i kanały sterowania używają różnych źródłowych adresów IP, w zależności od konfiguracji serwera FTP. | Zachowanie oryginalnego źródłowego adresu IP jest badane. W międzyczasie można skonfigurować serwer FTP tak, aby akceptował kanały danych i kontroli z różnych źródłowych adresów IP. |
| Aktywny protokół FTP nie działa, gdy klient FTP musi nawiązać połączenie z serwerem FTP przez Internet. | Usługa Active FTP używa polecenia PORT z klienta FTP, który kieruje serwer FTP, jakiego adresu IP i portu używać dla kanału danych. Polecenie PORT korzysta z prywatnego adresu IP klienta, którego nie można zmienić. Ruch po stronie klienta przechodzący przez usługę Azure Firewall przechodzi translację adresów sieciowych na potrzeby komunikacji internetowej, co powoduje, że polecenie PORT jest uważane za nieprawidłowe przez serwer FTP. | Błąd użycia trybu aktywnego FTP jest ogólnym ograniczeniem przy stosowaniu NAT po stronie klienta. |
| Metryce NetworkRuleHit brakuje aspektu związanego z protokołem. | Metryka ApplicationRuleHit umożliwia filtrowanie oparte na protokole, ale ta funkcja nie istnieje w odpowiadającej metryce NetworkRuleHit. | Trwa badanie poprawki. |
| Reguły NAT z portami z zakresu od 64000 do 65535 nie są obsługiwane | Usługa Azure Firewall zezwala na dowolny port w zakresie 1–65535 w regułach sieci i aplikacji, jednak reguły NAT obsługują tylko porty w zakresie 1–63999. | Ograniczenie dotyczące portów reguł NAT jest obecnym ograniczeniem. |
| Średnio aktualizacje konfiguracji mogą potrwać pięć minut | Aktualizacja konfiguracji usługi Azure Firewall może potrwać średnio od trzech do pięciu minut, a aktualizacje równoległe nie są obsługiwane. | Trwa badanie poprawki. |
| Usługa Azure Firewall używa nagłówków PROTOKOŁU TLS SNI do filtrowania ruchu HTTPS i MSSQL | Jeśli przeglądarka lub oprogramowanie serwera nie obsługuje rozszerzenia wskaźnika nazwy serwera (SNI), nie można nawiązać połączenia za pośrednictwem usługi Azure Firewall. | Jeśli przeglądarka lub oprogramowanie serwera nie obsługuje sieci SNI, możesz kontrolować połączenie przy użyciu reguły sieciowej zamiast reguły aplikacji. Zobacz Server Name Indication, aby znaleźć oprogramowanie obsługujące SNI. |
| Nie można dodać tagów polityki zapory przy użyciu portalu lub szablonów Azure Resource Manager (ARM) | Zasady Azure Firewall mają ograniczenie związane z obsługą aktualizacji, które uniemożliwia dodawanie tagów przy użyciu portalu Azure lub szablonów ARM. Generowany jest następujący błąd: Nie można zapisać tagów dla zasobu. | Trwa badanie poprawki. Możesz też użyć polecenia cmdlet Set-AzFirewallPolicy programu Azure PowerShell, aby zaktualizować tagi. |
| Protokół IPv6 nie jest obecnie obsługiwany | Jeśli dodasz adres IPv6 do reguły, zapora zakończy się niepowodzeniem. | Używaj tylko adresów IPv4. Obsługa protokołu IPv6 jest badana. |
| Usuwanie grup RuleCollectionGroups przy użyciu szablonów ARM nie jest obsługiwane. | Usunięcie RuleCollectionGroup przy użyciu szablonów ARM nie jest obsługiwane i kończy się niepowodzeniem. | Usuwanie grup RuleCollectionGroups za pomocą szablonów ARM nie jest operacją obsługiwaną. |
| Reguła DNAT zezwalająca na dowolne (*) zostanie użyte do SNAT ruchu. | Jeśli reguła DNAT zezwala na dowolny (*) jako źródłowy adres IP, to niejawna reguła sieciowa dopasowuje ruchu VNet-VNet i zawsze zostanie zastosowany SNAT do ruchu. | Automatyczne zachowanie SNAT dla reguł DNAT z dowolnym źródłem jest obecnym ograniczeniem. |
| Dodanie reguły DNAT do zabezpieczonego węzła wirtualnego z dostawcą zabezpieczeń nie jest obsługiwane. | Po dodaniu reguły DNAT do zabezpieczonego koncentratora wirtualnego z dostawcą zabezpieczeń powoduje to asynchroniczną trasę powrotnego ruchu DNAT, który trafia do dostawcy zabezpieczeń. | Nieobsługiwane. |
| Wystąpił błąd podczas tworzenia ponad 2000 kolekcji reguł. | Maksymalna liczba kolekcji reguł nat/aplikacji lub sieci to 2000 (limit usługi Resource Manager). | Limit 2000 reguł w kolekcji jest obecnym ograniczeniem. |
| Nie można wdrożyć zapory ze strefami dostępności, przy użyciu nowo utworzonego publicznego adresu IP | Podczas wdrażania zapory z wykorzystaniem stref dostępności nie można użyć nowo utworzonego publicznego adresu IP. | Najpierw utwórz nowy strefowo nadmiarowy publiczny adres IP, a następnie przypisz ten wcześniej utworzony adres IP podczas wdrażania zapory. |
| Kojarzenie publicznego adresu IP z usługą Azure Firewall nie jest obsługiwane w scenariuszu międzytenantowym. | Jeśli tworzysz publiczny IP w dzierżawie A, nie możesz skojarzyć go z zaporą wdrożoną w dzierżawie B. | Żaden. |
| Maszyny wirtualne za zaporą Azure Firewall nie mogą łączyć się z docelowymi adresami reguł DNAT przy użyciu publicznego adresu IP zapory | Gdy maszyny wirtualne kierują ruch przez usługę Azure Firewall i próbują połączyć się z zasobami skonfigurowanymi przy użyciu reguł DNAT przy użyciu publicznego adresu IP zapory, połączenie kończy się niepowodzeniem. Błąd połączenia występuje, ponieważ usługa Azure Firewall nie obsługuje przypinania ruchu z wewnętrznych maszyn wirtualnych do własnego publicznego adresu IP zapory dla miejsc docelowych reguł DNAT. | Rozwiązanie tego ograniczenia jest obecnie w trakcie opracowywania. |
Znane problemy z usługą Azure Firewall — wersja Premium
Uwaga
Każdy problem, który dotyczy Standardu, dotyczy również Premium.
Usługa Azure Firewall Premium ma następujące znane problemy:
| Problematyka | Opis | Ograniczanie ryzyka |
|---|---|---|
| Obsługa/ Wsparcie ESNI dla rozpoznawania pełnej nazwy domeny w HTTPS | Szyfrowana funkcja SNI nie jest obsługiwana w uzgadnianiu HTTPS. | Obecnie tylko Firefox obsługuje ESNI za pośrednictwem konfiguracji niestandardowej. Sugerowane obejście polega na wyłączeniu funkcji ESNI. |
| Uwierzytelnianie klienta za pomocą certyfikatu nie jest obsługiwane | Certyfikaty klienta są używane do tworzenia wzajemnego zaufania tożsamości między klientem a serwerem. Certyfikaty klienta są używane podczas negocjacji protokołu TLS. Azure Firewall renegocjuje połączenie z serwerem i nie ma dostępu do klucza prywatnego certyfikatów klienta. | Żaden |
| QUIC/HTTP3 | QUIC to nowa wersja główna protokołu HTTP. Jest to protokół oparty na UDP na portach 80 (PLAN) i 443 (SSL). Inspekcja nazwy FQDN/adresu URL/protokołu TLS nie jest obsługiwana. | Skonfiguruj przekazywanie UDP na portach 80/443 jako zasady sieciowe. |
| Niezaufane certyfikaty podpisane przez klienta | Zapora nie ufa certyfikatom podpisanym przez klienta, gdy odbiera je z intranetowego serwera internetowego. | Trwa badanie poprawki. |
| System IDPS wyświetla nieprawidłowy źródłowy adres IP dla alertów HTTP bez inspekcji TLS. | Gdy usługa IDPS generuje alerty dla ruchu HTTP w postaci zwykłego tekstu do publicznych adresów IP, wyświetla wewnętrzny adres IP zamiast oryginalnego źródłowego adresu IP. | Trwa badanie poprawki. |
| Propagacja certyfikatu | Po zastosowaniu certyfikatu urzędu certyfikacji w zaporze może upłynąć od 5 do 10 minut, zanim certyfikat zacznie obowiązywać. | Trwa badanie poprawki. |
| Obsługa protokołu TLS 1.3 | Protokół TLS 1.3 jest częściowo obsługiwany. Tunel TLS od klienta do zapory jest oparty na protokole TLS 1.2, a z zapory do zewnętrznego serwera sieci Web jest oparty na protokole TLS 1.3. | Trwa badanie aktualizacji. |
| Wygaśnięcie pośredniego certyfikatu CA TLSi | W niektórych unikatowych przypadkach certyfikat pośredniego urzędu certyfikacji może wygasnąć dwa miesiące przed oryginalną datą wygaśnięcia. | Odnów certyfikat pośredniego urzędu certyfikacji dwa miesiące przed pierwotną datą wygaśnięcia. Trwa badanie poprawki. |