Znane problemy i ograniczenia Azure Firewall

Podsumowanie

Ten artykuł pomaga zrozumieć bieżące znane problemy i ograniczenia dotyczące Azure Firewall. Firma Microsoft aktualizuje te informacje w miarę rozwiązywania problemów, dlatego regularnie sprawdzaj je pod kątem najnowszego stanu.

Przed wdrożeniem Azure Firewall lub rozwiązaniem problemów z istniejącymi wdrożeniami zapoznaj się z tymi znanymi problemami, aby uniknąć typowych problemów i zaplanować odpowiednie obejścia.

Aby poznać limity usług Azure Firewall, zobacz Azure limity subskrypcji i usług, przydziały i ograniczenia.

Bieżące ograniczenia pojemności

Następujące strefy mają obecnie ograniczenia pojemności:

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ć nowego Azure Firewall w strefie 1 i strefie 4. Wdróż nową usługę Azure Firewall w pozostałych strefach dostępności lub użyj 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 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 tych strefach, nie będzie można jej ponownie uruchomić.

Aby uzyskać więcej informacji, zobacz Strefy dostępności fizycznej i logicznej.		 Wdróż nową usługę Azure Firewall w pozostałych strefach dostępności lub użyj 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ć nowego Azure Firewall w strefie 3.

Szacowana data dostępna: 31 marca 2026 r.		 Wdróż nową usługę Azure Firewall w pozostałych strefach dostępności lub użyj 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 Azure Firewall w strefie 2.

Szacowana data dostępna: 31 grudnia 2026 r.		 Wdróż nową usługę Azure Firewall w pozostałych strefach dostępności lub użyj innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu?
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 Azure Firewall w strefie 2. Wdróż nową usługę Azure Firewall w pozostałych strefach dostępności lub użyj innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu?
Strefa fizyczna 1,2,3 w Katarze Środkowym Basic, Standard i Premium — Nowe wdrożenia Azure Firewall są zablokowane.

Dostępna data: 31 grudnia 2026 r.		 Wdróż nową usługę Azure Firewall w innym regionie.

Ostrzeżenie

Jeśli zatrzymasz istniejące wdrożenie 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 z Azure Firewall Standard

Azure Firewall Standard ma następujące znane problemy:

Problematyka Opis Mitigation
Obsługa DNAT prywatnych adresów IP ograniczona do wersji Standardowa i Premium Obsługa translacji DNAT na adresie IP prywatnym usługi Azure Firewall jest dostępna tylko w wersjach zapory Standard i Premium, a nie w wersji Basic. Żadne
Azure Firewall proces alokacji i dealokacji nie jest obsługiwany, gdy skonfigurowano prywatne reguły DNAT IP Proces alokacji Azure Firewall kończy się niepowodzeniem po skonfigurowaniu prywatnych reguł DNAT 1. Cofnij przydział Azure Firewall
2. Usuń wszystkie reguły DNAT prywatnych adresów IP
3. Przydziel Azure Firewall i zaczekaj na wypełnienie prywatnego adresu IP
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. Azure Firewall używa Standard Load Balancer, który nie obsługuje protokołu SNAT dla protokołów IP obecnie. 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 Azure Firewall, a następnie przydzieleniu go ponownie, może zostać przypisany nowy prywatny adres IP Po zakończeniu procesu dealokacji i alokacji Azure Firewall, prywatny adres IP jest przypisywany dynamicznie z tej podsieci. 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 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ć Availability Zones 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 . 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 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 Azure SQL IaaS:

Jeśli używasz niestandardowych portów, możesz określić te porty w regułach aplikacji.		 W przypadku języka SQL w trybie przekierowania (ustawienie domyślne w przypadku nawiązywania połączenia z poziomu Azure) można zamiast tego filtrować dostęp przy użyciu tagu usługi SQL w ramach reguł sieci 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 ruchu wychodzącego SMTP na porcie 25 jest domyślnym zachowaniem platformy w Azure. 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 wychodzącą łącznością SMTP w Azure.

