Sieci wirtualne i podsieci platformy Azure

Sieci wirtualne platformy Azure (VNets) i podsieci są podstawowymi elementami składowymi każdej sieci Azure. W tym artykule wyjaśniono, jak sieci wirtualne zapewniają izolację, jak podsieci organizują zasoby oraz jak dobrać rozmiar i strukturę sieci na potrzeby obciążeń produkcyjnych.

Co opisano w tym artykule

W tym artykule omówiono granice izolacji sieci VNet, rozmiary podsieci i adresy zarezerwowane, dedykowane podsieci platformowe dla usług, takich jak Azure Firewall i Application Gateway, komunikację równorzędną sieci wirtualnych oraz typowe wzorce topologii sieci.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli:

• Wdrażasz pierwsze obciążenie w Azure i musisz zrozumieć, jak działa sieć przed utworzeniem zasobów.
• Planujesz środowisko z wieloma obciążeniami i musisz zdecydować, ile sieci wirtualnych i podsieci ma zostać utworzonych.
• Czy migrujesz lokalne obciążenia robocze do platformy Azure i chcesz zrozumieć, czym sieci platformy Azure różnią się od sieci fizycznej.
• Należy prawidłowo ustawiać rozmiar podsieci dla usług platformy Azure, takich jak Azure Firewall, VPN Gateway lub Azure Kubernetes Service (AKS).
• Chcesz zrozumieć, kiedy należy oddzielić obciążenia do różnych sieci wirtualnych, a nie przechowywać ich w tej samej sieci wirtualnej.

Nacisk na lift-and-shift: Odwzoruj segmentację podsieci w środowisku lokalnym na platformie Azure. Przypisz istniejące sieci VLAN i strefy bezpieczeństwa do podsieci, utrzymuj przestrzenie adresowe zgodne z zakresami, z których korzysta już Twój zespół, i zaplanuj podsieci z odpowiednim zapasem, aby podczas migracji nie trzeba było zmieniać adresacji.

Modernizuj fokus: Projektowanie podsieci wokół usług platformy i automatyzacji. Odpowiednio dobierz rozmiar podsieci dla usługi AKS, prywatnych punktów końcowych i dedykowanych usług platformowych oraz zaplanuj użycie rozwiązania Azure Virtual Network Manager, aby stosować spójną konfigurację w wielu sieciach wirtualnych.

Podejście wielochmurowe: Przed utworzeniem dowolnej sieci VNet zaplanuj niepokrywające się przestrzenie adresowe w środowiskach Azure, AWS i Google Cloud. Zarezerwuj zakresy CIDR, które nie nakładają się na istniejące sieci VPC, aby można było łączyć chmury za pomocą peeringu lub połączenia VPN bez NAT.

Usługi i funkcje platformy Azure

Następujące usługi i funkcje składają się na podstawy sieci wirtualnej w Azure:

