Wychodzący dostęp do Internetu: kontrolowanie ruchu wychodzącego z Azure

W tym artykule wyjaśniono, jak kontrolować ruch wychodzący do Internetu z sieci wirtualnych platformy Azure. Porównuje rozwiązania NAT Gateway, Azure Firewall oraz połączone wzorce komunikacji wychodzącej, aby pomóc w wyborze przewidywalnej i bezpiecznej metody dla obciążeń roboczych.

Co opisano w tym artykule

Kontrola ruchu wychodzącego określa sposób, w jaki obciążenia Azure docierają do publicznego Internetu. Dobrze zaprojektowana strategia ruchu wychodzącego zapewnia przewidywalne publiczne adresy IP, zapobiega wyczerpaniu portów SNAT i opcjonalnie filtruje połączenia wychodzące według miejsca docelowego.

Note

W tym artykule opisano pojęcia specyficzne dla ruchu wychodzącego. Aby uzyskać pełny zakres ochrony zapory, zobacz Azure Firewall i inspekcja ruchu.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli ma zastosowanie co najmniej jeden z następujących warunków:

  • Obciążenia wymagają kontrolowanego dostępu wychodzącego do Internetu na potrzeby aktualizacji, interfejsów API lub usług zewnętrznych.
  • Potrzebujesz przewidywalnych publicznych adresów IP dla połączeń wychodzących.
  • Należy zapobiec wyczerpaniu portów SNAT lub skalować łączność wychodzącą dla obciążeń o wysokim poziomie połączenia.
  • Musisz wybrać jedną z opcji: NAT Gateway, Azure Firewall lub połączony model kontroli i inspekcji ruchu wychodzącego.

Tip

Podążasz ścieżką scenariusza? Wybierz swój scenariusz w górnej części strony, aby uzyskać dostosowane wskazówki. Poniższe podstawowe wskazówki dotyczą wszystkich czytelników.

Nacisk na migrację typu lift-and-shift: Zmigrowane maszyny wirtualne wymagają kontrolowanego dostępu wychodzącego do Internetu. Scentralizuj cały ruch wychodzący przez zaporę centrum, aby wymusić spójne zasady bezpieczeństwa we wszystkich zmigrowanych obciążeniach.

Przeczytaj ten artykuł, jeśli:

  • Wdróż obciążenia, które muszą uzyskać dostęp do Internetu w celu uzyskania aktualizacji, wywołań interfejsu API lub usług innych firm.
  • Chcesz scentralizować kontrolę ruchu wychodzącego przy użyciu Azure Firewall w centralnej sieci wirtualnej.
  • Należy wyłączyć domyślny dostęp wychodzący w przypadku migrowanych obciążeń i zastąpić go jawną metodą ruchu wychodzącego.
  • Wymagaj stałego, przewidywalnego publicznego adresu IP dla połączeń wychodzących.

Modernizacja: Wszystkie sieci wirtualne typu spoke kierują ruch wychodzący przez zaporę w sieci centralnej przy użyciu tras zdefiniowanych przez użytkownika (UDR). Ten scentralizowany model ruchu wychodzącego stanowi integralny element architektury zabezpieczeń, ponieważ uniemożliwia zespołom aplikacyjnym omijanie zabezpieczeń zarządzanych przez dział IT.

Przeczytaj ten artykuł, jeśli:

  • Należy wymusić, aby wszystkie obciążenia w sieciach szprychowych (AKS, App Service, maszyny wirtualne) kierowały ruch wychodzący przez zaporę huba.
  • Chcesz używać routingu opartego na trasach zdefiniowanych przez użytkownika (UDR) z każdej sieci spoke do centralnej zapory Azure Firewall, aby zapewnić spójne zasady ruchu wychodzącego.
  • Wymagaj, aby zapora koncentratora działała jako SNAT dla wszystkich połączeń wychodzących.
  • Należy zapobiec wyczerpaniu portów SNAT w przypadku obciążeń o wysokiej liczbie połączeń.

Fokus między chmurami: Uwzględnij scentralizowany ruch wychodzący, jeśli projekt docelowy wymaga kontrolowanych zasad ruchu wychodzącego z Internetu. W przeciwnym razie ruch między chmurami przechodzi przez ścieżkę tranzytową (Azure Firewall w bezpiecznym koncentratorze wirtualnym) i nie wymaga oddzielnej konfiguracji dla ruchu wychodzącego.