Inną opcją jest wdrożenie Azure Firewall w standardowej subskrypcji umowy Enterprise Agreement (EA). 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 Azure ExpressRoute, Azure Firewall obsługuje połączenie wychodzące na porcie TCP 25.
wyczerpanie portów SNAT. Azure Firewall obecnie obsługuje 2496 portów na publiczny adres IP na instancję skali zestawu maszyn wirtualnych zaplecza. 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 Azure Firewall z co najmniej pięcioma publicznymi adresami IP dla wdrożeń podatnych na wyczerpywanie 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 wykorzystaniem usługi NAT w Azure Virtual Network.
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 na Azure Firewall są SNATowane do jednego z prywatnych adresów IP zapory, aby zapewnić routing symetryczny. 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 Azure Firewall jest przetwarzany przez NAT dla komunikacji internetowej, co powoduje, że polecenie PORT jest postrzegane jako 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 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 Azure Firewall może potrwać średnio od trzech do pięciu minut, a aktualizacje równoległe nie są obsługiwane. Trwa badanie poprawki.
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 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 zasad zapory za pomocą portalu lub szablonów Azure Resource Manager (ARM) Azure Firewall Zasady mają ograniczenie obsługi poprawek, które uniemożliwia dodawanie tagu przy użyciu portalu Azure lub szablonów usługi 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 Azure PowerShell Set-AzFirewallPolicy, 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ń. Niewspierane.
Wystąpił błąd podczas tworzenia ponad 2000 kolekcji reguł. Maksymalna liczba kolekcji reguł NAT/aplikacji lub sieci to 2000 (limit Resource Manager). Limit 2000 reguł w kolekcji jest obecnym ograniczeniem.
Nie można wdrożyć zapory przy użyciu Availability Zones z nowo utworzonym publicznym adresem IP Podczas wdrażania zapory z Availability Zones 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 Azure Firewall nie jest obsługiwane w scenariuszu międzynierżawnym. 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 znajdujące się za Azure Firewall nie mogą łączyć się z docelowymi adresami reguł DNAT używając publicznego adresu IP zapory. Gdy maszyny wirtualne kierują ruch przez 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ż Azure Firewall nie obsługuje pętli zwrotnej ruchu z wewnętrznych maszyn wirtualnych do własnego publicznego adresu IP zapory dla celów reguł DNAT. Rozwiązanie tego ograniczenia jest obecnie w trakcie opracowywania.
Problemy z łącznością podczas routingu natywnego ruchu IPsec systemu operacyjnego z maszyn wirtualnych Azure do środowiska lokalnego za pośrednictwem Azure Firewall Standard W niektórych wdrożeniach hybrydowych Azure maszyny wirtualne używają natywnych tuneli IPsec systemu operacyjnego do łączenia się z sieciami lokalnymi. Gdy ten ruch jest kierowany przez Azure Firewall Standard — szczególnie wtedy, gdy jest zaangażowany VPN Gateway lub globalne peering VNet, pakiety IPsec mogą nie przechodzić przez zaporę, co może prowadzić do problemów z łącznością. Unikaj routingu natywnego ruchu IPsec systemu operacyjnego z maszyn wirtualnych Azure za pośrednictwem Azure Firewall Standard. Rozwiązanie tego ograniczenia jest obecnie w trakcie opracowywania.
Operacje zarządzania generują zapytania DNS widoczne w dziennikach Usługa Azure Firewall wykonuje wewnętrzne wyszukiwania DNS w ramach normalnego zarządzania i operacji platformy (na przykład aktualizacji konfiguracji, telemetrii i łączności z usługą). Te zapytania DNS mogą być wyświetlane w dziennikach usługi Azure DNS klienta lub narzędziach do monitorowania zabezpieczeń, mimo że nie są inicjowane przez ruch klientów. To zachowanie jest oczekiwane i nie wskazuje na błędną konfigurację lub problem z zabezpieczeniami. W razie potrzeby filtruj lub wyklucz znane domeny usług firmy Microsoft w zasadach monitorowania DNS.

znane problemy z Azure Firewall Premium

Uwaga / Notatka

Każdy problem, który dotyczy Standardu, dotyczy również Premium.

Azure Firewall Premium ma następujące znane problemy:

Problematyka Opis Mitigation
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. Zapora Azure (Azure firewall) renegocjuje połączenie z serwerem i nie ma dostępu do klucza prywatnego certyfikatów klienta. Żadne
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.
Problemy z łącznością podczas routingu natywnego ruchu IPsec systemu operacyjnego z maszyn wirtualnych Azure do środowiska lokalnego za pośrednictwem usługi Azure Firewall Premium W niektórych wdrożeniach hybrydowych Azure maszyny wirtualne używają natywnych tuneli IPsec systemu operacyjnego do łączenia się z sieciami lokalnymi. Gdy ten ruch jest kierowany przez Azure Firewall Standard — szczególnie wtedy, gdy jest zaangażowany VPN Gateway lub globalne peering VNet, pakiety IPsec mogą nie przechodzić przez zaporę, co może prowadzić do problemów z łącznością. Unikaj routingu natywnego ruchu IPsec systemu operacyjnego z maszyn wirtualnych Azure przez Azure Firewall Premium. Rozwiązanie tego ograniczenia jest obecnie w trakcie opracowywania.

Następne kroki

  • Last updated on