Usługa lub funkcja	Co zapewnia	Kiedy należy go używać
Azure Virtual Network (sieć wirtualna)	Izolowana, prywatna sieć w Azure. Wszystkie Azure sieci zaczynają się tutaj. Zasoby w tej samej sieci wirtualnej mogą domyślnie komunikować się; zasoby w różnych sieciach wirtualnych nie mogą komunikować się, chyba że jawnie je połączysz.	Zawsze: każde obciążenie wymagające łączności sieciowej wymaga sieci wirtualnej.
Podsieć	Partycja przestrzeni adresowej sieci wirtualnej. Podsieci stanowią zakres skojarzeń sieciowej grupy zabezpieczeń (NSG) i tabeli tras.	Zawsze: organizuj składniki obciążenia w podsieci według funkcji lub granicy zabezpieczeń.
Komunikacja równorzędna sieci VNet	Prywatna łączność o niskich opóźnieniach między dwiema sieciami VNet w tym samym regionie lub w różnych regionach. Ruch sieciowy pozostaje w obrębie sieci szkieletowej firmy Microsoft. Peering nie jest przechodni; każdy peering jest bezpośrednim połączeniem.	Gdy zasoby w oddzielnych sieciach wirtualnych muszą komunikować się. Informacje o komunikacji równorzędnej między regionami można znaleźć w sekcji Łączność między regionami.
Komunikacja równorzędna podsieci (wersja zapoznawcza)	Komunikacja równorzędna między określonymi podsieciami, a nie całą siecią wirtualną. Zapewnia precyzyjną kontrolę nad tym, które podsieci uczestniczą w połączeniach peeringowych.	Gdy potrzebujesz precyzyjnej kontroli peeringu między określonymi podsieciami w różnych sieciach VNet. Zobacz sekcję ograniczenia .
Tabela tras /Trasy zdefiniowane przez użytkownika (UDR)	Zastąpij domyślne trasy systemowe w Azure, aby kontrolować, gdzie jest wysyłany ruch. Zastosowane na poziomie podsieci.	Gdy trzeba wymusić kierowanie ruchu przez zaporę sieciową lub sieciowe urządzenie wirtualne (NVA). Wymagane do kontroli ruchu wychodzącego w architekturze hub-and-spoke. Zobacz projekt Azure Firewall i topologię piasta-szprycha.
Azure Virtual Network Manager (AVNM)	Centralnie twórz, zarządzaj i stosuj konfiguracje sieciowe w sieciach wirtualnych w różnych subskrypcjach.	Podczas zarządzania wieloma sieciami VNet w ramach wielu subskrypcji. Zobacz Scentralizowane zarządzanie siecią.

Jak wybrać

Co to jest sieć wirtualna?

Sieć wirtualna (VNet) to zdefiniowana programowo izolowana sieć w Azure. Pomyśl o niej jako o twojej sieci prywatnej w Azure. W przeciwieństwie do sieci fizycznej, która używa kabli, przełączników i routerów, sieć wirtualna jest całkowicie zdefiniowana programowo. Utworzysz ją, przypiszesz do niej przestrzeń adresową i wdrożysz w niej zasoby.

Kluczowe cechy:

• Ograniczona do regionu: sieć wirtualna znajduje się w jednym regionie platformy Azure. Wszystkie zasoby w tej sieci wirtualnej muszą znajdować się w tym samym regionie. Sieć VNet obejmuje strefy dostępności w obrębie tego regionu.
• Izolacja domyślnie: zasoby w jednej sieci wirtualnej nie mogą komunikować się z zasobami w innej sieci wirtualnej, chyba że jawnie utworzysz połączenie (komunikacja równorzędna lub sieć VPN).
• Domyślna łączność wewnętrzna: zasoby w tej samej sieci wirtualnej mogą domyślnie komunikować się ze sobą za pośrednictwem tras systemowych, które Azure zapewnia.

Co to jest podsieć?

Podsieć to zakres adresów IP w sieci wirtualnej. Podsieci umożliwiają:

• Segmentuj sieć według składnika obciążenia (na przykład warstwy internetowej, warstwy aplikacji, warstwy danych).
• Zastosuj reguły zabezpieczeń: NSG są przypisywane do podsieci, aby filtrować ruch.
• Sterowanie trasowaniem: tabele tras są przypisywane na poziomie podsieci, aby kierować ruchem.

Azure rezerwuje pięć adresów IP w każdej podsieci: pierwsze cztery adresy i ostatni adres. Na przykład w podsieci /24 (256 adresów) tylko 251 można używać. Uwzględnij ten zapas w obliczeniach doboru rozmiaru.

Przykład: aplikacja trójwarstwowa

Typowa aplikacja internetowa trójwarstwowa używa trzech podsieci do oddzielenia problemów i stosowania odrębnych reguł zabezpieczeń:

Podsieć	Zakres CIDR	Purpose	Przykładowe zasoby
web-subnet	10.0.1.0/24	Serwery sieci Web frontonu, które przyjmują przychodzący ruch HTTP/HTTPS z internetu lub z usługi Application Gateway	Usługa Azure App Service Environment Virtual Machine Scale Sets z systemem NGINX
app-subnet	10.0.2.0/24	Logika aplikacji warstwy środkowej. Akceptuje ruch tylko z podsieci internetowej.	Azure Functions (zintegrowane z siecią wirtualną), maszyny wirtualne uruchamiające logikę biznesową
data-subnet	10.0.3.0/24	Magazyny danych. Akceptuje ruch tylko z podsieci aplikacji. Brak bezpośredniego dostępu do Internetu.	Azure SQL Managed Instance, prywatne punkty końcowe dla Azure SQL Database lub Cosmos DB