Przeczytaj ten artykuł, jeśli:

  • Potrzebujesz scentralizowanych zasad ruchu wychodzącego z Internetu w strefie docelowej Azure.
  • Chcesz udostępnić tę samą zaporę Azure Firewall zarówno do inspekcji ruchu tranzytowego między chmurami, jak i do obsługi wychodzącego ruchu internetowego.
  • Zastąp domyślny dostęp wychodzący, zanim zostanie wycofany.

Usługi i funkcje platformy Azure

W poniższej tabeli opisano usługi i funkcje dostępne dla wychodzącego dostępu do Internetu w sieciach wirtualnych Azure.

Usługa lub funkcja Co zapewnia Kiedy należy go używać
Domyślny dostęp wychodzący (wycofany) Azure automatycznie przypisuje tymczasowy publiczny adres IP dla połączeń wychodzących. Przypisany adres IP nie jest przewidywalny i może ulec zmianie bez powiadomienia. Nie używaj ich w przypadku nowych wdrożeń. Zastąp bramą NAT lub usługą Azure Firewall. Zobacz Zagadnienia dotyczące zabezpieczeń.
Azure NAT Gateway Zarządzana usługa SNAT z stałymi, przewidywalnymi publicznymi adresami IP. Zapewnia 64 512 portów SNAT na publiczny adres IP, maksymalnie 16 publicznych adresów IP (łącznie ponad 1 milion portów). Brak filtrowania zawartości. Obciążenia obsługujące wyłącznie ruch wychodzący, które wymagają stałego wychodzącego adresu IP, aplikacje z dużą liczbą połączeń oraz scenariusze, w których wyczerpanie portów SNAT stanowi ryzyko.
Azure Firewall Pełna inspekcja warstwy 3–7 dla ruchu wychodzącego. Filtrowanie nazw FQDN, filtrowanie adresów URL, kategorie stron internetowych oraz system IDPS (SKU Premium). Scentralizowane zarządzanie zasadami. Gdy musisz kontrolować, z jakimi miejscami docelowymi łączą się Twoje zasoby, a nie tylko to, czy mają dostęp wychodzący.
Brama translatora adresów sieciowych i Azure Firewall Brama NAT obsługuje skalowanie mechanizmu SNAT w podsieci zapory. Azure Firewall obsługuje inspekcję i filtrowanie. Nie występuje podwójny NAT. Środowiska produkcyjne, które wymagają zarówno skalowalnej komunikacji wychodzącej, jak i filtrowania uwzględniającego zawartość. Zalecana architektura dla obciążeń przedsiębiorstwa.
Maszyna wirtualna z publicznym adresem IP (wychodzącym) Maszyna wirtualna używa własnego publicznego adresu IP dla ruchu wychodzącego. Brak scentralizowanej kontroli ani filtrowania. Unikaj produkcji. Brak scentralizowanego zarządzania, nieprzewidywalne przy dużej skali i brak korzyści ze współdzielonych zasobów SNAT.

Jak wybrać

Diagram przedstawiający trzy ścieżki ruchu wychodzącego z sieci wirtualnej obciążenia za pośrednictwem NAT Gateway, Azure Firewall lub obu tych rozwiązań.

Jak kontrolować dostęp wychodzący

Skorzystaj z poniższej tabeli, aby wybrać metodę ruchu wychodzącego odpowiednią do swoich wymagań.

Wymaganie Zalecane podejście Dlaczego
Naprawiono tylko wychodzący adres IP, bez konieczności filtrowania NAT Gateway Zapewnia przewidywalne publiczne adresy IP z automatyczną alokacją portów SNAT. Brak kosztów inspekcji ani filtrowania. Najprostsza opcja gotowa do produkcji.
Filtrowanie nazw FQDN, filtrowanie adresów URL lub inspekcja ruchu Azure Firewall Filtruje połączenia wychodzące według docelowej nazwy FQDN lub adresu URL. Wersja Premium obejmuje funkcje IDPS oraz inspekcję TLS w celu zaawansowanego wykrywania zagrożeń.
Naprawiono wychodzący adres IP i filtrowanie zawartości NAT Gateway + Azure Firewall Brama translatora adresów sieciowych w podsieci AzureFirewallSubnet zapewnia skalowalny adres SNAT. Zapora sprawdza ruch przed wyjściem. Najlepsze z obu możliwości.
Nie używaj w przypadku nowych wdrożeń Domyślny dostęp wychodzący lub publiczny adres IP maszyny wirtualnej Domyślny dostęp wychodzący został wycofany. Publiczne adresy IP maszyn wirtualnych nie zapewniają scentralizowanej kontroli. Oba są nieodpowiednie dla obciążeń produkcyjnych.

