Planowanie adresów IP dla sieci wirtualnych Azure

W tym artykule opisano planowanie prywatnych i publicznych adresów IP dla wdrożeń Azure. Dowiesz się, jak przydzielić przestrzeń adresową, unikać nakładających się zakresów, wybierać odpowiedni typ publicznego adresu IP i oceniać obsługę dwóch stosów IPv6.

Co opisano w tym artykule

W tym artykule opisano strategie alokacji adresów prywatnych, typy publicznych adresów IP i jednostki SKU, planowanie CIDR w celu uniknięcia nakładających się zakresów, zagadnień dotyczących podwójnego stosu IPv6 i Menedżera adresów IP (IPAM) w środowiskach na dużą skalę.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli:

  • Wdrażają sieć wirtualną w Azure i muszą zdecydować, które zakresy adresów IP mają być używane.
  • Łączą sieci platformy Azure ze środowiskami lokalnymi i muszą zapobiegać konfliktom adresów IP.
  • Należy wybrać między standardowymi publicznymi adresami IP, prefiksami publicznego adresu IP lub wprowadzeniem własnych zakresów adresów IP (BYOIP).
  • Chcesz zrozumieć, kiedy konfiguracja dual-stack dla protokołu IPv6 jest odpowiednia w przypadku Twoich obciążeń roboczych.
  • Zarządza dużym lub rosnącym środowiskiem i wymaga strategii śledzenia alokacji adresów IP na dużą skalę.

Fokus lift-and-shift: Wybierz zakresy prywatne, które nie nakładają się na sieć lokalną, więc routing sieci VPN lub usługi ExpressRoute działa bez tłumaczenia. Zarezerwuj jeden duży blok strefy docelowej z miejscem na obciążenia, które będziesz migrować w ciągu najbliższych kilku lat.

Modernizuj fokus: Zaplanuj nienakładające się przestrzenie adresowe w regionach podstawowych i kopii zapasowych, aby obciążenia aktywne-aktywne mogły później łączyć się równorzędnie i rezerwować odpowiednio rozmiary podsieci dla App Service Environment i usługi AKS.

Podejście wielochmurowe: Utwórz globalny plan adresacji, który nie koliduje z istniejącymi zakresami CIDR w AWS VPC ani w Google Cloud, co jest konieczne przed połączeniem chmur za pomocą sieci VPN lub Interconnect.

Usługi i funkcje platformy Azure

Następujące usługi i funkcje obsługują planowanie adresów IP w Azure:

Usługa lub funkcja Co zapewnia Kiedy należy go używać
Prywatne przestrzenie adresowe RFC 1918 Trzy zastrzeżone zakresy do użytku prywatnego: 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16. Sieci wirtualne platformy Azure używają tych zakresów do komunikacji wewnętrznej. Zawsze: każda sieć wirtualna wymaga co najmniej jednego zakresu prywatnych adresów z tych przestrzeni.
Wspólna przestrzeń adresowa RFC 6598 100.64.0.0/10: traktowane jako prywatna przestrzeń adresowa w Azure. Pierwotnie zaprojektowany dla środowisk NAT klasy przewoźnika (CGNAT). Gdy organizacja używa już zakresów RFC 6598 lokalnie lub gdy miejsce w RFC 1918 jest wyczerpane.
Standardowy publiczny adres IP Statyczny, strefowo nadmiarowy publiczny adres IP przypisany do jednego zasobu. Bezpieczne domyślnie dzięki zablokowanemu ruchowi przychodzącemu. Gdy zasób wymaga unikatowego publicznego punktu końcowego, takiego jak moduł równoważenia obciążenia, brama sieci VPN lub publiczna maszyna wirtualna.
Prefiks publicznego adresu IP Zastrzeżony blok publicznych adresów IP z określonego regionu Azure. Jeśli potrzebujesz przewidywalnych zakresów adresów IP dla bramy NAT, zestawów skalowania maszyn wirtualnych lub chcesz dodać zewnętrzny adres do listy dozwolonych.
BYOIP/ Niestandardowy prefiks adresu IP Wprowadź własne publiczne zakresy adresów IP do platformy Azure. Obejmuje proces trójetapowy: weryfikację własności, przydzielenie prefiksu, a następnie oddanie go do użytku. Gdy musisz zachować dotychczasową reputację adresu IP, utrzymać zewnętrzne wpisy na listach dozwolonych lub migrować obciążenia robocze bez zmiany publicznych adresów IP.
Azure Virtual Network Manager IPAM Wbudowana funkcja zarządzania adresami IP w Azure Virtual Network Manager. Ogólnie dostępne w większości regionów. Zapewnia scentralizowaną widoczność i śledzenie alokacji w ramach subskrypcji. Gdy zarządzasz wieloma sieciami wirtualnymi w wielu subskrypcjach i potrzebujesz automatycznego śledzenia wykorzystania adresów. Zobacz Scentralizowane zarządzanie siecią.

