Zapora platformy Azure — często zadawane pytania

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 dowiedzieć się więcej o funkcjach usługi Azure Firewall, zobacz Funkcje usługi Azure Firewall.

Usługę Azure Firewall można wdrożyć w dowolnej sieci wirtualnej, ale klienci zazwyczaj wdrażają ją w centralnej sieci wirtualnej i łączą z nią równorzędnie inne sieci wirtualne w modelu piasty i szprych. Następnie możesz ustawić trasę domyślną z równorzędnych sieci wirtualnych tak, aby wskazywała tę centralną sieć wirtualną zapory. Globalna komunikacja równorzędna sieci wirtualnych jest obsługiwana, ale nie jest zalecana z powodu potencjalnych problemów z wydajnością i opóźnieniami w różnych regionach. Aby uzyskać najlepszą wydajność, wdróż jedną zaporę na region.

Zaletą tego modelu jest możliwość scentralizowanej kontroli nad wieloma sieciami wirtualnymi szprychy w różnych subskrypcjach. Istnieją również oszczędności kosztów, ponieważ nie trzeba oddzielnie wdrażać zapory w każdej sieci wirtualnej. Oszczędności kosztów należy mierzyć w porównaniu z kosztami powiązanej komunikacji równorzędnej na podstawie wzorców ruchu klienta.

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

Usługa Azure Firewall obsługuje reguły i kolekcje reguł. Kolekcja reguł to zestaw reguł, które współdzielą tę samą kolejność i priorytet. Kolekcje reguł są wykonywane zgodnie z ich priorytetem. Kolekcje reguł DNAT to kolekcje reguł sieci o wyższym priorytcie, które mają wyższy priorytet niż kolekcje reguł aplikacji, a 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 zawierające adresy źródłowe, protokoły, porty docelowe i adresy docelowe.
• 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 obsługuje filtrowanie ruchu przychodzącego i wychodzącego. Ochrona ruchu przychodzącego jest zwykle używana w przypadku protokołów innych niż HTTP, takich jak protokoły RDP, SSH i FTP. W przypadku ochrony przychodzących protokołów HTTP i HTTPS należy użyć zapory aplikacji internetowej, takiej jak zapora aplikacji internetowej platformy Azure lub odciążanie protokołu TLS i głębokie możliwości inspekcji pakietów usługi Azure Firewall Premium.

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

Usługa Azure Firewall jest zintegrowana z usługą Azure Monitor na potrzeby wyświetlania i analizowania dzienników zapory. Dzienniki można wysyłać do usługi Log Analytics, Azure Storage lub Event Hubs. Można je analizować w usłudze Log Analytics lub za pomocą różnych narzędzi, takich jak program Excel i usługa 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 oferowana jako usługa, z wbudowaną wysoką dostępnością i możliwością nieograniczonego skalowania w chmurze. Jest ona wstępnie zintegrowana z dostawcami zabezpieczeń jako usługi (SECaaS) innych firm w celu zapewnienia zaawansowanych zabezpieczeń dla sieci wirtualnej i połączeń internetowych gałęzi. Aby dowiedzieć się więcej na temat zabezpieczeń sieci platformy Azure, zobacz Zabezpieczenia sieci platformy Azure.

Zapora aplikacji internetowej (WAF) to funkcja usługi Application Gateway, która zapewnia scentralizowaną ochronę ruchu przychodzącego 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 funkcjonalność sieciowej grupy zabezpieczeń. Razem zapewniają lepsze "zabezpieczenia sieci w głębi systemu obrony". Sieciowe grupy zabezpieczeń zapewniają filtrowanie ruchu warstwy sieci rozproszonej, aby ograniczyć ruch do zasobów w ramach sieci wirtualnych w każdej subskrypcji. Usługa Azure Firewall to w pełni stanowa, scentralizowana zapora sieciowa jako usługa, która zapewnia ochronę na poziomie sieci i aplikacji w różnych 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 w celu zapewnienia braku przerw w działaniu usługi.

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.

Zobacz Cennik usługi Azure Firewall.

Za pomocą programu Azure PowerShell można cofnąć przydział i przydzielić metody. W przypadku zapory skonfigurowanej do wymuszonego tunelowania procedura jest nieco inna.

Na przykład w przypadku zapory skonfigurowanej z kartą sieciową zarządzania NIE jest włączona:

# Stop an existing 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

W przypadku zapory skonfigurowanej z włączoną kartą sieciową zarządzania zatrzymanie jest takie samo. Jednak rozpoczęcie wymaga ponownego skojarzenia publicznego adresu IP zarządzania z zaporą:

# Stop an existing 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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azfw | Set-AzFirewall

W przypadku zapory w zabezpieczonej architekturze koncentratora wirtualnego zatrzymanie jest takie samo, ale rozpoczęcie musi używać identyfikatora koncentratora wirtualnego:

# Stop and existing firewall

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

# Start the firewall

$virtualhub = get-azvirtualhub -ResourceGroupName "RG name of vHUB" -name "vHUB name"
$azfw = Get-AzFirewall -Name "FW Name" -ResourceGroupName "Azfw RG Name"
$azfw.Allocate($virtualhub.Id)
$azfw | Set-AzFirewall

Po przydzieleniu i cofnięciu przydziału rozliczenia zapory są zatrzymywane i uruchamiane odpowiednio.

Zaleca się skonfigurowanie stref dostępności podczas początkowego wdrażania zapory. Jednak w niektórych przypadkach można zmienić strefy dostępności po wdrożeniu. Wymagania wstępne są następujące:

• Zapora jest wdrażana w sieci wirtualnej. Nie jest obsługiwana w przypadku zapór wdrożonych w zabezpieczonym koncentratonie wirtualnym.
• Region zapory obsługuje strefy dostępności.
• Wszystkie dołączone publiczne adresy IP są wdrażane ze strefami dostępności. Na stronie właściwości każdego publicznego adresu IP upewnij się, że pole stref dostępności istnieje i jest skonfigurowane z tymi samymi strefami skonfigurowanymi dla zapory.

Ponowne konfigurowanie stref dostępności można wykonać tylko po ponownym uruchomieniu zapory. Po przydzieleniu zapory i bezpośrednio przed uruchomieniem zapory z Set-AzFirewallprogramem użyj następującego programu Azure PowerShell, aby zmodyfikować właściwość Zones zapory:

$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"
$mgmtPip2 = Get-AzPublicIpAddress -ResourceGroupName "RG Name" -Name "mgmtpip"
$azfw.Allocate($vnet, $pip, $mgmtPip2)
$azFw.Zones=1,2,3
$azfw | Set-AzFirewall

Aby uzyskać informacje o limitach usługi Azure Firewall, zobacz Limity, przydziały i ograniczenia subskrypcji i usług platformy Azure.

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. Podczas 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.

Tak.

• Zapora i sieć wirtualna muszą znajdować się w tej samej grupie zasobów.
• Publiczny adres IP może znajdować się w dowolnej grupie zasobów.
• Zapora, sieć wirtualna i publiczny adres IP muszą znajdować się w tej samej subskrypcji.

• 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:

Po każdym zastosowaniu zmiany konfiguracji usługa Azure Firewall próbuje zaktualizować wszystkie swoje bazowe wystąpienia zaplecza. W rzadkich przypadkach jedna z tych wystąpień zaplecza może nie zostać zaktualizowana przy użyciu nowej konfiguracji, a proces aktualizacji zostanie zatrzymany ze stanem nieudanej aprowizacji. Usługa Azure Firewall nadal działa, ale zastosowana konfiguracja może być w niespójnym stanie, w którym niektóre wystąpienia mają poprzednią konfigurację, w której inne mają zaktualizowany zestaw reguł. Jeśli tak się stanie, spróbuj zaktualizować konfigurację jeszcze raz, dopóki operacja nie powiedzie się, a zapora będzie w stanie aprowizacji Powodzenie .

Usługa Azure Firewall składa się z kilku węzłów zaplecza w konfiguracji aktywne-aktywne. W przypadku każdej planowanej konserwacji mamy logikę opróżniania połączeń, aby bezpiecznie zaktualizować węzły. Aktualizacje są planowane w godzinach nonbusiness dla każdego z regionów platformy Azure w celu dalszego ograniczenia ryzyka zakłóceń. W przypadku nieplanowanych problemów tworzymy wystąpienie nowego węzła w celu zastąpienia węzła, który zakończył się niepowodzeniem. Łączność z nowym węzłem jest zwykle ponownie publikowana w ciągu 10 sekund od momentu awarii.

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.

Tak. Istnieje limit 50 znaków dla nazwy zapory.

Usługa Azure Firewall musi aprowizować więcej wystąpień maszyn wirtualnych podczas skalowania. Przestrzeń adresowa /26 gwarantuje, że zapora ma wystarczającą liczbę adresów IP dostępnych do obsługi skalowania.

L.p. Usługa Azure Firewall nie wymaga podsieci większej niż /26.

Początkowa pojemność przepływności usługi Azure Firewall wynosi 2,5 – 3 Gb/s i jest skalowana w poziomie do 30 Gb/s dla jednostki SKU w warstwie Standardowa i 100 Gb/s dla jednostki SKU w warstwie Premium. Skalowanie w poziomie odbywa się automatycznie na podstawie użycia procesora CPU, przepływności i liczby połączeń.

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. Wartości maksymalnej produktywności różnią się w zależności od jednostki SKU zapory i włączonych funkcji. Aby uzyskać więcej informacji, zobacz Wydajność usługi Azure Firewall.

Skalowanie w poziomie trwa od pięciu do siedmiu minut.

Podczas testowania wydajnościowego upewnij się, że testujesz przez co najmniej 10 do 15 minut i rozpocznij nowe połączenia, aby korzystać z nowo utworzonych węzłów zapory.

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.

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).

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

Polecenie ping TCP nie łączy się z docelową nazwą FQDN. Usługa Azure Firewall nie zezwala na połączenie z żadnym docelowym adresem IP/nazwą FQDN, chyba że istnieje jawna reguła, która ją zezwala.

Polecenie ping TCP jest unikatowym przypadkiem użycia, w którym jeśli nie ma dozwolonej reguły, zapora odpowiada na żądanie ping TCP klienta, mimo że polecenie ping TCP nie osiąga docelowego adresu IP/nazwy FQDN. W takim przypadku zdarzenie nie jest rejestrowane. Jeśli istnieje reguła sieci, która zezwala na dostęp do docelowego adresu IP/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.

Tak. Aby uzyskać więcej informacji, zobacz Limity, przydziały i ograniczenia usług i subskrypcji 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.

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

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.

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

Usługa Azure Firewall używa usługi Azure Virtual Machines poniżej, które mają stały limit liczby połączeń. Całkowita liczba aktywnych połączeń na maszynę wirtualną wynosi 250 tys.

Łączny limit dla zapory to limit połączenia maszyny wirtualnej (250 tys.) x liczba maszyn wirtualnych w puli zaplecza zapory. Usługa Azure Firewall rozpoczyna się od dwóch maszyn wirtualnych i skaluje w poziomie na podstawie użycia procesora CPU i przepływności.

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.