Ten układ umożliwia przypisanie grupy zabezpieczeń sieciowych (NSG) do każdej podsieci, aby ograniczyć ruch wyłącznie do tego, czego wymaga dana warstwa. Podsieć internetowa zezwala na przychodzący protokół HTTPS (port 443). Podsieć aplikacji zezwala na ruch przychodzący tylko z zakresu adresów IP podsieci internetowej. Podsieć danych zezwala na ruch przychodzący tylko z zakresu adresów IP podsieci aplikacji.

W przypadku wzorca modernizacji opartego na AKS można użyć podsieci aks-nodes, takiej jak 10.0.4.0/24, dla pul węzłów klastra podczas wdrażania Azure CNI Overlay. W tym modelu tylko węzły zużywają adresy IP sieci VNet z podsieci. Pody używają oddzielnego zakresu CIDR sieci nakładkowej, co pozwala utrzymać mniejszą podsieć węzła niż w płaskim modelu sieci AKS.

Często używane wzorce

Następujące układy podsieci obejmują najbardziej typowe scenariusze wdrażania Azure:

Wzór	Subnets	Kiedy stosować
Prosta aplikacja internetowa	web + data	Aplikacje dwuwarstwowe z frontonem i bazą danych. Minimalna złożoność.
Trzywarstwowe przedsiębiorstwo	web + app + data + management	Tradycyjne obciążenia przedsiębiorstwa z różnymi warstwami i podsiecią przesiadkową lub podsiecią bastionu na potrzeby administracji.
AKS z usługami wspólnymi	aks-nodes + aks-ingress + appgw + shared	Obciążenia Kubernetes z dedykowaną podsiecią kontrolera ruchu wejściowego i bramą aplikacyjną Application Gateway dla WAF.
Ruch wychodzący piasty i szprych	AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management	Centralna sieć wirtualna w topologii typu piasta i szprychy. Usługi współdzielone, przez które sieci wirtualne typu spoke kierują ruch. Zobacz topologię typu piasta-szprychy.
Obciążenie danych	compute + data + private-endpoints + management	Obciążenia platformy analiz i danych, w których prywatne punkty końcowe dla magazynu i baz danych wymagają własnej podsieci w celu zapewnienia przejrzystości planowania adresów IP.

Ile sieci wirtualnych i podsieci?

Zasada przewodnia jest prosta: użyj jednej sieci wirtualnej na aplikację i jednej podsieci na składnik (warstwa). To ustawienie domyślne zapewnia izolację każdego obciążenia, sprawia, że ruch między warstwami jest łatwy do kontrolowania za pomocą sieciowych grup zabezpieczeń i pozostawia miejsce na rozwój. Następnie dostosuj to w zależności od usług współdzielonych, wymagań dotyczących izolacji i skali.

Użyj tej tabeli decyzyjnej, aby określić strategię sieci wirtualnej i podsieci:

Twoja sytuacja	Zalecane podejście
Pojedyncze obciążenie, pojedynczy zespół, brak wymaganych usług udostępnionych	Jedna sieć wirtualna z podsieciami na składnik aplikacji (sieć Web, logika aplikacji, dane). Zobacz Topologia pojedynczego obciążenia.
Wiele niezależnych obciążeń współużytkujących bramę lub zaporę	Centralna sieć VNet dla usług współdzielonych oraz jedna satelicka sieć VNet dla każdego obciążenia. Zobacz Topologia piasty i szprych.
Ścisła izolacja między obciążeniami roboczymi (zasięg awarii, wymogi zgodności)	Jedna sieć wirtualna na każde obciążenie robocze, bez połączeń równorzędnych między nimi.
Bardzo duże środowisko z wieloma subskrypcjami i regionami	Azure Virtual WAN z automatycznym zarządzaniem koncentratorem. Zobacz topologię Virtual WAN.

