Zapora platformy Azure — często zadawane pytania

Ogólne

Co to jest usługa Azure Firewall?

Azure Firewall to zarządzana, sieciowa usługa zabezpieczeń oparta na chmurze, która zabezpiecza zasoby usługi Azure Virtual Network. Jest to w pełni stanowa zapora jako usługa z wbudowaną wysoką dostępnością i nieograniczoną skalowalnością chmury. Możesz centralnie tworzyć, wymuszać i rejestrować zasady łączności aplikacji i sieci w subskrypcjach i sieciach wirtualnych.

Jakie możliwości obsługuje usługa Azure Firewall?

Aby uzyskać szczegółową listę funkcji usługi Azure Firewall, zobacz Funkcje usługi Azure Firewall.

Jaki jest typowy model wdrażania usługi Azure Firewall?

Usługę Azure Firewall można wdrożyć w dowolnej sieci wirtualnej. Jednak jest on zwykle wdrażany w centralnej sieci wirtualnej w modelu piasty i szprych, z innymi sieciami wirtualnymi równorzędnymi. Domyślna trasa z równorzędnych sieci wirtualnych jest ustawiona tak, aby wskazywała tę centralną sieć wirtualną zapory. Chociaż globalna komunikacja równorzędna sieci wirtualnych jest obsługiwana, nie jest zalecana ze względu na potencjalne problemy z wydajnością i opóźnieniami w różnych regionach. Aby uzyskać optymalną wydajność, wdróż jedną zaporę na region.

Ten model umożliwia scentralizowaną kontrolę nad wieloma sieciami wirtualnymi szprych w różnych subskrypcjach i oferuje oszczędności kosztów, unikając konieczności wdrażania zapory w każdej sieci wirtualnej. Oszczędności kosztów należy ocenić na podstawie skojarzonych kosztów komunikacji równorzędnej na podstawie wzorców ruchu.

Jak wdrożyć usługę Azure Firewall?

Usługę Azure Firewall można wdrożyć przy użyciu witryny Azure Portal, programu PowerShell, interfejsu API REST lub szablonów. Aby uzyskać instrukcje krok po kroku, zobacz Samouczek: wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu witryny Azure Portal.

Jakie są kluczowe pojęcia dotyczące usługi Azure Firewall?

Usługa Azure Firewall używa reguł i kolekcji reguł. Kolekcja reguł to zestaw reguł z tą samą kolejnością i priorytetem. Kolekcje reguł są wykonywane w kolejności priorytetu. Kolekcje reguł DNAT mają wyższy priorytet niż kolekcje reguł sieciowych, które z kolei mają wyższy priorytet niż kolekcje reguł aplikacji. Wszystkie reguły kończą się.

Istnieją trzy typy kolekcji reguł:

• Reguły aplikacji: skonfiguruj w pełni kwalifikowane nazwy domen (FQDN), do których można uzyskać dostęp z sieci wirtualnej.
• Reguły sieci: skonfiguruj reguły z adresami źródłowymi, protokołami, portami docelowymi i adresami docelowymi.
• Reguły NAT: skonfiguruj reguły DNAT, aby zezwalać na przychodzące połączenia internetowe lub intranetowe (wersja zapoznawcza).

Aby uzyskać więcej informacji, zobacz Konfigurowanie reguł usługi Azure Firewall.

Które usługi rejestrowania i analizy obsługują usługę Azure Firewall?

Usługa Azure Firewall integruje się z usługą Azure Monitor do wyświetlania i analizowania dzienników. Dzienniki można wysyłać do usługi Log Analytics, Azure Storage lub Event Hubs i analizować przy użyciu narzędzi, takich jak Log Analytics, Excel lub Power BI. Aby uzyskać więcej informacji, zobacz Samouczek: monitorowanie dzienników usługi Azure Firewall.

Czym różni się usługa Azure Firewall od urządzeń WUS w witrynie Marketplace?

Azure Firewall to zarządzana usługa zabezpieczeń sieci oparta na chmurze, która chroni zasoby sieci wirtualnej. Jest to w pełni stanowa zapora jako usługa z wbudowaną wysoką dostępnością i nieograniczoną skalowalnością chmury. Jest ona wstępnie całkowita z dostawcami zabezpieczeń jako usługi (SECaaS) innych firm, aby zwiększyć bezpieczeństwo sieci wirtualnej i połączeń internetowych gałęzi. Aby uzyskać więcej informacji, zobacz Zabezpieczenia sieci platformy Azure.

Jaka jest różnica między zaporą aplikacji internetowej usługi Application Gateway i usługą Azure Firewall?

Zapora aplikacji internetowej usługi Application Gateway zapewnia scentralizowaną ochronę ruchu przychodzącego dla aplikacji internetowych przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach. Usługa Azure Firewall zapewnia ochronę ruchu przychodzącego dla protokołów innych niż HTTP/S (na przykład RDP, SSH, FTP), ochrony na poziomie sieci wychodzącej dla wszystkich portów i protokołów oraz ochrony na poziomie aplikacji dla wychodzących protokołów HTTP/S.

Jaka jest różnica między sieciowymi grupami zabezpieczeń i usługą Azure Firewall?

Usługa Azure Firewall uzupełnia sieciowe grupy zabezpieczeń w celu zapewnienia lepszego "zabezpieczenia w głębi systemu" zabezpieczeń sieci. Sieciowe grupy zabezpieczeń oferują rozproszone filtrowanie ruchu w warstwie sieciowej w celu ograniczenia ruchu w sieciach wirtualnych w każdej subskrypcji. Usługa Azure Firewall zapewnia scentralizowaną, w pełni stanową ochronę sieci i aplikacji w subskrypcjach i sieciach wirtualnych.

Czy sieciowe grupy zabezpieczeń są obsługiwane w podsieci AzureFirewallSubnet?

Azure Firewall to zarządzana usługa z wieloma warstwami ochrony, w tym ochrona platformy z sieciowymi grupami zabezpieczeń na poziomie karty sieciowej (nie można wyświetlić). Sieciowe grupy zabezpieczeń na poziomie podsieci nie są wymagane w podsieci AzureFirewallSubnet i są wyłączone, aby zapobiec przerwom w działaniu usługi.

Jaka jest wartość dodana usługi Azure Firewall z prywatnymi punktami końcowymi?

Prywatne punkty końcowe są składnikiem usługi Private Link, czyli technologii, która umożliwia interakcję z usługami PaaS platformy Azure przy użyciu prywatnych adresów IP zamiast publicznych. Usługa Azure Firewall może służyć do zapobiegania dostępowi do publicznych adresów IP, dlatego unikając eksfiltracji danych do usług platformy Azure, które nie korzystają z usługi Private Link, a także do implementowania zasad o zerowym zaufaniu, definiując, kto w organizacji musi uzyskać dostęp do tych usług Azure PaaS, ponieważ usługa Private Link na domyślne otwiera dostęp sieciowy dla całej sieci firmowej.