NAT Gateway kontra Azure Firewall dla ruchu wychodzącego

Zapoznaj się z poniższym porównaniem, aby zrozumieć różnice między usługami NAT Gateway i Azure Firewall używanymi niezależnie.

Capability NAT Gateway Azure Firewall
Porty SNAT 64 512 na publiczny adres IP (do 16 adresów IP, łącznie ponad 1 milion) 2 496 na publiczny adres IP na wystąpienie zaplecza (maks. 250 adresów IP)
Filtrowanie ruchu Brak: przepuszcza cały ruch wychodzący Reguły nazw FQDN, filtrowanie adresów URL, kategorie sieci, reguły sieci
IDPS i inspekcja protokołu TLS Niedostępne Tylko dla SKU Premium
Throughput Przepustowość dla podsieci (brak opublikowanego ograniczenia dla SNAT) Do 100 Gb/s (Premium), 30 Gb/s (Standardowa), 250 Mb/s (podstawowa)
Model kosztów Zasób za godzinę + przetworzone dane za GB Zasób na godzinę + przetworzone dane na GB (wyższy koszt bazowy)
Złożoność routingu Jest bezpośrednio skojarzone z podsiecią, nie wymaga trasy zdefiniowanej przez użytkownika (UDR) Wymaga trasy zdefiniowanej przez użytkownika (0.0.0.0/0 → prywatnego adresu IP zapory) w podsieciach obciążeń
Przypadek użycia Połączenia wychodzące o dużej ilości wymagają stałych adresów IP Środowiska regulowane wymagające filtrowania i rejestrowania ruchu wychodzącego

Priorytet routingu dla ruchu wychodzącego

Azure ocenia metody ruchu wychodzącego w następującej kolejności priorytetu. Metody o wyższym priorytcie zastępują te o niższym priorytcie w tej samej podsieci:

  1. UDR do urządzenia wirtualnego lub bramy sieci wirtualnej: zastępuje wszystkie inne metody ruchu wychodzącego, w tym NAT Gateway.
  2. Brama NAT: ma pierwszeństwo przed publicznymi adresami IP na poziomie instancji i regułami ruchu wychodzącego modułu równoważenia obciążenia.
  3. Publiczny adres IP przypisany do instancji na maszynie wirtualnej.
  4. Reguły wychodzące modułu równoważenia obciążenia.
  5. Domyślna trasa systemowa do Internetu (Microsoft wycofała tę opcję dla nowych wdrożeń).

Ważna

Trasa zdefiniowana przez użytkownika (UDR) z adresem docelowym 0.0.0.0/0 wskazującą na urządzenie wirtualne (takie jak Azure Firewall) ma pierwszeństwo przed usługą NAT Gateway. Takie zachowanie wynika z projektu architektury łączącej bramę NAT i zaporę. Trasa zdefiniowana przez użytkownika (UDR) w podsieciach obciążeń wymusza kierowanie ruchu przez zaporę, podczas gdy brama NAT w podsieci AzureFirewallSubnet zapewnia końcowe adresy IP ruchu wychodzącego.

Architektura łączona: NAT Gateway + Azure Firewall

Zalecany wzorzec produkcji dla ruchu wychodzącego przedsiębiorstwa łączy obie usługi:

  1. Podsieci obciążenia mają trasę zdefiniowaną przez użytkownika (UDR), która kieruje ruch 0.0.0.0/0 do prywatnego adresu IP zapory Azure Firewall.
  2. Azure Firewall sprawdza i filtruje ruch wychodzący przy użyciu reguł sieci, reguł aplikacji lub obu tych reguł.
  3. Brama NAT jest skojarzona z podsiecią AzureFirewallSubnet i zapewnia skalowalną translację adresów źródłowych (SNAT) dla połączeń wychodzących zapory.
  4. Nie występuje podwójny NAT. Zapora wysyła ruch do bramy NAT Gateway za pomocą swojego prywatnego adresu IP, a NAT Gateway jednokrotnie stosuje translację SNAT przy użyciu swoich publicznych adresów IP.