Informacje referencyjne dotyczące rozmiaru dedykowanej podsieci

Wiele usług platformy Azure wymaga własnej dedykowanej podsieci o określonej nazwie i minimalnym rozmiarze. Na poniższym diagramie przedstawiono wymagania dotyczące nazewnictwa i minimalne rozmiary dla dedykowanych podsieci platformy:

Użyj tej tabeli podczas planowania przestrzeni adresowej:

usługa Azure	Minimalny rozmiar podsieci	Nazwa wymaganej podsieci	Notatki
Azure Firewall	/26 (59 adresów IP do użycia)	AzureFirewallSubnet	Wymagane dla wszystkich jednostek SKU zapory. Zobacz projekt Azure Firewall.
brama VPN	/27 (27 adresów IP do użycia)	GatewaySubnet	Microsoft zaleca /27 lub większy do skalowania przestrzeni głowy.
Azure Bastion	/26 (59 adresów IP do użycia)	AzureBastionSubnet	Minimalna liczba /26 dla wszystkich wdrożeń utworzonych po listopadzie 2021 r.
Application Gateway (wersja 2)	/24 zalecane (251 użytecznych adresów IP)	Brak wymaganej nazwy	Zdecydowanie zaleca się /24, aby umożliwić automatyczne skalowanie. Wartość minimalna jest obliczana według wzoru (wystąpienia + 5 zarezerwowanych + 1 prywatny adres IP frontonu).
App Service Environment	/24 (produkcja), /23 (maksymalna skala)	Brak wymaganej nazwy	Skalowanie zużywa adresy IP z podsieci. Użyj /23, jeśli planujesz skalować do maksymalnej liczby 200 instancji.
Azure Route Server	/26 (59 adresów IP do użycia)	RouteServerSubnet	Wymagane do wymiany tras BGP z wirtualnymi urządzeniami sieciowymi (NVA).
Azure DNS Private Resolver	minimum /28 dla każdej podsieci punktu końcowego	Dedykowane podsieci przychodzące i wychodzące	Wymaga oddzielnych podsieci dla przychodzących i wychodzących punktów końcowych. Nie można udostępniać innym zasobom.
AKS (Azure Kubernetes Service)	Oparte na formule (zależne od CNI)	Brak wymaganej nazwy	Zapoznaj się ze wskazówkami dotyczącymi określania rozmiaru usługi AKS.

Note

Prywatne punkty końcowe używają adresów IP z istniejących podsieci. Nie wymagają dedykowanej podsieci. Uwzględnij to zużycie adresów IP przy doborze rozmiaru podsieci. Aby uzyskać szczegółowe informacje na temat planowania adresów IP, zobacz Planowanie adresów IP.

Określanie rozmiaru podsieci AKS

Rozmiar podsieci AKS zależy od wybranej wtyczki CNI (Container Networking Interface). Nie ma jednego minimalnego rozmiaru:

• Nakładka Azure CNI: Podsieć musi obejmować tylko węzły, ponieważ zasobniki używają oddzielnego prywatnego bloku CIDR (bezklasowego routingu międzydomenowego). Znacznie mniejsza podsieć jest akceptowalna w porównaniu z siecią płaską.
• Azure CNI (sieć płaska): podsieć musi pomieścić zarówno węzły, jak i pody. Formuła: (nodes + surge) × (max_pods + 1). Prefiks /21 lub szerszy to typowy wybór dla klastrów z co najmniej 50 węzłami.
• Kubenet: Tylko węzły zużywają adresy IP podsieci VNet. Zasobniki uzyskują adresy IP wewnątrz klastra.

Aby uzyskać wzory określania rozmiaru dla każdej opcji CNI, zobacz Planowanie adresacji IP dla klastra AKS.

Ograniczenia komunikacji równorzędnej podsieci

Komunikacja równorzędna podsieci łączy określone podsieci między sieciami wirtualnymi zamiast całej przestrzeni adresowej. Takie podejście zapewnia precyzyjną kontrolę nad tym, które podsieci uczestniczą w połączeniach peeringowych.