Odpowiedni projekt inspekcji ruchu do prywatnych punktów końcowych za pomocą usługi Azure Firewall będzie zależeć od architektury sieci. Więcej szczegółów można znaleźć w artykule Scenariusze usługi Azure Firewall w celu sprawdzenia ruchu kierowanego do prywatnego punktu końcowego.

Jaka jest wartość dodana usługi Azure Firewall z punktami końcowymi usługi sieci wirtualnej?

Punkty końcowe usługi sieci wirtualnej są alternatywą dla usługi Private Link w celu kontrolowania dostępu sieciowego do usług PaaS platformy Azure. Nawet jeśli klient nadal używa publicznych adresów IP w celu uzyskania dostępu do usługi PaaS, podsieć źródłowa jest widoczna, aby docelowa usługa PaaS mogła implementować reguły filtrowania i ograniczać dostęp dla poszczególnych podsieci. Szczegółowe porównanie obu mechanizmów można znaleźć w artykule Porównanie prywatnych punktów końcowych i punktów końcowych usługi.

Reguły aplikacji usługi Azure Firewall mogą służyć do upewnienia się, że nie ma miejsca eksfiltracja danych w celu nieautoryzowanych usług i zaimplementowania zasad dostępu ze zwiększonym poziomem szczegółowości poza poziomem podsieci. Zazwyczaj punkty końcowe usługi sieci wirtualnej muszą być włączone w podsieci klienta, który będzie łączyć się z usługą platformy Azure. Jednak podczas inspekcji ruchu do punktów końcowych usługi za pomocą usługi Azure Firewall należy włączyć odpowiedni punkt końcowy usługi w podsieci usługi Azure Firewall i wyłączyć go w podsieci rzeczywistego klienta (zazwyczaj sieci wirtualnej będącej szprychą). W ten sposób możesz użyć reguł aplikacji w usłudze Azure Firewall, aby kontrolować, do których usług platformy Azure będą miały dostęp obciążenia platformy Azure.

Jakie są ceny usługi Azure Firewall?

Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Firewall.

Jakie są znane limity usług dla usługi Azure Firewall?

Aby uzyskać informacje o limitach usług, zobacz Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure.

Gdzie usługa Azure Firewall przechowuje dane klientów?

Usługa Azure Firewall nie przenosi ani nie przechowuje danych klientów poza regionem, w którym jest wdrażany.

Czy usługa Azure Firewall w zabezpieczonych koncentratorach wirtualnych (vWAN) jest obsługiwana w Katarze?

Nie, usługa Azure Firewall w zabezpieczonych koncentratorach wirtualnych (vWAN) nie jest obecnie obsługiwana w Katarze.

Obsługiwane możliwości i funkcje

Czy usługa Azure Firewall obsługuje filtrowanie ruchu przychodzącego?

Tak, usługa Azure Firewall obsługuje filtrowanie ruchu przychodzącego i wychodzącego. Filtrowanie przychodzące jest zwykle używane w przypadku protokołów innych niż HTTP, takich jak RDP, SSH i FTP. W przypadku przychodzącego ruchu HTTP i HTTPS rozważ użycie zapory aplikacji internetowej, takiej jak zapora aplikacji internetowej platformy Azure lub odciążanie protokołu TLS i głębokie funkcje inspekcji pakietów usługi Azure Firewall Premium.

Czy usługa Azure Firewall w warstwie Podstawowa obsługuje wymuszone tunelowanie?

Tak, usługa Azure Firewall w warstwie Podstawowa obsługuje wymuszone tunelowanie.

Dlaczego polecenie ping protokołu TCP lub podobne narzędzie wydaje się łączyć się z docelową nazwą FQDN nawet wtedy, gdy żadna reguła nie zezwala na ruch?

Polecenie ping TCP nie łączy się z docelową nazwą FQDN. Usługa Azure Firewall blokuje połączenia z dowolnym docelowym adresem IP lub nazwą FQDN, chyba że jest jawnie dozwolona przez regułę.

W przypadku polecenia ping TCP, jeśli żadna reguła nie zezwala na ruch, sama zapora odpowiada na żądanie ping TCP klienta. Ta odpowiedź nie osiąga docelowego adresu IP ani nazwy FQDN i nie jest rejestrowana. Jeśli reguła sieci jawnie zezwala na dostęp do docelowego adresu IP lub nazwy FQDN, żądanie ping dociera do serwera docelowego, a jego odpowiedź jest przekazywana z powrotem do klienta. To zdarzenie jest rejestrowane w dzienniku reguł sieciowych.

Czy usługa Azure Firewall obsługuje komunikację równorzędną BGP?

Nie, usługa Azure Firewall nie obsługuje natywnie komunikacji równorzędnej BGP. Jednak funkcja automatycznego uczenia tras SNAT pośrednio używa protokołu BGP za pośrednictwem usługi Azure Route Server.

Zarządzanie i konfiguracja

Jak mogę zatrzymać i uruchomić usługę Azure Firewall?

Za pomocą programu Azure PowerShell można cofnąć przydział i przydzielić usługę Azure Firewall. Proces różni się w zależności od konfiguracji.

Zapora bez karty sieciowej zarządzania:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Zapora z kartą sieciową zarządzania:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Zapora w zabezpieczonym koncentratonie wirtualnym:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Uwaga

Podczas zatrzymywania i uruchamiania zapory rozliczenia są zatrzymywane i uruchamiane odpowiednio. Jednak prywatny adres IP może ulec zmianie, co może mieć wpływ na łączność w przypadku skonfigurowania tabel tras.

Jak skonfigurować strefy dostępności po wdrożeniu?

Zaleca się skonfigurowanie stref dostępności podczas początkowego wdrażania. Można je jednak ponownie skonfigurować po wdrożeniu, jeśli:

• Zapora jest wdrażana w sieci wirtualnej (nieobsługiwana w zabezpieczonych koncentratorach wirtualnych).
• Region obsługuje strefy dostępności.
• Wszystkie dołączone publiczne adresy IP są konfigurowane z tymi samymi strefami.

Aby ponownie skonfigurować strefy dostępności:

1. Cofnij przydział zapory:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Zaktualizuj konfigurację strefy i przydziel zaporę:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Czy istnieją ograniczenia grupy zasobów usługi Azure Firewall?

Tak:

• Usługa Azure Firewall i sieć wirtualna muszą znajdować się w tej samej grupie zasobów.
• Publiczny adres IP może znajdować się w innej grupie zasobów.
• Wszystkie zasoby (zapora platformy Azure, sieć wirtualna, publiczny adres IP) muszą znajdować się w tej samej subskrypcji.

Co oznacza stan aprowizacji **Niepowodzenie**?

Stan aprowizacji Niepowodzenie wskazuje, że aktualizacja konfiguracji nie powiodła się w co najmniej jednym wystąpieniu zaplecza. Usługa Azure Firewall pozostaje operacyjna, ale konfiguracja może być niespójna. Ponów próbę aktualizacji, dopóki stan aprowizacji nie zmieni się na Powodzenie.