Ta architektura zapewnia scentralizowaną inspekcję przy użyciu skalowalnej architektury SNAT. Podsieć AzureFirewallSubnet nie wymaga dodatkowych tras zdefiniowanych przez użytkownika (UDR), ponieważ brama NAT automatycznie kieruje wychodzący ruch internetowy po jej skojarzeniu.

Note

Standardowa brama translatora adresów sieciowych jest zasobem strefowym i nie obsługuje wdrożeń strefowo nadmiarowych. Jeśli wdrażasz Azure Firewall z nadmiarowością stref, użyj usługi NAT Gateway V2 (SKU StandardV2), aby zapewnić nadmiarowość stref dla SNAT. Brama NAT w warstwie Standard staje się pojedynczym punktem awarii podczas awarii strefowej w połączeniu z nadmiarową strefowo zaporą. Aby uzyskać więcej informacji, zobacz jednostki SKU usługi NAT Gateway.

Przewodnik po przepływie danych

Poniższa sekwencja pokazuje, jak pojedyncze żądanie wychodzące przepływa przez połączoną architekturę:

  1. Maszyna wirtualna w podsieci obciążenia uruchamia połączenie TCP z zewnętrznym interfejsem API (na przykład api.contoso.com:443).
  2. Trasa zdefiniowana przez użytkownika (UDR) podsieci obejmuje prefiks 0.0.0.0/0 i kieruje pakiet do prywatnego adresu IP usługi Azure Firewall.
  3. Azure Firewall ocenia połączenie na podstawie reguł aplikacji i reguł sieci. Jeśli reguła aplikacji z nazwą FQDN zezwala na dopasowanie wpisu, zapora zezwala na połączenie.
  4. Zapora wysyła dozwolony pakiet z własnego interfejsu w podsieci AzureFirewallSubnet.
  5. Brama NAT Gateway skojarzona z podsiecią AzureFirewallSubnet wykonuje SNAT. Przekształca prywatny adres IP zapory na jeden z jego publicznych adresów IP i przydziela port SNAT z puli.
  6. Odpowiedź z zewnętrznego interfejsu API wraca na publiczny adres IP bramy NAT. Brama NAT wykonuje translację odwrotną i odsyła pakiet z powrotem do zapory.
  7. Zapora wysyła odpowiedź do maszyny wirtualnej inicjującej połączenie, korzystając z istniejącego stanu połączenia.

W tym kompleksowym przepływie zapora sprawdza ruch dokładnie raz, a brama NAT stosuje SNAT dokładnie raz, bez podwójnego NAT-u.

Monitorowanie i diagnostyka

Monitoruj infrastrukturę ruchu wychodzącego, aby wykrywać problemy z przepustowością, zanim wpłyną one na obciążenia robocze:

  • Metryki bramy NAT: Monitoruj łączną liczbę połączeń SNAT, liczbę połączeń SNAT (według stanu) i dostępność ścieżki przetwarzania danych w usłudze Azure Monitor. Ustaw alerty, gdy użycie portów SNAT przekracza 80% przydzielonej pojemności.
  • Dzienniki Azure Firewall: Włącz ustawienia diagnostyczne, aby przesyłać dzienniki do usługi Log Analytics. Użyj kategorii dzienników AzureFirewallApplicationRule i AzureFirewallNetworkRule , aby przeprowadzić inspekcję dozwolonych i odrzuconych połączeń wychodzących.
  • Monitor połączenia: Użyj narzędzia Network Watcher Monitor połączenia, aby przetestować łączność typu end-to-end z maszyn wirtualnych obsługujących obciążenia z zewnętrznymi punktami końcowymi. Monitor połączenia wykrywa wzrost opóźnienia i błędy łączności, które mogą wskazywać na wyczerpanie sieci SNAT lub błędną konfigurację zapory.
  • Metryki zapory: Monitoruj przepustowość, liczbę trafień reguł i wykorzystanie portów SNAT, aby dobrać odpowiedni rozmiar jednostki SKU zapory i zidentyfikować najbardziej obciążone reguły.