Jak wybrać

Skorzystaj z poniższych tabel decyzyjnych, aby kierować decyzjami o planowaniu adresów IP.

Najlepsze rozwiązania dotyczące planowania adresów IP

Practice Dlaczego Example
Przydziel duży nadrzędny blok CIDR (/16) i podziel go na mniejsze podsieci Zapobiega wyczerpaniu puli adresów wraz ze wzrostem obciążeń. Łatwiejsze podsumowywanie tras. Przypisz 10.1.0.0/16 do środowiska produkcyjnego, a następnie utwórz podsieci /24 dla każdej warstwy obciążenia.
Pozostaw co najmniej 30% miejsca w każdej podsieci Usługi skalowania, takie jak Virtual Machine Scale Sets, AKS i App Service Environments, szybko zużywają adresy IP podczas skalowania w poziomie. Podsieć /24 zapewnia 251 adresów IP do użycia. Jeśli wdrożenie bazowe wynosi 100, możesz zwiększyć tę wartość trzykrotnie.
Używaj ciągłych bloków CIDR dla każdego środowiska Upraszcza podsumowanie tras i reguły zapory. Pojedyncza ścieżka podsumowująca reprezentuje całe środowisko. Produkcja: 10.1.0.0/16. Środowisko testowe: 10.2.0.0/16. Programowanie: 10.3.0.0/16.
Unikaj zakresów zarezerwowanych przez platformę Azure i niedozwolonych Użycie zakresów zarezerwowanych powoduje błędy routingu i błędy wdrażania. Nie przypisz 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8 lub 255.255.255.255.255/32.
Dokumentuj alokacje w usłudze Azure IPAM lub w arkuszu kalkulacyjnym Zapobiega nakładaniu się na siebie w miarę rozwoju środowiska. Centralizuje widoczność zespołów sieciowych. Użyj usługi Azure Virtual Network Manager IPAM do zautomatyzowanego śledzenia lub obsługi udostępnionego arkusza kalkulacyjnego dla mniejszych środowisk.

Diagram przedstawiający podział przestrzeni adresowej sieci wirtualnej na podsieci dla warstw obciążeń i dedykowanych usług platformy, takich jak brama, zapora i bastion.

Typy publicznych adresów IP

Typ Co to jest Kiedy należy go używać
Standardowy publiczny adres IP Indywidualnie przypisany statyczny publiczny adres IP. Strefowo nadmiarowy domyślnie w regionach z obsługą strefy dostępności. Domyślnie zabezpieczone: cały ruch przychodzący jest blokowany, dopóki reguła NSG lub modułu równoważenia obciążenia na to nie zezwoli. Publicznie dostępne moduły równoważenia obciążenia, bramy sieci VPN, Azure Bastion, bramy aplikacyjne lub dowolny zasób, który wymaga unikalnego publicznego punktu końcowego.
Prefiks publicznego adresu IP Zastrzeżony blok publicznych adresów IP z określonego regionu. Gwarantuje sekwencyjne adresy. Brama NAT (wymaga prefiksu w przypadku wielu wychodzących adresów IP), zestawy skalowania maszyn wirtualnych lub gdy systemy zewnętrzne muszą dodać przewidywalny zakres adresów IP do listy dozwolonych.
BYOIP/ Niestandardowy prefiks adresu IP Publiczne zakresy adresów IP należące do klienta są wdrażane na platformie Azure w ramach trzyetapowego procesu: walidacji, aprowizacji i uruchomienia. Prefiksy regionalne są udostępniane w ciągu około 30 minut; udostępnienie prefiksów globalnych trwa od 3 do 4 godzin. Zachowanie reputacji IP podczas migracji do chmury, utrzymywanie wpisów na zewnętrznych listach dozwolonych lub spełnianie wymogów regulacyjnych dotyczących własności adresów IP. Adresy IP pochodzące z niestandardowego prefiksu IP mogą również używać usługi Azure DDoS Protection.