Ważna

Komunikacja równorzędna między podsieciami jest obecnie w wersji zapoznawczej i ma następujące ograniczenia:

• Wymaga dodania subskrypcji do zatwierdzonej listy (nie rejestracji samoobsługowej)
• Interfejs wiersza polecenia, szablon arm, program Terraform lub tylko program PowerShell (brak obsługi portalu)
• Jednostki SKU V5 oparte na procesorach Intel (lub jednostki SKU oparte na procesorach AMD Genoa/Cobalt 100) są wymagane w środowisku produkcyjnym, aby uniknąć znanego błędu występującego w jednostkach SKU starszej generacji: zobacz Konfigurowanie komunikacji równorzędnej podsieci, aby sprawdzić bieżące wymagania sprzętowe
• Maksymalnie 200 podsieci po każdej stronie na połączenie peeringowe
• Maksymalnie 1000 podsieci łącznie we wszystkich połączeniach komunikacji równorzędnej na każdą sieć wirtualną (VNet)
• Podsieci muszą należeć do unikatowych, nienakładających się przestrzeni adresowych

Informacje o bieżących ograniczeniach i rejestracji można znaleźć w artykule Konfigurowanie komunikacji równorzędnej między podsieciami.

Note

Azure Virtual Network Manager (AVNM) nie może odróżnić połączenia równorzędnego podsieci od połączenia równorzędnego sieci VNet. Jeśli używasz usługi AVNM do zarządzania konfiguracjami połączeń równorzędnych, pamiętaj, że połączenia równorzędne na poziomie podsieci są widoczne w usłudze AVNM jako standardowe połączenia równorzędne sieci wirtualnej (VNet).

Uwagi dotyczące projektowania

Koncentracja projektu lift-and-shift na sieci VNet i podsieci

• Odtwórz segmentację środowiska lokalnego: przypisz każdą sieć VLAN lub strefę bezpieczeństwa do podsieci, aby zachować istniejące granice reguł zapory i odpowiedzialność operacyjną przy minimalnych zmianach projektowych.
• Umożliwia ustawianie rozmiaru podsieci z miejscami głównymi. Ponowna adresacja po migracji powoduje zakłócenia, więc przydzielaj zakresy CIDR większe, niż wynika to z bieżącej liczby hostów, aby uwzględnić przyszły wzrost oraz pięć adresów zarezerwowanych przez platformę Azure w każdej podsieci.
• Jeśli to możliwe, utrzymuj przestrzenie adresowe platformy Azure zgodne z lokalnymi zakresami adresów, aby uprościć routing i uniknąć nakładania się zakresów podczas łączenia za pośrednictwem bramy sieci VPN lub usługi ExpressRoute.
• Domyślnie używaj jednej sieci wirtualnej na każdą zmigrowaną aplikację, z podsiecią dla każdej warstwy. Ten projekt odzwierciedla typowe trójwarstwowe architektury lokalne i sprawia, że migracja jest przewidywalna.

Modernizuj fokus projektowania sieci wirtualnej i podsieci

• Najpierw zaprojektuj podsieci z myślą o usługach platformy: dedykowane podsieci dla Azure Firewall, Application Gateway i Azure Bastion oraz podsieci o odpowiednio dobranym rozmiarze dla AKS w zależności od wybranego rozwiązania CNI.
• Użyj nakładki Azure CNI w usłudze AKS, aby utrzymać małe podsieci węzłów, ponieważ pody korzystają z oddzielnego zakresu CIDR nakładki, a nie z przestrzeni adresowej sieci VNet.
• Zarezerwuj dedykowaną podsieć dla prywatnych punktów końcowych, aby użycie adresu IP było przewidywalne, ponieważ wdrażasz więcej Azure usług PaaS.
• Wdrażaj Azure Virtual Network Manager wcześnie, aby stale stosować grupy sieciowe, łączność i konfiguracje zabezpieczeń w miarę wzrostu liczby sieci wirtualnych w subskrypcjach.

Projektowanie sieci wirtualnych i podsieci w środowisku wielochmurowym