Uwagi dotyczące projektowania

Użyj Azure Firewall dla całej komunikacji wychodzącej z migrowanych obciążeń. Takie podejście zapewnia scentralizowane filtrowanie FQDN, rejestrowanie i wykrywanie zagrożeń od pierwszego dnia:

  • Wyłącz domyślny dostęp wychodzący: W przypadku nowych wdrożeń podsieci są domyślnie prywatne (bez automatycznego ruchu wychodzącego). W przypadku istniejących sieci wirtualnych jawnie zastąp domyślny ruch wychodzący ruchem wychodzącym przez Azure Firewall, aby nie polegać na nieprzewidywalnych, niekontrolowanych publicznych adresach IP.
  • UDR w podsieciach obciążeń: Utwórz trasę zdefiniowaną przez użytkownika (0.0.0.0/0 → prywatny adres IP usługi Azure Firewall) w każdej podsieci obciążeń w sieci spoke. Ta konfiguracja kieruje cały ruch wychodzący do Internetu przez zaporę centrum.
  • Brama NAT w AzureFirewallSubnet: Skojarz bramę NAT z podsiecią zapory, aby zapewnić skalowalny mechanizm SNAT. Ta kombinacja zapewnia przewidywalne adresy IP ruchu wychodzącego i pozwala uniknąć wyczerpania portów SNAT.
  • Zacznij od ogólnych reguł zezwalających, a następnie stopniowo je zaostrzaj: Podczas migracji zezwól na ruch wychodzący do miejsc docelowych, których wymagają aplikacje (Windows Update, repozytoria pakietów, interfejsy API innych firm). Po ustabilizowaniu migracji przeprowadź inspekcję dzienników zapory i ogranicz znane nazwy FQDN.

Routing oparty na trasach definiowanych przez użytkownika (UDR) z każdej sieci typu spoke do zapory w sieci hub stanowi podstawę modelu bezpieczeństwa ruchu wychodzącego. Zespoły aplikacji nie mogą pominąć kontrolek wychodzących zarządzanych przez dział IT:

  • UDR w każdej szprychowej sieci VNet: Każda podsieć z obciążeniem w sieci szprychowej ma tabelę tras z trasą 0.0.0.0/0 → prywatny adres IP usługi Azure Firewall w hubie. Ta konfiguracja gwarantuje, że węzły usługi AKS, podsieci zintegrowane z siecią wirtualną usługi App Service i maszyny wirtualne będą kierować ruch wychodzący przez zaporę.
  • Zapora w centrum jako SNAT: Azure Firewall wykonuje translację adresów źródłowych dla wszystkich połączeń wychodzących. Wszystkie obciążenia w sieciach szprychowych współdzielą wychodzące adresy IP zapory, co upraszcza dodawanie ich do listy dozwolonych zapory partnera.
  • Brama NAT do skalowania SNAT: Skojarz bramę NAT z podsiecią AzureFirewallSubnet. Dzięki 16 publicznym adresom IP (ponad 1 milionom portów SNAT) obsługujesz obciążenia o wysokiej liczbie połączeń, takie jak klastry usługi AKS z wieloma zasobnikami wykonującymi zewnętrzne wywołania interfejsu API.
  • Reguły aplikacji do kontrolowania ruchu przy użyciu nazw FQDN: Użyj reguł aplikacji w usłudze Azure Firewall, aby ograniczyć ruch wychodzący na podstawie nazw FQDN. Zespoły aplikacyjne składają wnioski o dodanie wpisów FQDN do listy dozwolonych w ramach procesu zarządzania zmianami. Odmowa domyślnie uniemożliwia eksfiltrację danych.

