Znane problemy i ograniczenia usługi Azure Firewall
W tym artykule wymieniono znane problemy z usługą Azure Firewall. Jest on aktualizowany w miarę rozwiązywania problemów.
Aby uzyskać informacje o ograniczeniach usługi Azure Firewall, zobacz Limity, przydziały i ograniczenia subskrypcji i usług platformy Azure.
Usługa Azure Firewall w warstwie Standardowa
Usługa Azure Firewall w warstwie Standardowa ma następujące znane problemy:
Uwaga
Każdy problem, który ma zastosowanie do warstwy Standardowa, ma również zastosowanie do warstwy Premium.
| Problem | opis | Ograniczanie ryzyka |
|---|---|---|
| Obsługa DNAT prywatnych adresów IP ograniczonych do wersji Standardowa i Premium | Obsługa prywatnego adresu IP DNAT w usłudze Azure Firewall jest przeznaczona dla przedsiębiorstw, więc jest ograniczona do wersji zapory Standardowa i Premium. | Brak |
| 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. Protokoły inne niż TCP/UDP są obsługiwane między podsieciami szprych i sieciami wirtualnymi. | 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 tego scenariusza w przyszłej wersji. |
| 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ą portu: definicji protokołu. | Jako wartości portu i protokołu można użyć wartości https. Pracujemy nad tym polem opcjonalnym, gdy są używane tagi FQDN. |
| Przenoszenie zapory do innej grupy zasobów lub subskrypcji nie jest obsługiwane | Przenoszenie zapory 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żące wystąpienie i utworzyć je ponownie w nowej grupie zasobów lub subskrypcji. |
| Alerty analizy zagrożeń mogą zostać zamaskowane | Reguły sieciowe z docelową 80/443 dla filtrowania ruchu wychodzącego maskują alerty analizy zagrożeń, gdy są skonfigurowane do trybu tylko alertów. | 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ć Strefy dostępności po wdrożeniu zapory z zabezpieczonymi koncentratorami wirtualnymi. | Jest to celowe. |
| SNAT dla połączeń przychodzących | Oprócz DNAT połączenia za pośrednictwem publicznego adresu IP zapory (przychodzącego) są SNATed do jednego z prywatnych adresów IP zapory. To wymaganie dzisiaj (również dla aktywnych/aktywnych urządzeń WUS), aby zapewnić routing symetryczny. | Aby zachować oryginalne źródło dla protokołu HTTP/S, rozważ użycie nagłówków XFF . Na przykład użyj usługi, takiej jak Azure Front Door lub aplikacja systemu Azure Gateway przed zaporą. Zaporę aplikacji internetowej można również dodać jako część usługi Azure Front Door i połączyć łańcuch z zaporą. |
| Filtrowanie nazw FQDN SQL obsługuje tylko w trybie serwera proxy (port 1433) | W przypadku usług Azure SQL Database, Azure Synapse Analytics i Azure SQL Managed Instance: Filtrowanie nazw FQDN SQL jest obsługiwane tylko w trybie serwera 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. |
W przypadku języka SQL w trybie przekierowania (wartość domyślna w przypadku nawiązywania połączenia z poziomu platformy Azure) możesz zamiast tego filtrować dostęp przy użyciu tagu usługi SQL w ramach reguł sieciowych usługi Azure Firewall. |
| Ruch wychodzący SMTP na porcie TCP 25 jest zablokowany | 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 są blokowane przez platformę Azure. Jest to domyślne zachowanie 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 usługi Azure Firewall w standardowej subskrypcji Umowa Enterprise (EA). Usługa Azure Firewall w subskrypcji EA może komunikować się z publicznymi adresami IP przy użyciu wychodzącego portu TCP 25. Obecnie może również działać w innych typach subskrypcji, ale nie ma gwarancji, że działa. 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 wystąpienie zestawu skalowania 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 jest skalowana w górę do maksymalnie 20 wystąpień. | Jest to ograniczenie 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 sieci SNAT. Zwiększa to liczbę dostępnych portów SNAT o pięć razy. Przydziel z prefiksu adresu IP, aby uprościć uprawnienia podrzędne. Aby uzyskać bardziej trwałe rozwiązanie, można wdrożyć bramę translatora adresów sieciowych, aby przezwyciężyć limity portów SNAT. Takie podejście jest obsługiwane w przypadku wdrożeń sieci wirtualnych. Aby uzyskać więcej informacji, zobacz Skalowanie portów SNAT przy użyciu translatora adresów sieciowych platformy Azure. |
| Funkcja DNAT nie jest obsługiwana z włączonym wymuszonym tunelowaniem | Zapory wdrożone z włączonym wymuszonym tunelowaniem nie mogą obsługiwać dostępu przychodzącego z Internetu z powodu routingu asymetrycznego. | Jest to projektowe ze względu na routing asymetryczny. Ścieżka powrotna dla połączeń przychodzących przechodzi przez zaporę lokalną, która nie widziała 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 z wieloma publicznymi adresami IP wysyła dane wychodzące, losowo wybiera jeden z jego 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 tej sytuacji. |
| 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ą przekierowywane do jednego z prywatnych adresów IP zapory w celu zapewnienia routingu symetrycznego. 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. To 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 jest nated na potrzeby komunikacji internetowej, dzięki czemu polecenie PORT jest postrzegane jako nieprawidłowe przez serwer FTP. | Jest to ogólne ograniczenie usługi Active FTP w przypadku użycia z translatorem adresów sieciowych po stronie klienta. |
| Metryka NetworkRuleHit nie ma wymiaru protokołu | Metryka ApplicationRuleHit umożliwia filtrowanie opartego na protokole, ale ta funkcja nie istnieje w odpowiedniej 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. | To jest obecne ograniczenie. |
| Ś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 Wskazanie nazwy serwera dla oprogramowania obsługującego nazwy SNI. |
| Nie można dodać tagów zasad zapory przy użyciu portalu lub szablonów usługi Azure Resource Manager (ARM) | Usługa Azure Firewall Policy ma ograniczenie obsługi poprawek, które uniemożliwia dodawanie tagu przy użyciu witryny Azure Portal 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 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. |
| Aktualizowanie wielu grup adresów IP kończy się niepowodzeniem z powodu błędu powodującego konflikt. | Po zaktualizowaniu co najmniej dwóch grup adresów IP dołączonych do tej samej zapory jeden z zasobów przechodzi w stan niepowodzenia. | Jest to znany problem/ograniczenie. Po zaktualizowaniu grupy adresów IP wyzwala aktualizację wszystkich zapór dołączonych przez grupę IPGroup. Jeśli aktualizacja drugiej grupy adresów IP jest uruchomiona, gdy zapora jest nadal w stanie Aktualizowanie , aktualizacja grupy IP nie powiedzie się. Aby uniknąć awarii, grupy adresów IP dołączone do tej samej zapory muszą być aktualizowane pojedynczo. Zezwalaj na wystarczająco dużo czasu między aktualizacjami, aby umożliwić zaporze wyjście ze stanu aktualizacji . |
| Usuwanie grup RuleCollectionGroups przy użyciu szablonów usługi ARM nie jest obsługiwane. | Usunięcie regułyCollectionGroup przy użyciu szablonów usługi ARM nie jest obsługiwane i powoduje niepowodzenie. | Nie jest to obsługiwana operacja. |
| Reguła DNAT zezwala na dowolny ruch (*) będzie ruchem SNAT. | Jeśli reguła DNAT zezwala na dowolny element (*) jako źródłowy adres IP, niejawna reguła sieci odpowiada ruchowi sieci wirtualnej i zawsze SNAT ruchu. | To jest obecne ograniczenie. |
| Dodawanie reguły DNAT do zabezpieczonego koncentratora wirtualnego z dostawcą zabezpieczeń nie jest obsługiwane. | 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). | To jest obecne ograniczenie. |
| Nagłówek XFF w protokole HTTP/S | Nagłówki XFF są zastępowane oryginalnym źródłowym adresem IP widocznym przez zaporę. Dotyczy to następujących przypadków użycia: - Żądania HTTP - Żądania HTTPS z kończeniem żądań TLS |
Trwa badanie poprawki. |
| Nie można wdrożyć zapory z Strefy dostępności przy użyciu nowo utworzonego publicznego adresu IP | Podczas wdrażania zapory z Strefy 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. |
| Strefa fizyczna 2 w Europie Północnej jest niedostępna dla wdrożeń zapory. | Nie można wdrożyć nowej zapory ze strefą fizyczną 2. Ponadto w przypadku zatrzymania istniejącej zapory wdrożonej w strefie fizycznej 2 nie można jej ponownie uruchomić. Aby uzyskać więcej informacji, zobacz Strefy dostępności fizycznej i logicznej. | W przypadku nowych zapór należy wdrożyć pozostałe strefy dostępności lub użyć innego regionu. Aby skonfigurować istniejącą zaporę, zobacz Jak skonfigurować strefy dostępności po wdrożeniu?. |
Usługa Azure Firewall w warstwie Premium
Usługa Azure Firewall Premium ma następujące znane problemy:
| Problem | opis | Ograniczanie ryzyka |
|---|---|---|
| Obsługa funkcji ESNI na potrzeby rozpoznawania nazw FQDN w protokole 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 tej funkcji. |
| Uwierzytelnianie certyfikacji klienta 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. Usługa Azure Firewall renegocjatuje połączenie z serwerem i nie ma dostępu do klucza prywatnego certyfikatów klienta. | Brak |
| QUIC/HTTP3 | QUIC to nowa wersja główna protokołu HTTP. Jest to protokół oparty na protokole UDP ponad 80 (PLAN) i 443 (SSL). Inspekcja nazwy FQDN/adresu URL/protokołu TLS nie jest obsługiwana. | Skonfiguruj przekazywanie protokołu UDP 80/443 jako reguł sieciowych. |
| Niezaufane certyfikaty podpisane przez klienta | Certyfikaty podpisane przez klienta nie są zaufane przez zaporę po odebraniu z intranetowego serwera internetowego. | Trwa badanie poprawki. |
| Nieprawidłowy źródłowy adres IP w alertach z dostawcą tożsamości dla protokołu HTTP (bez inspekcji protokołu TLS). | Gdy ruch HTTP w postaci zwykłego tekstu jest używany, a dostawcy tożsamości wystawiają nowy alert, a miejsce docelowe jest publicznym adresem IP, wyświetlany źródłowy adres IP jest nieprawidłowy (wewnętrzny adres IP jest wyświetlany zamiast oryginalnego adresu IP). | Trwa badanie poprawki. |
| Propagacja certyfikatu | Po zastosowaniu certyfikatu urzędu certyfikacji w zaporze może upłynąć od 5 do 10 minut, aby certyfikat mógł zostać zastosowany. | 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 certyfikatu pośredniego urzędu certyfikacji 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 oryginalną datą wygaśnięcia. Trwa badanie poprawki. |