Note

Publiczne adresy IP jednostek SKU w warstwie Podstawowa zostały wycofane 30 września 2025 r. Istniejące podstawowe adresy IP nadal działają, ale nie są obsługiwane i nie mają umowy SLA. Przejdź na wariant SKU Standard dla wszystkich nowych wdrożeń.

Decyzja IPv6

Scenario Rekomendacja Uzasadnienie
Obciążenie robocze obsługuje tylko klientów IPv4, brak wymogu regulacyjnego dotyczącego IPv6 Tylko protokół IPv4 Najprostsza konfiguracja. Unika narzutów związanych z zarządzaniem dwoma stosami. Większość usług Azure obsługuje natywnie protokół IPv4.
Obciążenie musi obsługiwać klientów IPv6 lub przepisy wymagają obsługi protokołu IPv6 Dwustosowy (IPv4 + IPv6) Azure sieci wirtualne obsługują podsieci z podwójnym stosem. Wdróż protokół IPv6 obok protokołu IPv4 w tych samych zasobach.
Obciążenie wymaga protokołu IPv6, ale opiera się na Azure Firewall, Virtual WAN lub route Server Tylko protokół IPv4 (z zewnętrznym kończeniem protokołu IPv6) Azure Firewall, Virtual WAN i Route Server nie obsługują obecnie protokołu IPv6. Zakończ działanie protokołu IPv6 na zewnętrznym module równoważenia obciążenia lub urządzeniu brzegowym, zanim ruch przejdzie do tych usług. Funkcja VPN Gateway IPv6 jest dostępna w wersji zapoznawczej.

Podwójny stos IPv6 w Azure

Azure obsługuje wdrożenia dwóch stosów IPv6 w sieciach wirtualnych. Po włączeniu trybu dual-stack każda podsieć otrzymuje zarówno zakres IPv4, jak i zakres IPv6 /64. Zasoby odbierają adresy z obu rodzin i mogą komunikować się jednocześnie za pośrednictwem obu protokołów.

Protokół IPv6 w Azure ma określone wymagania dotyczące rozmiaru. Podsieci IPv6 muszą być dokładnie /64. Nie jest obsługiwana żadna inna długość prefiksu. Przestrzeń adresowa IPv6 przypisana do sieci wirtualnej musi być wystarczająco duża, aby pomieścić /64 podsieci dla każdej podsieci wymagającej łączności IPv6. Zaplanuj alokację adresów IPv6 wraz z zakresami IPv4 podczas początkowego projektowania sieci.

Następujące usługi Azure obsługują konfiguracje dwóch stosów protokołu IPv6:

Service Obsługa protokołu IPv6
Azure Virtual Network Podsieci dwustosowe z zakresami IPv6 /64
usługa Load Balancer w warstwie Standardowa Publiczne i wewnętrzne frontony IPv6
brama VPN Punkty końcowe tunelu IPv6 (wersja zapoznawcza; wymaga zgody)
NAT Gateway Translacja ruchu wychodzącego IPv6 (tylko dla SKU StandardV2; Standard SKU obsługuje tylko IPv4)
Publiczny adres IP (jednostka SKU w warstwie Standardowa) Publiczne adresy IPv6
Virtual Machine Scale Sets Interfejsy sieciowe IPv6
Komunikacja równorzędna sieci VNet Ruch IPv6 między równorzędnymi sieciami wirtualnymi
Grupy zabezpieczeń sieci Reguły IPv6 na potrzeby filtrowania
DNS (Azure DNS) Obsługa rekordów AAAA

Kluczowe usługi, które nie obsługują protokołu IPv6: Azure Firewall (wymaga tylko podsieci IPv4), Virtual WAN (tylko IPv4) i Route Server (tylko protokół IPv4). VPN Gateway obsługuje IPv6 w trybie dual-stack, ale tylko jako funkcję w wersji zapoznawczej (wymaga włączenia). Jeśli twoja architektura zależy od Azure Firewall, Virtual WAN lub Route Server na potrzeby inspekcji ruchu lub routingu, zaprojektuj sieć tak, aby ruch IPv6 był obsługiwany przed dotarciem do tych składników.