Azure Firewall w bezpiecznym koncentratorze wirtualnym sprawdza zarówno ruch tranzytowy między chmurami, jak i ruch wychodzący z Internetu. Udostępnianie pojedynczej zapory dla obu ścieżek upraszcza architekturę:

  • Bezpieczna zapora koncentratora wirtualnego dla ruchu wychodzącego: W przypadku wdrażania Virtual WAN za pomocą bezpiecznego koncentratora Azure Firewall w centrum obsługuje ruch wychodzący z Internetu dla wszystkich połączonych sieci wirtualnych. Skonfiguruj zasady routingu ruchu internetowego bezpiecznego koncentratora tak, aby kierować ruch 0.0.0.0/0 przez zaporę.
  • Ruch wychodzący i tranzyt między chmurami korzystają z tej samej zapory: Ruch kierowany do Internetu oraz ruch kierowany do AWS/Google Cloud przez tunele IPSec przechodzą przez usługę Azure Firewall w celu inspekcji. To rozwiązanie oznacza, że utrzymujesz jeden zestaw reguł dla wszystkich ścieżek ruchu wychodzącego.
  • Centralizuj tylko w razie potrzeby: Jeśli architektura wielochmurowa nie wymaga scentralizowanego wyjścia do internetu (na przykład obciążenia robocze komunikują się tylko między chmurami), możesz pominąć tę konfigurację i polegać wyłącznie na inspekcji przez zaporę tranzytową między chmurami.

Prerequisites

Przed wdrożeniem mechanizmów kontroli ruchu wychodzącego potwierdź następujące kwestie:

  • Wdrażana jest sieć wirtualna z podsieciami o rozmiarze dostosowanym do obciążeń. Aby uzyskać wskazówki dotyczące projektowania podsieci, zobacz Sieci wirtualne i podsieci .
  • Rozumiesz trasy zdefiniowane przez użytkownika i sposób ich zastępowania domyślnego routingu Azure. Zobacz Sieci wirtualne i podsieci, aby uzyskać szczegółowe informacje na temat konfiguracji UDR.
  • Podsieć zapory ma prawidłowy rozmiar, jeśli używasz Azure Firewall. Podsieć AzureFirewallSubnet wymaga co najmniej /26 (64 adresów).
  • Znasz wymagania dotyczące skalowania SNAT. Oblicz maksymalną liczbę jednoczesnych połączeń wychodzących, aby określić, ile publicznych adresów IP usługi NAT Gateway potrzebujesz (64 512 portów na adres IP).

Zagadnienia dotyczące zabezpieczeń

Zamień domyślny dostęp wychodzący

Domyślny dostęp wychodzący został wycofany. W przypadku wersji API wydanych po 31 marca 2026 r. nowe sieci wirtualne domyślnie korzystają z prywatnych podsieci (bez automatycznych połączeń wychodzących). Nie wpływa to na istniejące sieci wirtualne, ale należy przejść na jawną metodę ruchu wychodzącego. Aby uzyskać szczegółowe informacje, zobacz domyślną dokumentację dostępu wychodzącego.

Note

Istniejące sieci wirtualne i maszyny wirtualne, które obecnie używają domyślnego dostępu wychodzącego, nadal działają. Jednak przypisany publiczny adres IP jest nieprzewidywalny, nie zapewnia filtrowania i powoduje alerty usługi Azure Advisor. Zaplanuj migrację do usługi NAT Gateway lub Azure Firewall niezależnie od harmonogramu wycofania.

Routing UDR na potrzeby scentralizowanej inspekcji zapory

Jeśli używasz Azure Firewall do kontroli ruchu wychodzącego, utwórz UDR w każdej podsieci obciążeń z następującymi ustawieniami:

  • Miejsce docelowe: 0.0.0.0/0
  • Typ następnego przeskoku: Urządzenie wirtualne
  • Adres następnego przeskoku: prywatny adres IP usługi Azure Firewall (na przykład 10.0.1.4)

Ta konfiguracja zapewnia, że cały ruch kierowany do internetu z podsieci obciążeń roboczych przechodzi przez zaporę w celu inspekcji. Bez tego wpisu UDR ruch omija zaporę i korzysta z dowolnej metody ruchu wychodzącego skonfigurowanej bezpośrednio dla podsieci.

Zapobieganie wyczerpaniu portów SNAT

Wyczerpanie portów SNAT występuje, gdy obciążenie otwiera więcej współbieżnych połączeń wychodzących, niż obsługuje dostępny spis portów. Objawy obejmują sporadyczne przekroczenia limitu czasu połączenia, pakiety TCP RST w połączeniach wychodzących i nieudane żądania HTTP z błędami gniazda. W dziennikach aplikacji są wyświetlane błędy "adres już używany" lub "nie można przypisać żądanego adresu". Wyczerpanie zwykle manifestuje się pod obciążeniem, gdy wiele krótkotrwałych połączeń otwiera się szybko do tego samego docelowego adresu IP i portu.