Jak usługa Azure Firewall obsługuje planowaną konserwację i nieplanowane błędy?

Usługa Azure Firewall używa konfiguracji aktywne-aktywne z wieloma węzłami zaplecza. Podczas planowanej konserwacji opróżnianie połączeń zapewnia bezproblemowe aktualizacje. W przypadku nieplanowanych awarii nowy węzeł zastępuje ten, który zakończył się niepowodzeniem, a łączność jest zwykle przywracana w ciągu 10 sekund.

Czy istnieje limit znaków dla nazwy zapory?

Tak, nazwy zapory są ograniczone do 50 znaków.

Dlaczego usługa Azure Firewall potrzebuje rozmiaru podsieci /26?

Podsieć /26 zapewnia wystarczające adresy IP do skalowania, ponieważ usługa Azure Firewall aprowizuje dodatkowe wystąpienia maszyn wirtualnych.

Czy rozmiar podsieci zapory musi ulec zmianie w miarę skalowania usługi?

Nie, podsieć /26 jest wystarczająca dla wszystkich scenariuszy skalowania.

Jak mogę zwiększyć przepływność zapory?

Usługa Azure Firewall jest skalowana automatycznie na podstawie użycia procesora CPU, przepływności i liczby połączeń. Pojemność przepływności waha się od 2,5 do 3 Gb/s początkowo do 30 Gb/s (jednostka SKU w warstwie Standardowa) lub 100 Gb/s (jednostka SKU w warstwie Premium).

Czy istnieją limity liczby adresów IP obsługiwanych przez grupy adresów IP?

Tak. Aby uzyskać szczegółowe informacje, zobacz Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure.

Czy mogę przenieść grupę adresów IP do innej grupy zasobów?

Nie, przenoszenie grupy adresów IP do innej grupy zasobów nie jest obecnie obsługiwane.

Jaki jest limit czasu bezczynności protokołu TCP dla usługi Azure Firewall?

Standardowe zachowanie zapory sieciowej polega na upewnieniu się, że połączenia TCP są aktywne i aby szybko je zamknąć, jeśli nie ma żadnej aktywności. Limit czasu bezczynności protokołu TCP usługi Azure Firewall wynosi cztery minuty. To ustawienie nie jest konfigurowalne przez użytkownika, ale możesz skontaktować się z pomocą techniczną platformy Azure, aby zwiększyć limit czasu bezczynności dla połączeń przychodzących i wychodzących do 15 minut. Nie można zmienić limitu czasu bezczynności dla ruchu wschodnio-zachodniego.

Jeśli okres braku aktywności jest dłuższy niż wartość limitu czasu, nie ma gwarancji, że sesja TCP lub HTTP jest utrzymywana. Powszechną praktyką jest użycie protokołu TCP keep-alive. Ta praktyka utrzymuje aktywne połączenie przez dłuższy czas. Aby uzyskać więcej informacji, zobacz przykłady platformy .NET.

Czy można wdrożyć usługę Azure Firewall bez publicznego adresu IP?

Tak, ale należy skonfigurować zaporę w trybie wymuszonego tunelowania. Ta konfiguracja tworzy interfejs zarządzania z publicznym adresem IP używanym przez usługę Azure Firewall do wykonywania operacji. Ten publiczny adres IP jest przeznaczony dla ruchu zarządzania. Jest ona używana wyłącznie przez platformę Azure i nie może być używana do żadnego innego celu. Sieć ścieżki danych dzierżawy można skonfigurować bez publicznego adresu IP, a ruch internetowy może zostać wymuszony tunelowany do innej zapory lub całkowicie zablokowany.

Czy istnieje sposób automatycznego tworzenia kopii zapasowej usługi Azure Firewall i zasad?

Tak. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych usługi Azure Firewall i zasad usługi Azure Firewall przy użyciu usługi Logic Apps.

Łączność i routing

Jak skonfigurować usługę Azure Firewall z moimi punktami końcowymi usług?

Aby zapewnić bezpieczny dostęp do usług PaaS, zalecamy punkty końcowe usługi. Możesz włączyć punkty końcowe usług w podsieci usługi Azure Firewall i wyłączyć je w połączonych sieciach wirtualnych będących szprychami. Dzięki temu możesz korzystać z obu funkcji: zabezpieczeń punktu końcowego usługi i centralnego rejestrowania dla całego ruchu.

Czy usługa Azure Firewall w sieci wirtualnej piasty może przekazywać dalej i filtrować ruch sieciowy między wieloma sieciami wirtualnymi szprych?

Tak, możesz użyć usługi Azure Firewall w sieci wirtualnej koncentratora do kierowania i filtrowania ruchu między wieloma sieciami wirtualnymi szprych. Podsieci w każdej sieci wirtualnej będącej szprychami muszą mieć trasę zdefiniowaną przez użytkownika wskazującą usługę Azure Firewall jako bramę domyślną, aby ten scenariusz działał prawidłowo.

Czy usługa Azure Firewall może przekazywać dalej i filtrować ruch sieciowy między podsieciami w tej samej sieci wirtualnej lub równorzędnych sieciach wirtualnych?

Tak. Jednak skonfigurowanie tras zdefiniowanych przez użytkownika w celu przekierowania ruchu między podsieciami w tej samej sieci wirtualnej wymaga większej uwagi. W przypadku używania zakresu adresów sieci wirtualnej jako prefiksu docelowego trasy zdefiniowanej przez użytkownika jest wystarczająca, spowoduje to również kierowanie całego ruchu z jednej maszyny do innej maszyny w tej samej podsieci za pośrednictwem wystąpienia usługi Azure Firewall. Aby tego uniknąć, dołącz trasę dla podsieci w trasie zdefiniowanej przez użytkownika z typem następnego przeskoku sieci wirtualnej. Zarządzanie tymi trasami może być uciążliwe i podatne na błędy. Zalecaną metodą segmentacji sieci wewnętrznej jest użycie sieciowych grup zabezpieczeń, które nie wymagają tras zdefiniowanych przez użytkownika.

Czy usługa Azure Firewall wychodząca usługa SNAT między sieciami prywatnymi?

Usługa Azure Firewall nie obsługuje protokołu SNAT, gdy docelowy adres IP jest prywatnym zakresem adresów IP dla sieci prywatnych IANA RFC 1918 lub IANA RFC 6598 . Jeśli organizacja używa publicznego zakresu adresów IP dla sieci prywatnych, usługa Azure Firewall SNATs ruchu do jednego z prywatnych adresów IP zapory w podsieci AzureFirewallSubnet. Usługę Azure Firewall można skonfigurować tak, aby nie SNAT był twoim zakresem publicznych adresów IP. Aby uzyskać więcej informacji, zobacz Usługa SNAT dla zakresów prywatnych adresów IP w usłudze Azure Firewall.

Ponadto ruch przetwarzany przez reguły aplikacji jest zawsze sNAT-ed. Jeśli chcesz zobaczyć oryginalny źródłowy adres IP w dziennikach dla ruchu FQDN, możesz użyć reguł sieci z docelową nazwą FQDN.