Aby uzyskać szczegółowe informacje na temat możliwości, ograniczeń i kroków konfiguracji protokołu IPv6, zobacz IPv6 dla Azure Virtual Network.

zarezerwowane adresy Azure

Azure rezerwuje pięć adresów IP w każdej podsieci:

Adres zastrzeżony Purpose
Pierwszy adres (.0) Identyfikator sieci
Drugi adres (.1) Brama domyślna
Trzeci adres (.2) mapowanie Azure DNS
Czwarty adres (.3) mapowanie Azure DNS
Ostatni adres (emisja) Adres emisji

Uwzględnij te pięć zarezerwowanych adresów we wszystkich obliczeniach ustalania rozmiaru podsieci. Podsieć /24 zapewnia łącznie 256 adresów, z czego 5 jest zarezerwowanych, co pozostawia 251 użytecznych adresów IP hostów. Najmniejsza obsługiwana podsieć IPv4 to /29 (8 adresów minus 5 zarezerwowanych = 3 do użycia). Największa obsługiwana podsieć IPv4 to /2.

Tip

Publiczne adresy IP jednostki SKU w warstwie Standardowa generują opłatę, niezależnie od tego, czy są one dołączone do zasobu. W ramach higieny adresów IP okresowo usuwaj nieużywane publiczne adresy IP i zwalniaj publiczne prefiksy IP, które przestały być wystarczające dla Twoich potrzeb. Nieprzyłączone publiczne adresy IP są częstym źródłem możliwych do uniknięcia kosztów i niepotrzebnego obszaru ataków.

Uwagi dotyczące projektowania

Nacisk projektu planowania adresacji IP typu „lift-and-shift”

  • Zarezerwuj jeden duży blok CIDR (często stosuje się /16) dla landing zone i podziel go na potrzeby każdej migrowanej aplikacji, pozostawiając bufor około 20% na przyszły wzrost.
  • Wybierz zakresy, które nie nakładają się na sieci lokalne, które łączą się za pośrednictwem VPN Gateway lub usługi ExpressRoute, dlatego routing działa bez tłumaczenia adresów.
  • Uwzględnij pięć zarezerwowanych adresów Azure na podsieć i dedykowane podsieci, których wymagają usługi platformy, takie jak GatewaySubnet (/27) i AzureFirewallSubnet (/26).
  • Tam, gdzie między sieciami nie występuje peering, można celowo ponownie wykorzystywać prywatne zakresy IPv4, aby oszczędzać przestrzeń adresową.

Unowocześnij projektowanie planowania IP

  • Przydziel niepokrywające się zakresy w głównym i zapasowym regionie, aby obciążenia w trybie active-active mogły później korzystać z globalnego peeringu bez ponownej adresacji.
  • Zarezerwuj dedykowaną podsieć o rozmiarze odpowiednim dla środowiska App Service Environment (/24 lub /23 przy skali zbliżonej do maksymalnej). W przypadku usługi AKS z funkcją CNI Overlay należy dobrać wielkość podsieci tylko dla węzłów, ponieważ pody korzystają z oddzielnego zakresu CIDR sieci nakładkowej, co sprawia, że podsieć dla węzłów może być znacznie mniejsza niż wymaga tego płaski model CNI.
  • Zarezerwuj dedykowaną podsieć dla prywatnych punktów końcowych, aby wdrożenie usługi PaaS nie fragmentował planu adresowego.
  • Korzystaj z zarządzania adresami IP w usłudze Azure Virtual Network Manager, aby śledzić i automatyzować przydziały wraz ze wzrostem skali środowiska.