Aby zapobiec wyczerpaniu:

  • Użyj bramy NAT w przypadku obciążeń z dużą liczbą połączeń wychodzących. Każdy publiczny adres IP zapewnia 64 512 portów SNAT z dynamiczną alokacją we wszystkich zasobach w podsieci.
  • Dodaj publiczne adresy IP do bramy NAT, jeśli monitoring wskazuje, że wykorzystanie portów przekracza 80%. Dodaj do 16 publicznych adresów IP.
  • Użyj buforowania połączeń w kodzie aplikacji, aby ponownie użyć istniejących połączeń zamiast otwierać nowe dla każdego żądania.
  • Zdywersyfikuj docelowe punkty końcowe, jeśli to możliwe. Alokacja portów SNAT odbywa się dla każdej pary docelowy adres IP/docelowy port, więc rozłożenie ruchu na wiele docelowych adresów IP zmniejsza obciążenie puli portów.
  • Zmniejsz limity czasu bezczynności, aby szybciej odzyskiwać porty. Domyślny limit czasu bezczynności bramy NAT wynosi 4 minuty. Obniż tę wartość dla obciążeń, które tworzą wiele krótkotrwałych połączeń.

Sieciowe grupy zabezpieczeń uzupełniają kontrolę ruchu wychodzącego

Sieciowe grupy zabezpieczeń (NSG) i metody ruchu wychodzącego służą różnym celom i współpracują ze sobą. Sieciowe grupy zabezpieczeń filtrują ruch według adresu IP i portu na poziomie podsieci lub karty sieciowej. Brama NAT i Azure Firewall kontrolują, w jaki sposób ruch dociera do Internetu. Użyj obu warstw w ramach obrony wielowarstwowej. Zobacz Grupy zabezpieczeń sieci i grupy zabezpieczeń aplikacji, aby uzyskać wskazówki dotyczące projektowania grup zabezpieczeń sieci.

Zagadnienia dotyczące wymuszonego tunelowania

Wymuszone tunelowanie ruchu wychodzącego przez środowisko lokalne może wprowadzać opóźnienia i zwiększać zależność od zapory sieciowej w środowisku lokalnym. Rozważ użycie usługi Azure Firewall do inspekcji ruchu wychodzącego, jeśli istotne są niskie opóźnienia. Jeśli wymogi zgodności wymagają inspekcji w środowisku lokalnym, przetestuj opóźnienie end-to-end z podsieci obciążeń roboczych i upewnij się, że lokalna trasa może obsłużyć wymagania dotyczące przepustowości, nie stając się wąskim gardłem.

Zapobieganie eksfiltracji danych

Filtrowanie nazw FQDN w usłudze Azure Firewall zapobiega eksfiltracji danych poprzez ograniczenie połączeń wychodzących wyłącznie do zatwierdzonych nazw domen. Zdefiniuj reguły aplikacji, które zezwalają na ruch do określonych nazw FQDN (na przykład *.blob.core.windows.net lub api.partner.com) i odrzucają wszystkie inne połączenia wychodzące. Takie podejście zapewnia, że naruszone obciążenia nie mogą wysyłać danych do punktów końcowych kontrolowanych przez osobę atakującą.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Skonfiguruj zaporę huba: skonfiguruj usługę Azure Firewall na potrzeby scentralizowanej inspekcji ruchu na osi wschód-zachód oraz kontroli ruchu wychodzącego.

Kolejny etap procesu modernizacji:

Skonfiguruj zaporę w węźle centralnym: skonfiguruj usługę Azure Firewall jako SNAT/DNAT w węźle centralnym, aby filtrować cały ruch, zanim dotrze on do warstwy aplikacji.

Kolejny krok w Twojej wielochmurowej podróży:

Skonfiguruj monitorowanie między chmurami: Środowiska obejmujące wiele chmur są trudniejsze do diagnozowania. Skonfiguruj monitorowanie przed uruchomieniem produkcyjnym.

  • Ostatnia aktualizacja o