Czy wymuszone tunelowanie/łączenie łańcuchowe z wirtualnym urządzeniem sieciowym jest obsługiwane?

Wymuszone tunelowanie jest obsługiwane podczas tworzenia nowej zapory. Nie można skonfigurować istniejącej zapory na potrzeby wymuszonego tunelowania. Aby uzyskać więcej informacji, zobacz Wymuszone tunelowanie usługi Azure Firewall.

Usługa Azure Firewall musi mieć bezpośrednie połączenie z Internetem. Jeśli twoja sieć AzureFirewallSubnet poznaje domyślną trasę do sieci lokalnej za pośrednictwem protokołu BGP, należy zastąpić ją trasą zdefiniowaną przez użytkownika 0.0.0.0/0 z wartością NextHopType ustawioną jako Internet, aby zachować bezpośrednią łączność z Internetem .

Jeśli konfiguracja wymaga wymuszonego tunelowania do sieci lokalnej i można określić docelowe prefiksy adresów IP dla miejsc docelowych w Internecie, możesz skonfigurować te zakresy z siecią lokalną jako następny przeskok za pośrednictwem trasy zdefiniowanej przez użytkownika w podsieci AzureFirewallSubnet. Możesz też użyć protokołu BGP do zdefiniowania tych tras.

Jak działają symbole wieloznaczne w docelowych adresach URL i docelowych nazwach FQDN w regułach aplikacji?

• ADRES URL — gwiazdki działają po prawej lub lewej stronie. Jeśli znajduje się po lewej stronie, nie może być częścią nazwy FQDN.
• Nazwa FQDN — gwiazdki działają po lewej stronie.
• OGÓLNE — gwiazdki po lewej stronie oznaczają dosłownie wszystkie dopasowania do lewej strony, co oznacza, że wiele domen podrzędnych i/lub potencjalnie niechcianych odmian nazw domen jest dopasowanych - zobacz następujące przykłady.

Przykłady:

Typ	Reguła	Obsługiwane?	Przykłady pozytywne
TargetURL	www.contoso.com	Tak	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	Tak	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	Tak	example.anycontoso.com sub1.example.contoso.com contoso.com Ostrzeżenie: to użycie symboli wieloznacznych umożliwia również potencjalnie niepożądane/ryzykowne odmiany, takie jak th3re4lcontoso.com - należy używać z ostrożnością.
TargetURL	www.contoso.com/test	Tak	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	Tak	www.contoso.com/test/anything Uwaga: www.contoso.com/testnie jest zgodna (ostatni ukośnik)
TargetURL	www.contoso.*/test/*	Nie.
TargetURL	www.contoso.com/test?example=1	Nie.
TargetURL	www.contoso.*	Nie.
TargetURL	www.*contoso.com	Nie.
TargetURL	www.contoso.com:8080	Nie.
TargetURL	*.contoso.*	Nie.
Nazwa docelowaFQDN	www.contoso.com	Tak	www.contoso.com
Nazwa docelowaFQDN	*.contoso.com	Tak	any.contoso.com Uwaga: jeśli chcesz zezwolić contoso.comna korzystanie z usługi , musisz uwzględnić contoso.com w regule. W przeciwnym razie połączenie jest domyślnie porzucone, ponieważ żądanie nie jest zgodne z żadną regułą.
Nazwa docelowaFQDN	*contoso.com	Tak	example.anycontoso.com contoso.com
Nazwa docelowaFQDN	www.contoso.*	Nie.
Nazwa docelowaFQDN	*.contoso.*	Nie.

Czy usługa Azure Firewall domyślnie zezwala na dostęp do usługi Active Directory?

L.p. Usługa Azure Firewall domyślnie blokuje dostęp do usługi Active Directory. Aby zezwolić na dostęp, skonfiguruj tag usługi AzureActiveDirectory. Aby uzyskać więcej informacji, zobacz Tagi usługi Azure Firewall.

Czy mogę wykluczyć nazwę FQDN lub adres IP z filtrowania opartego na usłudze Azure Firewall Threat Intelligence?

Tak, możesz użyć programu Azure PowerShell, aby to zrobić:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Jakie jest zachowanie ponownego użycia portu TCP/UDP protokołu SNAT w usłudze Azure Firewall?

Usługa Azure Firewall obecnie używa portów źródłowych TCP/UDP dla wychodzącego ruchu SNAT bezczynności. Po zamknięciu połączenia TCP/UDP używany port TCP jest natychmiast widoczny jako dostępny dla nadchodzących połączeń.

Aby obejść niektóre architektury, można wdrożyć i skalować za pomocą bramy translatora adresów sieciowych za pomocą usługi Azure Firewall , aby zapewnić szerszą pulę portów SNAT w celu zapewnienia zmienności i dostępności.

Co to są zachowania translatora adresów sieciowych w usłudze Azure Firewall?

Określone zachowania translatora adresów sieciowych zależą od konfiguracji zapory i typu skonfigurowanego translatora adresów sieciowych. Na przykład zapora ma reguły DNAT dla ruchu przychodzącego, a reguły sieci i reguły aplikacji dla ruchu wychodzącego przez zaporę.

Aby uzyskać więcej informacji, zobacz Zachowania translatora adresów sieciowych usługi Azure Firewall.

Limity czasu i skalowanie

Jak działa opróżnianie połączeń?

W przypadku każdej planowanej konserwacji logika opróżniania połączeń bezpiecznie aktualizuje węzły zaplecza. Usługa Azure Firewall czeka 90 sekund na zamknięcie istniejących połączeń. W ciągu pierwszych 45 sekund węzeł zaplecza nie akceptuje nowych połączeń, a w pozostałym czasie odpowiada RST na wszystkie pakiety przychodzące. W razie potrzeby klienci mogą automatycznie ponownie nawiązać łączność z innym węzłem zaplecza.

Jak usługa Azure Firewall obsługuje zamykanie wystąpień maszyn wirtualnych podczas skalowania zestawu skalowania maszyn wirtualnych w dół (skalowanie w dół) lub uaktualnienia oprogramowania floty?

Zamknięcie wystąpienia maszyny wirtualnej usługi Azure Firewall może wystąpić podczas skalowania zestawu skalowania maszyn wirtualnych w dół (skalowanie w dół) lub podczas uaktualniania oprogramowania floty. W takich przypadkach nowe połączenia przychodzące są równoważone do pozostałych wystąpień zapory i nie są przekazywane do wystąpienia zapory w dół. Po 45 sekundach zapora zacznie odrzucać istniejące połączenia, wysyłając pakiety TCP RST. Po kolejnych 45 sekundach maszyna wirtualna zapory zostanie zamknięta. Aby uzyskać więcej informacji, zobacz Load Balancer TCP Reset and Idle Timeout (Resetowanie protokołu TCP modułu równoważenia obciążenia i limit czasu bezczynności).

Jak długo trwa skalowanie usługi Azure Firewall w poziomie?

Usługa Azure Firewall stopniowo skaluje się, gdy średnia produktywność lub wykorzystanie procesorów wynosi 60%, albo liczba wykorzystywanych połączeń wynosi 80%. Na przykład rozpoczyna zwiększanie skali w poziomie, gdy osiągnie 60% maksymalnej produktywności. Maksymalna liczba przepływności różni się w zależności od jednostki SKU usługi Azure Firewall i funkcji z obsługą. Aby uzyskać więcej informacji, zobacz Wydajność usługi Azure Firewall.

Skalowanie w poziomie trwa od pięciu do siedmiu minut. Podczas testowania wydajności upewnij się, że testujesz przez co najmniej 10 do 15 minut, a następnie rozpocznij nowe połączenia, aby skorzystać z nowo utworzonych węzłów usługi Azure Firewall.

Jak usługa Azure Firewall obsługuje limity czasu bezczynności?

Jeśli połączenie ma limit czasu bezczynności (cztery minuty braku aktywności), usługa Azure Firewall bezpiecznie przerywa połączenie, wysyłając pakiet TCP RST.

Azure Firewall to zarządzana, sieciowa usługa zabezpieczeń oparta na chmurze, która zabezpiecza zasoby usługi Azure Virtual Network. Jest to w pełni stanowa zapora jako usługa z wbudowaną wysoką dostępnością i nieograniczoną skalowalnością chmury. Możesz centralnie tworzyć, wymuszać i rejestrować zasady łączności aplikacji i sieci w subskrypcjach i sieciach wirtualnych.

Aby uzyskać szczegółową listę funkcji usługi Azure Firewall, zobacz Funkcje usługi Azure Firewall.

Usługę Azure Firewall można wdrożyć w dowolnej sieci wirtualnej. Jednak jest on zwykle wdrażany w centralnej sieci wirtualnej w modelu piasty i szprych, z innymi sieciami wirtualnymi równorzędnymi. Domyślna trasa z równorzędnych sieci wirtualnych jest ustawiona tak, aby wskazywała tę centralną sieć wirtualną zapory. Chociaż globalna komunikacja równorzędna sieci wirtualnych jest obsługiwana, nie jest zalecana ze względu na potencjalne problemy z wydajnością i opóźnieniami w różnych regionach. Aby uzyskać optymalną wydajność, wdróż jedną zaporę na region.

Ten model umożliwia scentralizowaną kontrolę nad wieloma sieciami wirtualnymi szprych w różnych subskrypcjach i oferuje oszczędności kosztów, unikając konieczności wdrażania zapory w każdej sieci wirtualnej. Oszczędności kosztów należy ocenić na podstawie skojarzonych kosztów komunikacji równorzędnej na podstawie wzorców ruchu.

Usługę Azure Firewall można wdrożyć przy użyciu witryny Azure Portal, programu PowerShell, interfejsu API REST lub szablonów. Aby uzyskać instrukcje krok po kroku, zobacz Samouczek: wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu witryny Azure Portal.

Usługa Azure Firewall używa reguł i kolekcji reguł. Kolekcja reguł to zestaw reguł z tą samą kolejnością i priorytetem. Kolekcje reguł są wykonywane w kolejności priorytetu. Kolekcje reguł DNAT mają wyższy priorytet niż kolekcje reguł sieciowych, które z kolei mają wyższy priorytet niż kolekcje reguł aplikacji. Wszystkie reguły kończą się.

Istnieją trzy typy kolekcji reguł:

• Reguły aplikacji: skonfiguruj w pełni kwalifikowane nazwy domen (FQDN), do których można uzyskać dostęp z sieci wirtualnej.
• Reguły sieci: skonfiguruj reguły z adresami źródłowymi, protokołami, portami docelowymi i adresami docelowymi.
• Reguły NAT: skonfiguruj reguły DNAT, aby zezwalać na przychodzące połączenia internetowe lub intranetowe (wersja zapoznawcza).

Aby uzyskać więcej informacji, zobacz Konfigurowanie reguł usługi Azure Firewall.

Usługa Azure Firewall integruje się z usługą Azure Monitor do wyświetlania i analizowania dzienników. Dzienniki można wysyłać do usługi Log Analytics, Azure Storage lub Event Hubs i analizować przy użyciu narzędzi, takich jak Log Analytics, Excel lub Power BI. Aby uzyskać więcej informacji, zobacz Samouczek: monitorowanie dzienników usługi Azure Firewall.

Azure Firewall to zarządzana usługa zabezpieczeń sieci oparta na chmurze, która chroni zasoby sieci wirtualnej. Jest to w pełni stanowa zapora jako usługa z wbudowaną wysoką dostępnością i nieograniczoną skalowalnością chmury. Jest ona wstępnie całkowita z dostawcami zabezpieczeń jako usługi (SECaaS) innych firm, aby zwiększyć bezpieczeństwo sieci wirtualnej i połączeń internetowych gałęzi. Aby uzyskać więcej informacji, zobacz Zabezpieczenia sieci platformy Azure.

Zapora aplikacji internetowej usługi Application Gateway zapewnia scentralizowaną ochronę ruchu przychodzącego dla aplikacji internetowych przed typowymi lukami w zabezpieczeniach i lukami w zabezpieczeniach. Usługa Azure Firewall zapewnia ochronę ruchu przychodzącego dla protokołów innych niż HTTP/S (na przykład RDP, SSH, FTP), ochrony na poziomie sieci wychodzącej dla wszystkich portów i protokołów oraz ochrony na poziomie aplikacji dla wychodzących protokołów HTTP/S.

Usługa Azure Firewall uzupełnia sieciowe grupy zabezpieczeń w celu zapewnienia lepszego "zabezpieczenia w głębi systemu" zabezpieczeń sieci. Sieciowe grupy zabezpieczeń oferują rozproszone filtrowanie ruchu w warstwie sieciowej w celu ograniczenia ruchu w sieciach wirtualnych w każdej subskrypcji. Usługa Azure Firewall zapewnia scentralizowaną, w pełni stanową ochronę sieci i aplikacji w subskrypcjach i sieciach wirtualnych.

Azure Firewall to zarządzana usługa z wieloma warstwami ochrony, w tym ochrona platformy z sieciowymi grupami zabezpieczeń na poziomie karty sieciowej (nie można wyświetlić). Sieciowe grupy zabezpieczeń na poziomie podsieci nie są wymagane w podsieci AzureFirewallSubnet i są wyłączone, aby zapobiec przerwom w działaniu usługi.

Prywatne punkty końcowe są składnikiem usługi Private Link, czyli technologii, która umożliwia interakcję z usługami PaaS platformy Azure przy użyciu prywatnych adresów IP zamiast publicznych. Usługa Azure Firewall może służyć do zapobiegania dostępowi do publicznych adresów IP, dlatego unikając eksfiltracji danych do usług platformy Azure, które nie korzystają z usługi Private Link, a także do implementowania zasad o zerowym zaufaniu, definiując, kto w organizacji musi uzyskać dostęp do tych usług Azure PaaS, ponieważ usługa Private Link na domyślne otwiera dostęp sieciowy dla całej sieci firmowej.

Odpowiedni projekt inspekcji ruchu do prywatnych punktów końcowych za pomocą usługi Azure Firewall będzie zależeć od architektury sieci. Więcej szczegółów można znaleźć w artykule Scenariusze usługi Azure Firewall w celu sprawdzenia ruchu kierowanego do prywatnego punktu końcowego.

Punkty końcowe usługi sieci wirtualnej są alternatywą dla usługi Private Link w celu kontrolowania dostępu sieciowego do usług PaaS platformy Azure. Nawet jeśli klient nadal używa publicznych adresów IP w celu uzyskania dostępu do usługi PaaS, podsieć źródłowa jest widoczna, aby docelowa usługa PaaS mogła implementować reguły filtrowania i ograniczać dostęp dla poszczególnych podsieci. Szczegółowe porównanie obu mechanizmów można znaleźć w artykule Porównanie prywatnych punktów końcowych i punktów końcowych usługi.

Reguły aplikacji usługi Azure Firewall mogą służyć do upewnienia się, że nie ma miejsca eksfiltracja danych w celu nieautoryzowanych usług i zaimplementowania zasad dostępu ze zwiększonym poziomem szczegółowości poza poziomem podsieci. Zazwyczaj punkty końcowe usługi sieci wirtualnej muszą być włączone w podsieci klienta, który będzie łączyć się z usługą platformy Azure. Jednak podczas inspekcji ruchu do punktów końcowych usługi za pomocą usługi Azure Firewall należy włączyć odpowiedni punkt końcowy usługi w podsieci usługi Azure Firewall i wyłączyć go w podsieci rzeczywistego klienta (zazwyczaj sieci wirtualnej będącej szprychą). W ten sposób możesz użyć reguł aplikacji w usłudze Azure Firewall, aby kontrolować, do których usług platformy Azure będą miały dostęp obciążenia platformy Azure.

Aby uzyskać szczegółowe informacje o cenach, zobacz Cennik usługi Azure Firewall.

Aby uzyskać informacje o limitach usług, zobacz Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure.

Usługa Azure Firewall nie przenosi ani nie przechowuje danych klientów poza regionem, w którym jest wdrażany.

Nie, usługa Azure Firewall w zabezpieczonych koncentratorach wirtualnych (vWAN) nie jest obecnie obsługiwana w Katarze.

Tak, usługa Azure Firewall obsługuje filtrowanie ruchu przychodzącego i wychodzącego. Filtrowanie przychodzące jest zwykle używane w przypadku protokołów innych niż HTTP, takich jak RDP, SSH i FTP. W przypadku przychodzącego ruchu HTTP i HTTPS rozważ użycie zapory aplikacji internetowej, takiej jak zapora aplikacji internetowej platformy Azure lub odciążanie protokołu TLS i głębokie funkcje inspekcji pakietów usługi Azure Firewall Premium.

Tak, usługa Azure Firewall w warstwie Podstawowa obsługuje wymuszone tunelowanie.

Polecenie ping TCP nie łączy się z docelową nazwą FQDN. Usługa Azure Firewall blokuje połączenia z dowolnym docelowym adresem IP lub nazwą FQDN, chyba że jest jawnie dozwolona przez regułę.

W przypadku polecenia ping TCP, jeśli żadna reguła nie zezwala na ruch, sama zapora odpowiada na żądanie ping TCP klienta. Ta odpowiedź nie osiąga docelowego adresu IP ani nazwy FQDN i nie jest rejestrowana. Jeśli reguła sieci jawnie zezwala na dostęp do docelowego adresu IP lub nazwy FQDN, żądanie ping dociera do serwera docelowego, a jego odpowiedź jest przekazywana z powrotem do klienta. To zdarzenie jest rejestrowane w dzienniku reguł sieciowych.

Nie, usługa Azure Firewall nie obsługuje natywnie komunikacji równorzędnej BGP. Jednak funkcja automatycznego uczenia tras SNAT pośrednio używa protokołu BGP za pośrednictwem usługi Azure Route Server.

Za pomocą programu Azure PowerShell można cofnąć przydział i przydzielić usługę Azure Firewall. Proces różni się w zależności od konfiguracji.

Zapora bez karty sieciowej zarządzania:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$publicip1 = Get-AzPublicIpAddress -Name "Public IP1 Name" -ResourceGroupName "RG Name"
$publicip2 = Get-AzPublicIpAddress -Name "Public IP2 Name" -ResourceGroupName "RG Name"
$azfw.Allocate($vnet, @($publicip1, $publicip2))
Set-AzFirewall -AzureFirewall $azfw

Zapora z kartą sieciową zarządzania:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
$pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
$mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip)
Set-AzFirewall -AzureFirewall $azfw

Zapora w zabezpieczonym koncentratonie wirtualnym:

# Stop the firewall
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
$azfw.Deallocate()
Set-AzFirewall -AzureFirewall $azfw

# Start the firewall
$virtualhub = Get-AzVirtualHub -ResourceGroupName "vHUB RG Name" -Name "vHUB Name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Firewall RG Name"
$azfw.Allocate($virtualhub.Id)
Set-AzFirewall -AzureFirewall $azfw

Uwaga

Podczas zatrzymywania i uruchamiania zapory rozliczenia są zatrzymywane i uruchamiane odpowiednio. Jednak prywatny adres IP może ulec zmianie, co może mieć wpływ na łączność w przypadku skonfigurowania tabel tras.

Zaleca się skonfigurowanie stref dostępności podczas początkowego wdrażania. Można je jednak ponownie skonfigurować po wdrożeniu, jeśli:

• Zapora jest wdrażana w sieci wirtualnej (nieobsługiwana w zabezpieczonych koncentratorach wirtualnych).
• Region obsługuje strefy dostępności.
• Wszystkie dołączone publiczne adresy IP są konfigurowane z tymi samymi strefami.

Aby ponownie skonfigurować strefy dostępności:

1. Cofnij przydział zapory:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $azfw.Deallocate()
   Set-AzFirewall -AzureFirewall $azfw
   

2. Zaktualizuj konfigurację strefy i przydziel zaporę:

   $azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "RG Name"
   $vnet = Get-AzVirtualNetwork -ResourceGroupName "RG Name" -Name "VNet Name"
   $pip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "azfwpublicip"
   $mgmtPip = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
   $azfw.Allocate($vnet, $pip, $mgmtPip)
   $azfw.Zones = 1, 2, 3
   Set-AzFirewall -AzureFirewall $azfw
   

Tak:

• Usługa Azure Firewall i sieć wirtualna muszą znajdować się w tej samej grupie zasobów.
• Publiczny adres IP może znajdować się w innej grupie zasobów.
• Wszystkie zasoby (zapora platformy Azure, sieć wirtualna, publiczny adres IP) muszą znajdować się w tej samej subskrypcji.

Stan aprowizacji Niepowodzenie wskazuje, że aktualizacja konfiguracji nie powiodła się w co najmniej jednym wystąpieniu zaplecza. Usługa Azure Firewall pozostaje operacyjna, ale konfiguracja może być niespójna. Ponów próbę aktualizacji, dopóki stan aprowizacji nie zmieni się na Powodzenie.

Usługa Azure Firewall używa konfiguracji aktywne-aktywne z wieloma węzłami zaplecza. Podczas planowanej konserwacji opróżnianie połączeń zapewnia bezproblemowe aktualizacje. W przypadku nieplanowanych awarii nowy węzeł zastępuje ten, który zakończył się niepowodzeniem, a łączność jest zwykle przywracana w ciągu 10 sekund.

Tak, nazwy zapory są ograniczone do 50 znaków.

Podsieć /26 zapewnia wystarczające adresy IP do skalowania, ponieważ usługa Azure Firewall aprowizuje dodatkowe wystąpienia maszyn wirtualnych.

Nie, podsieć /26 jest wystarczająca dla wszystkich scenariuszy skalowania.

Usługa Azure Firewall jest skalowana automatycznie na podstawie użycia procesora CPU, przepływności i liczby połączeń. Pojemność przepływności waha się od 2,5 do 3 Gb/s początkowo do 30 Gb/s (jednostka SKU w warstwie Standardowa) lub 100 Gb/s (jednostka SKU w warstwie Premium).

Tak. Aby uzyskać szczegółowe informacje, zobacz Limity, limity przydziału i ograniczenia subskrypcji i usług platformy Azure.

Nie, przenoszenie grupy adresów IP do innej grupy zasobów nie jest obecnie obsługiwane.

Standardowe zachowanie zapory sieciowej polega na upewnieniu się, że połączenia TCP są aktywne i aby szybko je zamknąć, jeśli nie ma żadnej aktywności. Limit czasu bezczynności protokołu TCP usługi Azure Firewall wynosi cztery minuty. To ustawienie nie jest konfigurowalne przez użytkownika, ale możesz skontaktować się z pomocą techniczną platformy Azure, aby zwiększyć limit czasu bezczynności dla połączeń przychodzących i wychodzących do 15 minut. Nie można zmienić limitu czasu bezczynności dla ruchu wschodnio-zachodniego.

Jeśli okres braku aktywności jest dłuższy niż wartość limitu czasu, nie ma gwarancji, że sesja TCP lub HTTP jest utrzymywana. Powszechną praktyką jest użycie protokołu TCP keep-alive. Ta praktyka utrzymuje aktywne połączenie przez dłuższy czas. Aby uzyskać więcej informacji, zobacz przykłady platformy .NET.

Tak, ale należy skonfigurować zaporę w trybie wymuszonego tunelowania. Ta konfiguracja tworzy interfejs zarządzania z publicznym adresem IP używanym przez usługę Azure Firewall do wykonywania operacji. Ten publiczny adres IP jest przeznaczony dla ruchu zarządzania. Jest ona używana wyłącznie przez platformę Azure i nie może być używana do żadnego innego celu. Sieć ścieżki danych dzierżawy można skonfigurować bez publicznego adresu IP, a ruch internetowy może zostać wymuszony tunelowany do innej zapory lub całkowicie zablokowany.

Tak. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych usługi Azure Firewall i zasad usługi Azure Firewall przy użyciu usługi Logic Apps.

Aby zapewnić bezpieczny dostęp do usług PaaS, zalecamy punkty końcowe usługi. Możesz włączyć punkty końcowe usług w podsieci usługi Azure Firewall i wyłączyć je w połączonych sieciach wirtualnych będących szprychami. Dzięki temu możesz korzystać z obu funkcji: zabezpieczeń punktu końcowego usługi i centralnego rejestrowania dla całego ruchu.

Tak, możesz użyć usługi Azure Firewall w sieci wirtualnej koncentratora do kierowania i filtrowania ruchu między wieloma sieciami wirtualnymi szprych. Podsieci w każdej sieci wirtualnej będącej szprychami muszą mieć trasę zdefiniowaną przez użytkownika wskazującą usługę Azure Firewall jako bramę domyślną, aby ten scenariusz działał prawidłowo.

Tak. Jednak skonfigurowanie tras zdefiniowanych przez użytkownika w celu przekierowania ruchu między podsieciami w tej samej sieci wirtualnej wymaga większej uwagi. W przypadku używania zakresu adresów sieci wirtualnej jako prefiksu docelowego trasy zdefiniowanej przez użytkownika jest wystarczająca, spowoduje to również kierowanie całego ruchu z jednej maszyny do innej maszyny w tej samej podsieci za pośrednictwem wystąpienia usługi Azure Firewall. Aby tego uniknąć, dołącz trasę dla podsieci w trasie zdefiniowanej przez użytkownika z typem następnego przeskoku sieci wirtualnej. Zarządzanie tymi trasami może być uciążliwe i podatne na błędy. Zalecaną metodą segmentacji sieci wewnętrznej jest użycie sieciowych grup zabezpieczeń, które nie wymagają tras zdefiniowanych przez użytkownika.

Usługa Azure Firewall nie obsługuje protokołu SNAT, gdy docelowy adres IP jest prywatnym zakresem adresów IP dla sieci prywatnych IANA RFC 1918 lub IANA RFC 6598 . Jeśli organizacja używa publicznego zakresu adresów IP dla sieci prywatnych, usługa Azure Firewall SNATs ruchu do jednego z prywatnych adresów IP zapory w podsieci AzureFirewallSubnet. Usługę Azure Firewall można skonfigurować tak, aby nie SNAT był twoim zakresem publicznych adresów IP. Aby uzyskać więcej informacji, zobacz Usługa SNAT dla zakresów prywatnych adresów IP w usłudze Azure Firewall.

Ponadto ruch przetwarzany przez reguły aplikacji jest zawsze sNAT-ed. Jeśli chcesz zobaczyć oryginalny źródłowy adres IP w dziennikach dla ruchu FQDN, możesz użyć reguł sieci z docelową nazwą FQDN.

Wymuszone tunelowanie jest obsługiwane podczas tworzenia nowej zapory. Nie można skonfigurować istniejącej zapory na potrzeby wymuszonego tunelowania. Aby uzyskać więcej informacji, zobacz Wymuszone tunelowanie usługi Azure Firewall.

Usługa Azure Firewall musi mieć bezpośrednie połączenie z Internetem. Jeśli twoja sieć AzureFirewallSubnet poznaje domyślną trasę do sieci lokalnej za pośrednictwem protokołu BGP, należy zastąpić ją trasą zdefiniowaną przez użytkownika 0.0.0.0/0 z wartością NextHopType ustawioną jako Internet, aby zachować bezpośrednią łączność z Internetem .

Jeśli konfiguracja wymaga wymuszonego tunelowania do sieci lokalnej i można określić docelowe prefiksy adresów IP dla miejsc docelowych w Internecie, możesz skonfigurować te zakresy z siecią lokalną jako następny przeskok za pośrednictwem trasy zdefiniowanej przez użytkownika w podsieci AzureFirewallSubnet. Możesz też użyć protokołu BGP do zdefiniowania tych tras.

• ADRES URL — gwiazdki działają po prawej lub lewej stronie. Jeśli znajduje się po lewej stronie, nie może być częścią nazwy FQDN.
• Nazwa FQDN — gwiazdki działają po lewej stronie.
• OGÓLNE — gwiazdki po lewej stronie oznaczają dosłownie wszystkie dopasowania do lewej strony, co oznacza, że wiele domen podrzędnych i/lub potencjalnie niechcianych odmian nazw domen jest dopasowanych - zobacz następujące przykłady.

Przykłady:

Typ	Reguła	Obsługiwane?	Przykłady pozytywne
TargetURL	www.contoso.com	Tak	www.contoso.com www.contoso.com/
TargetURL	*.contoso.com	Tak	any.contoso.com/ sub1.any.contoso.com
TargetURL	*contoso.com	Tak	example.anycontoso.com sub1.example.contoso.com contoso.com Ostrzeżenie: to użycie symboli wieloznacznych umożliwia również potencjalnie niepożądane/ryzykowne odmiany, takie jak th3re4lcontoso.com - należy używać z ostrożnością.
TargetURL	www.contoso.com/test	Tak	www.contoso.com/test www.contoso.com/test/ www.contoso.com/test?with_query=1
TargetURL	www.contoso.com/test/*	Tak	www.contoso.com/test/anything Uwaga: www.contoso.com/testnie jest zgodna (ostatni ukośnik)
TargetURL	www.contoso.*/test/*	Nie.
TargetURL	www.contoso.com/test?example=1	Nie.
TargetURL	www.contoso.*	Nie.
TargetURL	www.*contoso.com	Nie.
TargetURL	www.contoso.com:8080	Nie.
TargetURL	*.contoso.*	Nie.
Nazwa docelowaFQDN	www.contoso.com	Tak	www.contoso.com
Nazwa docelowaFQDN	*.contoso.com	Tak	any.contoso.com Uwaga: jeśli chcesz zezwolić contoso.comna korzystanie z usługi , musisz uwzględnić contoso.com w regule. W przeciwnym razie połączenie jest domyślnie porzucone, ponieważ żądanie nie jest zgodne z żadną regułą.
Nazwa docelowaFQDN	*contoso.com	Tak	example.anycontoso.com contoso.com
Nazwa docelowaFQDN	www.contoso.*	Nie.
Nazwa docelowaFQDN	*.contoso.*	Nie.

L.p. Usługa Azure Firewall domyślnie blokuje dostęp do usługi Active Directory. Aby zezwolić na dostęp, skonfiguruj tag usługi AzureActiveDirectory. Aby uzyskać więcej informacji, zobacz Tagi usługi Azure Firewall.

Tak, możesz użyć programu Azure PowerShell, aby to zrobić:

# Add a Threat Intelligence allowlist to an Existing Azure Firewall.

# Create the allowlist with both FQDN and IPAddresses
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
$fw.ThreatIntelWhitelist = New-AzFirewallThreatIntelWhitelist `
   -FQDN @("fqdn1", "fqdn2", …) -IpAddress @("ip1", "ip2", …)

# Or Update FQDNs and IpAddresses separately
$fw = Get-AzFirewall -Name $firewallname -ResourceGroupName $RG
$fw.ThreatIntelWhitelist.IpAddresses = @($fw.ThreatIntelWhitelist.IpAddresses + $ipaddresses)
$fw.ThreatIntelWhitelist.fqdns = @($fw.ThreatIntelWhitelist.fqdns + $fqdns)


Set-AzFirewall -AzureFirewall $fw

Usługa Azure Firewall obecnie używa portów źródłowych TCP/UDP dla wychodzącego ruchu SNAT bezczynności. Po zamknięciu połączenia TCP/UDP używany port TCP jest natychmiast widoczny jako dostępny dla nadchodzących połączeń.

Aby obejść niektóre architektury, można wdrożyć i skalować za pomocą bramy translatora adresów sieciowych za pomocą usługi Azure Firewall , aby zapewnić szerszą pulę portów SNAT w celu zapewnienia zmienności i dostępności.

Określone zachowania translatora adresów sieciowych zależą od konfiguracji zapory i typu skonfigurowanego translatora adresów sieciowych. Na przykład zapora ma reguły DNAT dla ruchu przychodzącego, a reguły sieci i reguły aplikacji dla ruchu wychodzącego przez zaporę.

Aby uzyskać więcej informacji, zobacz Zachowania translatora adresów sieciowych usługi Azure Firewall.

W przypadku każdej planowanej konserwacji logika opróżniania połączeń bezpiecznie aktualizuje węzły zaplecza. Usługa Azure Firewall czeka 90 sekund na zamknięcie istniejących połączeń. W ciągu pierwszych 45 sekund węzeł zaplecza nie akceptuje nowych połączeń, a w pozostałym czasie odpowiada RST na wszystkie pakiety przychodzące. W razie potrzeby klienci mogą automatycznie ponownie nawiązać łączność z innym węzłem zaplecza.

Zamknięcie wystąpienia maszyny wirtualnej usługi Azure Firewall może wystąpić podczas skalowania zestawu skalowania maszyn wirtualnych w dół (skalowanie w dół) lub podczas uaktualniania oprogramowania floty. W takich przypadkach nowe połączenia przychodzące są równoważone do pozostałych wystąpień zapory i nie są przekazywane do wystąpienia zapory w dół. Po 45 sekundach zapora zacznie odrzucać istniejące połączenia, wysyłając pakiety TCP RST. Po kolejnych 45 sekundach maszyna wirtualna zapory zostanie zamknięta. Aby uzyskać więcej informacji, zobacz Load Balancer TCP Reset and Idle Timeout (Resetowanie protokołu TCP modułu równoważenia obciążenia i limit czasu bezczynności).

Usługa Azure Firewall stopniowo skaluje się, gdy średnia produktywność lub wykorzystanie procesorów wynosi 60%, albo liczba wykorzystywanych połączeń wynosi 80%. Na przykład rozpoczyna zwiększanie skali w poziomie, gdy osiągnie 60% maksymalnej produktywności. Maksymalna liczba przepływności różni się w zależności od jednostki SKU usługi Azure Firewall i funkcji z obsługą. Aby uzyskać więcej informacji, zobacz Wydajność usługi Azure Firewall.

Skalowanie w poziomie trwa od pięciu do siedmiu minut. Podczas testowania wydajności upewnij się, że testujesz przez co najmniej 10 do 15 minut, a następnie rozpocznij nowe połączenia, aby skorzystać z nowo utworzonych węzłów usługi Azure Firewall.

Jeśli połączenie ma limit czasu bezczynności (cztery minuty braku aktywności), usługa Azure Firewall bezpiecznie przerywa połączenie, wysyłając pakiet TCP RST.