• Przed utworzeniem dowolnej sieci VNet przygotuj globalny plan adresacji. Zarezerwuj nienakładające się bloki CIDR na potrzeby platformy Azure, które nie pokrywają się z istniejącymi sieciami VPC w AWS lub Google Cloud. Ta rezerwacja jest obowiązkowa dla routowanego VPN lub połączenia wzajemnego.
• Przyporządkuj podstawowe elementy sieciowe każdej chmury do odpowiadających im usług w platformie Azure: sieć VPC w AWS lub sieć VPC w Google Cloud odpowiada usłudze Azure VNet, a grupy zabezpieczeń odpowiadają sieciowym grupom zabezpieczeń (NSG).
• Zarezerwuj przestrzeń adresową podsieci dla komponentów łączności między chmurami, takich jak GatewaySubnet dla usługi VPN Gateway lub koncentrator używany przez usługę Azure Virtual WAN, aby infrastruktura tranzytowa miała przestrzeń do rozbudowy.
• Standaryzacja nazewnictwa i tagowania podsieci w chmurach, dzięki czemu zespoły operacyjne mogą korelować równoważne warstwy podczas rozwiązywania problemów z ruchem wielochmurowym.

Prerequisites

Przed zaprojektowaniem sieci wirtualnej i układu podsieci upewnij się, że masz następujące elementy:

• Subskrypcja platformy Azure: Aktywna subskrypcja platformy Azure z uprawnieniami do tworzenia zasobów sieciowych (rola Network Contributor lub wyższa).
• Grupa zasobów: grupa zasobów w regionie docelowym zawierająca zasoby sieci wirtualnej.
• Decyzja o regionie: wybierz podstawowy region Azure w oparciu o bliskość użytkowników, wymagania dotyczące zgodności i dostępność usługi.
• Plan przestrzeni adresowej: Wybierz zakres adresów IP (blok CIDR), który nie pokrywa się z Twoimi sieciami lokalnymi ani z innymi sieciami wirtualnymi (VNetami), z którymi zamierzasz ustanowić komunikację równorzędną. Zobacz Planowanie adresów IP , aby uzyskać wskazówki.

Zagadnienia dotyczące zabezpieczeń

Sieci wirtualne i podsieci to pierwsza warstwa segmentacji sieci. Zastosuj następujące rozwiązania w zakresie zabezpieczeń:

• Sieciowe grupy zabezpieczeń:Kojarzenie sieciowych grup zabezpieczeń z każdą podsiecią w celu filtrowania ruchu przychodzącego i wychodzącego. Zdefiniuj reguły zezwalania specyficzne dla roli każdej podsieci i odmów domyślnie wszystkie inne elementy. Aby uzyskać szczegółowe wskazówki, zobacz Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji.
• Wymuszone tunelowanie przy użyciu tras UDR: Jeśli wymagania dotyczące zgodności nakazują, aby cały ruch kierowany do Internetu przechodził przez lokalne urządzenie inspekcyjne lub zaporę w chmurze, użyj tabel tras z trasami zdefiniowanymi przez użytkownika, aby zastąpić domyślne trasowanie ruchu internetowego. Zobacz Łączność wychodząca i wyjściowa.
• Izolacja podsieci: umieść zasoby o różnych poziomach zaufania w oddzielnych podsieciach. Na przykład zachowaj bazy danych w podsieci, która zezwala tylko na ruch przychodzący z podsieci warstwy aplikacji. Ta separacja ogranicza ruch boczny, jeśli osoba atakująca naruszy jeden składnik.
• Dedykowane podsieci dla usług platformy: Wiele usług platformy Azure (Azure Firewall, Application Gateway, Bastion) jest wdrażanych w dedykowanych podsieciach. Ta izolacja zapewnia, że trasowanie ruchu usług platformy i reguły zabezpieczeń nie zakłócają działania podsieci obciążeń roboczych.

Interakcja NSG z podsiecią

Po skojarzeniu sieciowej grupy zabezpieczeń z podsiecią reguły sieciowej grupy zabezpieczeń mają zastosowanie do wszystkich zasobów w tej podsieci. Zapoznaj się z tymi zachowaniami interakcji:

• Ocena skumulowana: jeśli karta sieciowa maszyny wirtualnej ma również sieciową grupę zabezpieczeń, Azure ocenia zarówno sieciową grupę zabezpieczeń na poziomie podsieci, jak i sieciową grupę zabezpieczeń na poziomie karty sieciowej. W przypadku ruchu przychodzącego Azure najpierw ocenia sieciową grupę zabezpieczeń podsieci, a następnie sieciową grupę zabezpieczeń karty sieciowej. W przypadku ruchu wychodzącego Azure najpierw ocenia NSG karty sieciowej, a następnie NSG podsieci.
• Odmowa domyślna: Azure zawiera reguły domyślne zezwalające na ruch wewnątrz sieci wirtualnej i wychodzący dostęp do Internetu. Po dodaniu niestandardowych reguł odmowy sprawdź, czy prawidłowy ruch (taki jak sondy kondycji modułu Azure Load Balancer z adresu IP 168.63.129.16) nie został przypadkowo zablokowany.
• Tagi usług i grupy ASG: Użyj tagów usług (takich jak AzureLoadBalancer, Internet, VirtualNetwork) i grup zabezpieczeń aplikacji (ASG) w regułach sieciowej grupy zabezpieczeń zamiast surowych adresów IP. Takie podejście upraszcza zarządzanie regułami i dostosowuje się automatycznie w miarę zmiany Azure zakresów adresów IP.
• Dzienniki przepływu zapewniające widoczność: Włącz dzienniki przepływu NSG dla każdej grupy NSG na poziomie podsieci, aby rejestrować dozwolony i odrzucony ruch. Dzienniki przepływu ułatwiają sprawdzenie, czy reguły zabezpieczeń działają zgodnie z oczekiwaniami i dostarczają dowody na inspekcje zgodności. Instrukcje dotyczące konfiguracji można znaleźć w sekcji Dzienniki przepływu NSG.

Powiązane artykuły

Te artykuły w przewodniku projektowania sieci Azure obejmują tematy pokrewne:

• Planowanie adresów IP: Projektowanie przestrzeni adresowej, unikanie nakładania się i planowanie rozwoju.
• Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji: zdefiniuj reguły filtrowania ruchu na poziomie podsieci i karty sieciowej.
• Topologia pojedynczego obciążenia: Projektowanie prostej sieci dla jednego obciążenia bez usług udostępnionych.
• Topologia piasty i szprych: łączenie wielu sieci wirtualnych obciążeń za pośrednictwem centrum usług udostępnionych.
• topologia Virtual WAN: zarządzanie łącznością na dużą skalę przy użyciu zautomatyzowanego routingu koncentratora.
• Łączność między regionami: Połącz sieci wirtualne w regionach platformy Azure przy użyciu globalnego peeringu lub usługi Virtual WAN.
• Scentralizowane zarządzanie siecią: zarządzanie konfiguracjami sieci wirtualnej w subskrypcjach przy użyciu Azure Virtual Network Manager.

Learn more

Aby uzyskać więcej informacji na temat Azure sieci wirtualnej, zobacz następujące zasoby:

• Co to jest Azure Virtual Network?
• Azure Virtual Network — często zadawane pytania
• Planowanie podsieci sieci wirtualnej
• Peering sieci wirtualnych
• Konfigurowanie komunikacji równorzędnej między podsieciami (wersja zapoznawcza)
• Planowanie adresowania IP dla klastrów usługi AKS

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:

Zaplanuj przestrzeń adresów IP: przydziel pulę CIDR /16, która pozwala uniknąć nakładania się na lokalne zakresy adresów.

Kolejny etap procesu modernizacji:

Zaplanuj przestrzeń adresów IP: Przydziel dwuregionowe pule adresów IP z nienakładającymi się zakresami dla połączenia równorzędnego w trybie active-active.

Kolejny krok w Twojej wielochmurowej podróży:

Zaplanuj przestrzeń adresową IP: zaprojektuj niepokrywającą się adresację na platformach Azure, Amazon Web Services (AWS) i Google Cloud.