Projektowanie z naciskiem na planowanie adresacji IP między chmurami

  • Najpierw opracuj globalny plan adresacji: zarezerwuj bloki CIDR platformy Azure, które nie nakładają się na istniejące sieci VPC w AWS ani sieci VPC w Google Cloud, co jest wymagane w przypadku trasowanej sieci VPN lub połączenia Interconnect.
  • Udokumentować zakresy adresów każdej połączonej chmury i gałęzi, aby można było zaplanować podsumowane trasy za pośrednictwem Azure Virtual WAN.
  • Zarezerwuj przestrzeń adresową dla składników tranzytowych, takich jak podsieci centrum Virtual WAN i bramy sieci VPN, z miejscem do skalowania podczas dodawania krawędzi chmury i gałęzi.
  • Jeśli nakładania się zakresów adresów nie da się uniknąć, zaplanuj zastosowanie NAT dla połączeń VPN, których to dotyczy, lub zmianę adresacji obciążeń roboczych podczas migracji, a nie po jej zakończeniu.

Prerequisites

Przed zaplanowanie alokacji adresów IP:

  • Projekt sieci wirtualnej: Masz istniejącą lub planowaną strukturę sieci wirtualnej. Jeśli nie masz jeszcze zaprojektowanych sieci wirtualnych, najpierw zapoznaj się z tematem Sieci wirtualne i podsieci platformy Azure.
  • Spis lokalnych adresów IP: Dokumentowanie istniejących lokalnych zakresów adresów, w tym zakresów używanych przez biura oddziałów, centra danych lub innych dostawców chmury. W przypadku łączności hybrydowej wymagane są nienakładane adresy.
  • Prognozy wzrostu: Szacowanie liczby dodatkowych podsieci i hostów potrzebnych w ciągu najbliższych 2–3 lat. Przydzielanie przestrzeni adresowej z góry jest łatwiejsze niż późniejsze rozszerzanie sieci wirtualnej.

Zagadnienia dotyczące zabezpieczeń

Planowanie adresów IP ma bezpośredni wpływ na zabezpieczenia. Postępuj zgodnie z tymi rozwiązaniami, aby zmniejszyć ryzyko:

  • Zapobiegaj nakładaniu się adresów: Nakładające się zakresy adresów IP między sieciami lokalnymi, sieciami wirtualnymi platformy Azure i sieciami równorzędnymi powodują problemy z routingiem. Ruch może trafić do niewłaściwego miejsca docelowego lub zostać odrzucony bez powiadomienia. Sprawdź, czy każdy zakres adresów jest unikatowy w całej sieci.
  • Unikaj zabronionych zakresów: Azure rezerwuje następujące zakresy dla operacji platformy. Nigdy nie używaj ich jako przestrzeni adresowej sieci wirtualnej:
    • 169.254.0.0/16 (link-lokalny)
    • 168.63.129.16/32 (wewnętrzny DNS platformy Azure)
    • 224.0.0.0/4 (multiemisji)
    • 127.0.0.0/8 (interfejs pętli zwrotnej)
    • 255.255.255.255/32 (emisja)
  • Dokument i inspekcja: Zachowaj bieżący rekord wszystkich alokacji adresów IP. Nieudokumentowane zakresy powodują przypadkowe nakładanie się podczas wdrażania nowych obciążeń roboczych. Użyj usługi Azure Virtual Network Manager IPAM na potrzeby zautomatyzowanego śledzenia zgodności lub obsługi udostępnionego arkusza kalkulacyjnego, który jest przeglądany podczas każdego wdrożenia.
  • Ochrona publicznych adresów IP: Kojarzenie Azure ochrony przed atakami DDoS z publicznymi zasobami IP w środowiskach produkcyjnych. Zakresy BYOIP mogą być również chronione przez ochronę przed atakami DDoS.

W tych artykułach omówiono tematy, które wchodzą w interakcję z planowaniem adresów IP:

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:

Zabezpiecz podsieci za pomocą grup zabezpieczeń sieciowych: Odwzoruj istniejące reguły zapory w postaci reguł NSG, aby zachować poziom zabezpieczeń na platformie Azure.

Kolejny etap procesu modernizacji:

Zabezpiecz swoje podsieci za pomocą grup zabezpieczeń sieci: Wymuszaj ścisłą segmentację, aby do podsieci aplikacji docierał tylko ruch z modułu równoważenia obciążenia.

Kolejny krok w Twojej wielochmurowej podróży:

Zabezpiecz swoje podsieci za pomocą grup zabezpieczeń sieciowych: Odwzoruj grupy zabezpieczeń AWS i reguły zapory Google Cloud jako grupy zabezpieczeń sieciowych platformy Azure.

  • Last updated on