Zapobieganie wyczerpaniu protokołu IPv4 na platformie Azure

W tym artykule opisano sposób minimalizowania zużycia prywatnej przestrzeni adresowej podczas tworzenia dużych sieci na platformie Azure. Może być konieczne zminimalizowanie użycia przestrzeni adresowej, jeśli nie ustanowiono odpowiednich zasad alokacji i zabraknie prywatnych adresów IP do przypisania do sieci wirtualnych platformy Azure. W tym artykule przedstawiono dwie metody odpowiedniego zarządzania adresami IP na platformie Azure.

Szczegóły scenariusza

Sieci firmowe zwykle używają przestrzeni adresowych, które znajdują się w prywatnych zakresach adresów IPv4 zdefiniowanych w dokumencie RFC 1918. Zakresy adresów to 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/166. W środowiskach lokalnych te zakresy zapewniają wystarczającą liczbę adresów IP, aby spełnić wymagania nawet największych sieci. W związku z tym wiele organizacji opracowuje praktyki zarządzania adresami, które priorytetują proste konfiguracje routingu i elastyczne procesy alokacji adresów IP. Efektywne wykorzystanie przestrzeni adresowej nie jest priorytetem.

W chmurze duże sieci hybrydowe są łatwe do skompilowania, a niektóre typowe wzorce architektury, takie jak mikrousługi lub konteneryzacja, mogą prowadzić do zwiększonego zużycia adresów IP. Dlatego ważne jest dostosowanie tych praktyk związanych z zarządzaniem adresami. W środowisku chmury traktuj prywatne adresy IPv4 jako ograniczony zasób.

Zakresy adresów IP usługi Azure Virtual Network

W sieciach wirtualnych platformy Azure zalecamy użycie bloków adresów zdefiniowanych przez RFC 1918. Te bloki adresów są przeznaczone dla sieci prywatnych ogólnego przeznaczenia i nie są dostępne w publicznym Internecie.

Możesz użyć innych zakresów, ale przed użyciem tych zakresów w sieci wirtualnej zapoznaj się z dokumentacją Internet Assigned Numbers Authority (IANA), aby zrozumieć potencjalne konsekwencje dla danego środowiska. Można użyć następujących zakresów:

• Udostępniona przestrzeń adresowa zdefiniowana przez RFC 6598 dla translacji adresów sieciowych klasy przewoźnika (NAT), która jest traktowana jako prywatna przestrzeń adresowa w usłudze Azure Virtual Network. Blok adresu to 100.64.0.0/10.
• Publiczne, routing internetowy adresy IP, których organizacja nie jest właścicielem. Jest to zalecane, ponieważ zasoby w sieci wirtualnej nie mogą uzyskiwać dostępu do internetowych punktów końcowych uwidocznionych za pośrednictwem publicznych adresów IP.
• Bloki adresów specjalnego przeznaczenia zdefiniowane przez IANA, takie jak 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 i 233.252.0.0/24.

Nie można używać następujących zakresów adresów IP w sieciach wirtualnych platformy Azure:

• 224.0.0.0/4 (multiemisji)
• 255.255.255.255/32 (emisja)
• 127.0.0.0/8 (sprzężenia zwrotnego)
• 169.254.0.0/16 (łącze lokalne)
• 168.63.129.16/32 (wewnętrzny system DNS)

Wyrównanie strefy docelowej platformy Azure

Zalecenia zawarte w tym artykule dotyczą scenariuszy opartych na architekturze strefy docelowej platformy Azure. W wytycznych przyjęto założenie, że:

• Każdy region ma topologię piasty i szprych.
• Sieci piasty i szprych, które znajdują się w różnych regionach, są ze sobą połączone za pośrednictwem globalnej komunikacji równorzędnej sieci wirtualnych lub połączeń z tym samym obwodem lub obwodami usługi Azure ExpressRoute.
• Sieci piasty i szprych są połączone z lokacjami lokalnymi za pośrednictwem kombinacji obwodów usługi ExpressRoute i sieci VPN typu lokacja-lokacja.

Na poniższym diagramie przedstawiono przykładową architekturę. Zalecenia mają równie zastosowanie do sieci opartych na usłudze Azure Virtual WAN, które mają również sieci piasty i szprych w każdym regionie.

Pobierz plik programu PowerPoint tej architektury.

W scenariuszu opartym na architekturze strefy docelowej platformy Azure aplikacje są wdrażane we własnej strefie docelowej. Każda strefa docelowa zawiera sieć wirtualną szprych, która jest równorzędna z regionalnym koncentratorem. Sieci wirtualne szprych są integralną częścią sieci firmowej i są przypisywane adresy IPv4. Te adresy są unikatowe w całej sieci firmowej. Dlatego wszystkie składniki architektury wdrożone w usłudze Azure Virtual Network używają adresów IPv4 w przestrzeni adresowej sieci firmowej, nawet jeśli tylko kilka składników uwidacznia punkty końcowe, które muszą być dostępne z całej sieci firmowej. Te składniki architektury mogą być maszynami wirtualnymi, urządzeniami wirtualnymi sieciowymi innych firm lub usługami paaS (platformy jako usługa) lub z siecią wirtualną.

W pozostałej części tego artykułu składnik frontonu odwołuje się do składnika aplikacji dostępnego z całej sieci firmowej lub spoza strefy docelowej składnika. Składnik zaplecza odwołuje się do składnika aplikacji, który nie uwidacznia punktów końcowych w sieci firmowej i musi być dostępny tylko z poziomu własnej strefy docelowej. Na przykład aplikacja internetowa, która uwidacznia punkt końcowy, jest składnikiem frontonu, a baza danych, która nie uwidacznia punktu końcowego, jest składnikiem zaplecza.

W poniższych sekcjach opisano dwie metody minimalizowania zużycia prywatnej przestrzeni adresowej podczas tworzenia dużych sieci na platformie Azure.

Metoda 1. Sieci wirtualne będące szprychami strefy docelowej bez routingu

RFC 1918 carves adres IP blokuje z przestrzeni adresowej IPv4 32-bitowej i sprawia, że nie można ich przekierować w publicznym Internecie, dzięki czemu można ich ponownie użyć w wielu sieciach prywatnych na potrzeby komunikacji wewnętrznej. Ta metoda jest oparta na tej samej zasadzie, która ma zastosowanie do prywatnej przestrzeni adresowej. Co najmniej jeden zakres adresów jest wyrzeźbiony z całej prywatnej przestrzeni adresowej używanej przez organizację i zadeklarowany jako niezwiązany z siecią firmową organizacji. Zakresy adresów są ponownie używane w wielu strefach docelowych. W rezultacie każda strefa docelowa:

• Ma przypisaną przestrzeń adresową routingu, która składa się z co najmniej jednego zakresu adresów. Twoja organizacja centralnie zarządza zakresami adresów i jednoznacznie przypisuje je do strefy docelowej na potrzeby komunikacji z siecią firmową. Adresy w przestrzeni routingu są przypisywane do składników frontonu.
• Może używać przestrzeni adresowej niezwiązanej z routingiem, czyli zakresów adresów zadeklarowanych przez organizację w sieci firmowej. Te zastrzeżone zakresy można używać do komunikacji wewnętrznej we wszystkich strefach docelowych. Adresy w przestrzeni niezwiązanej są przypisywane do składników zaplecza.

W sieci piasty i szprych platformy Azure zarządzanej przez klienta lub opartej na wirtualnej sieci WAN co najmniej dwie sieci wirtualne będące szprychami nie mogą mieć nakładających się przestrzeni adresowych IP. Nie można przypisać bloków adresów niezwiązanych z szprychą strefy docelowej. Komunikacja równorzędna sieci wirtualnych jest nieprzejeżona, więc sieć wirtualna będącej szprychą strefy docelowej może być równorzędna z siecią wirtualną szprych drugiego poziomu , która ma niepodlegającą routingowi przestrzeń adresową. Na poniższym diagramie przedstawiono podwójną topologię sieci wirtualnej dla stref docelowych.

Pobierz plik programu PowerPoint tej architektury.

Każda strefa docelowa aplikacji zawiera dwie równorzędne sieci wirtualne. Jedna sieć wirtualna ma routingowe adresy IP i hosty składników frontonu. Druga sieć wirtualna ma niezwiązane adresy IP i składniki zaplecza hostów. Routingowa strefa docelowa równorzędna szprychy z regionalnym koncentratorem. Nieroutable strefy docelowej szprychy równorzędne z rozruszną strefą docelową szprychy. Komunikacja równorzędna sieci wirtualnych nie jest transiktywna, dlatego prefiksy niezwiązane z routingiem nie są widoczne dla regionalnego centrum ani pozostałej części sieci firmowej. Routingowe sieci wirtualne nie mogą używać zakresów adresów niezwiązanych z routingiem. Niektóre organizacje mają fragmentowaną przestrzeń adresową, która jest już przypisana do sieci routingu. Identyfikowanie nieużywanych dużych bloków adresów i deklarowanie ich bez routingu może być trudne. W takim przypadku rozważ nieużywane adresy, które nie są uwzględnione w przestrzeni adresowej RFC 1918. Na poprzednim diagramie przedstawiono przykład adresów NAT klasy przewoźnika, takich jak RFC 6598, w niekondycyjnych sieciach wirtualnych szprych.

Migracja pojedynczej strefy docelowej sieci wirtualnej

Komunikacja równorzędna sieci wirtualnych zapewnia pełną łączność warstwy 3 między dwiema równorzędną sieciami wirtualnymi. Składniki aplikacji wdrożone w tradycyjnych strefach docelowych pojedynczej sieci wirtualnej, które komunikują się ze sobą za pośrednictwem adresu IP, mogą być swobodnie przenoszone między routingiem i niekonsuwalnymi sieciami wirtualnymi szprych w strefie docelowej. W tej sekcji opisano dwa typowe wzorce migracji.

Następujące aplikacje są udostępniane za pośrednictwem kontrolerów dostarczania aplikacji warstwy 7:

Pobierz plik programu PowerPoint tej architektury.

Aplikacje uwidocznione za pośrednictwem kontrolerów dostarczania aplikacji warstwy 7 można przenosić do niekonstrucyjnej szprychy. Kontroler dostarczania aplikacji jest jedynym składnikiem frontonu, który musi znajdować się w szprychy strefy docelowej routingu.

Następujące aplikacje są uwidocznione za pośrednictwem modułu równoważenia obciążenia platformy Azure:

Pobierz plik programu PowerPoint tej architektury.

Jeśli aplikacja uwidacznia swoje punkty końcowe za pośrednictwem modułu równoważenia obciążenia platformy Azure, wystąpienia obliczeniowe będące częścią puli zaplecza modułu równoważenia obciążenia muszą pozostać w tej samej sieci wirtualnej. Moduły równoważenia obciążenia platformy Azure obsługują tylko wystąpienia zaplecza w własnej sieci wirtualnej.

Zależności wychodzące

Składniki zaplecza aplikacji nie muszą być dostępne ani odbierać połączeń przychodzących z sieci firmowej, ale często mają zależności wychodzące. Składniki zaplecza mogą wymagać połączenia z punktami końcowymi, które znajdują się poza ich strefami docelowymi w wystąpieniach, takich jak rozpoznawanie nazw DNS, domena usługi Active Directory Kontrolery domeny usług, uzyskiwanie dostępu do punktów końcowych aplikacji, które są udostępniane przez inne strefy docelowe lub uzyskiwanie dostępu do rejestrowania lub obiektów kopii zapasowych.

Gdy usługi inicjują połączenia w sieciach wirtualnych szprych bez routingu, należy zaimplementować źródłowy translator adresów sieciowych (SNAT) dla połączeń za routingowym adresem IP. Aby zaimplementować protokół SNAT, wdróż urządzenie obsługujące translator adresów sieciowych w sieci wirtualnej rozsyłanej szprychy. Każda strefa docelowa działa we własnym dedykowanym wirtualnym urządzeniu sieciowym translatora adresów sieciowych. Istnieją dwie opcje implementowania sieci SNAT w strefie docelowej: Azure Firewall lub urządzenia WUS innych firm. W obu przypadkach wszystkie podsieci w niepodstawnej szprychy muszą być skojarzone z niestandardową tabelą tras. Jak pokazano na poniższym diagramie, tabela tras przekazuje ruch do miejsc docelowych poza strefą docelową do urządzenia SNAT. Usługa Azure NAT Gateway nie obsługuje protokołu SNAT dla ruchu kierowanego do prywatnej przestrzeni adresowej IP, takiej jak przestrzeń RFC 1918.

Pobierz plik programu PowerPoint tej architektury.

Implementowanie protokołu SNAT za pośrednictwem usługi Azure Firewall

Azure Firewall:

• Zapewnia wysoką dostępność.
• Zapewnia natywną skalowalność i trzy różne jednostki SKU. SNAT nie jest zadaniem intensywnie korzystającym z zasobów, dlatego najpierw rozważ podstawową jednostkę SKU. W przypadku stref docelowych, które wymagają dużych ilości ruchu wychodzącego z przestrzeni adresowej bez routingu, użyj standardowej jednostki SKU.
• Wykonuje SNAT dla ruchu za prywatnymi adresami IP dowolnego z jego wystąpień. Każde wystąpienie może używać wszystkich nieuprzywilejowanych portów.

Na poniższym diagramie przedstawiono układ strefy docelowej w celu zaimplementowania protokołu SNAT w topologii sieci piasty i szprych przy użyciu usługi Azure Firewall.

Pobierz plik programu PowerPoint tej architektury.

Aby wysyłać ruch do miejsc docelowych poza strefą docelową do usługi Azure Firewall, należy skojarzyć wszystkie podsieci w niepodstawowej szprychy z niestandardową tabelą tras.

Na poniższym diagramie przedstawiono układ strefy docelowej w celu zaimplementowania protokołu SNAT w sieci piasty i szprych opartej na usłudze Virtual WAN przy użyciu usługi Azure Firewall.

Pobierz plik programu PowerPoint tej architektury.

Należy skojarzyć wszystkie podsieci w szprychach niepodstawialnych lub szprychach, które nie są połączone z usługą Virtual WAN, z niestandardową tabelą tras w celu wysyłania ruchu do miejsc docelowych poza strefą docelową do usługi Azure Firewall.

W przypadku obu układów, aby zapewnić zasoby w niekonserowalnym dostępie szprychy do routingu adresów IP poza ich strefą docelową, należy wdrożyć usługę Azure Firewall z opcją Wykonaj SNAT ustawioną na zawsze w rozrusznej szprychy każdej strefy docelowej. Instrukcje dotyczące konfigurowania usługi Azure Firewall w celu zaimplementowania protokołu SNAT we wszystkich odebranych połączeniach można znaleźć w dokumentacji publicznej. Poniższy zrzut ekranu przedstawia wymaganą konfigurację używania usługi Azure Firewall jako urządzenia NAT dla połączeń inicjowanych przez zasoby w niekonskrywalnych sieciach wirtualnych szprych.

Implementowanie SNAT za pośrednictwem urządzeń WUS innych firm

Urządzenia WUS innych firm z funkcjami translatora adresów sieciowych są dostępne w witrynie Azure Marketplace. Zapewniają one:

• Szczegółowa kontrola nad skalowaniem i skalowaniem w poziomie.
• Szczegółowa kontrola puli translatora adresów sieciowych.
• Niestandardowe zasady translatora adresów sieciowych, takie jak używanie różnych adresów NAT w zależności od właściwości połączenia przychodzącego, takich jak źródłowy lub docelowy adres IP.

Rozważmy następujące zalecenia:

• Aby zapewnić wysoką dostępność, wdróż klastry z co najmniej dwoma urządzeniami WUS. Użyj modułu równoważenia obciążenia platformy Azure, aby dystrybuować połączenia przychodzące z niekonstrybuowanej sieci wirtualnej szprych do urządzeń WUS. Wymagana jest reguła równoważenia obciążenia portów o wysokiej dostępności, ponieważ klaster implementuje protokół SNAT na wszystkich połączeniach opuszczających strefę docelową. Usługa Azure usługa Load Balancer w warstwie Standardowa obsługuje reguły równoważenia obciążenia portów o wysokiej dostępności.
• Stos SDN platformy Azure obsługuje urządzenia WUS z pojedynczym ramieniem i dwoma armami. Preferowane są urządzenia WUS z jednym ramieniem, ponieważ zmniejszają zużycie przestrzeni adresowej w sieciach wirtualnych szprych.

Na poniższym diagramie przedstawiono układ strefy docelowej w celu zaimplementowania protokołu SNAT w topologii sieci piasty i szprych przy użyciu urządzeń WUS innych firm.

Pobierz plik programu PowerPoint tej architektury.

Na poniższym diagramie przedstawiono układ strefy docelowej w celu zaimplementowania protokołu SNAT w topologii sieci piasty i szprych opartej na usłudze Virtual WAN przy użyciu urządzeń WUS innych firm.

Pobierz plik programu PowerPoint tej architektury.

W przypadku obu układów urządzenia WUS innej firmy należy wdrożyć wiele wystąpień za modułem równoważenia obciążenia platformy Azure, aby zapewnić wysoką dostępność. Wymagana jest jednostka SKU usługi Azure Load Balancer w warstwie Standardowa.

Metoda 2. Usługi Azure Private Link

Usługa Private Link zapewnia dostęp do aplikacji wdrożonych w sieci wirtualnej, która nie jest połączona z siecią wirtualną. W sieci wirtualnej po stronie serwera lub aplikacji usługa Private Link jest wdrażana i skojarzona z punktem końcowym aplikacji uwidocznionym na adresie IP frontonu wewnętrznego standardowego modułu równoważenia obciążenia jednostki SKU platformy Azure. W sieci wirtualnej po stronie klienta jest wdrażany i skojarzony z usługą Private Link zasób prywatnego punktu końcowego. Prywatny punkt końcowy uwidacznia punkt końcowy aplikacji w sieciach wirtualnych. Usługa Private Link udostępnia logikę tunelowania i translatora adresów sieciowych do kierowania ruchu między po stronie klienta i po stronie serwera. Aby uzyskać więcej informacji, zobacz Co to jest usługa Azure Private Link?

Usługa Private Link nie wymaga połączenia warstwy 3 między siecią wirtualną po stronie klienta i siecią wirtualną po stronie serwera. Dwie sieci wirtualne mogą mieć nakładające się przestrzenie adresowe IP. Usługa Private Link umożliwia wdrażanie aplikacji w dedykowanych, izolowanych sieciach wirtualnych, z których wszystkie korzystają z tej samej przestrzeni adresowej bez routingu. Aplikacje są uwidocznione jako usługi Private Link w sieci firmowej, które używają przestrzeń adresową routingu. W kontekście architektury strefy docelowej platformy Azure wynikowa topologia strefy docelowej ma następujące elementy:

• Izolowana sieć wirtualna, która hostuje całą aplikację i usługę Private Link skojarzona z punktami końcowymi aplikacji. Zespół aplikacji definiuje przestrzeń adresową sieci wirtualnej.
• Sieć wirtualna będące szprychą z routingową przestrzenią adresową, która hostuje prywatny punkt końcowy skojarzony z usługą Private Link. Sieć wirtualna szprychy jest bezpośrednio równorzędna z regionalnym koncentratorem.

Na poniższym diagramie przedstawiono topologię strefy docelowej z obsługą usługi Private Link.

Pobierz plik programu PowerPoint tej architektury.

Używanie usługi Private Link dla zależności wychodzących

Podczas wdrażania aplikacji w izolowanych sieciach wirtualnych szprych użyj usługi Private Link dla zależności wychodzących. Zdefiniuj prywatne punkty końcowe w izolowanej sieci wirtualnej będącej szprychą i skojarz je z usługą Private Link w sieciach wirtualnych z routingiem. Na poniższym diagramie przedstawiono podejście koncepcyjne.

Pobierz plik programu PowerPoint tej architektury.

W rzeczywistych implementacjach na dużą skalę metoda usługi Private Link może nie mieć zastosowania:

• Jeśli aplikacje wdrożone w izolowanej sieci wirtualnej mają wiele zależności wychodzących. Podczas wdrażania usługi Private Link i prywatnego punktu końcowego dla każdego z zależności wychodzących zwiększa złożoność i potrzeby zarządzania.
• Jeśli zależność wychodząca obejmuje punkty końcowe w sieci routingu, które nie mogą być częścią puli zaplecza usługi Azure Load Balancer, usługa Private Link nie ma zastosowania.

Aby przezwyciężyć te dwa ograniczenia, wdróż rozwiązanie serwera proxy/translatora adresów sieciowych w szprychy routingu i udostępnij je z izolowanej sieci wirtualnej przy użyciu usługi Private Link.

Pobierz plik programu PowerPoint tej architektury.

Użyj pojedynczego prywatnego punktu końcowego lub usługi Private Link, aby uwidocznić rozwiązanie serwera proxy/translatora adresów sieciowych wdrożone w sieci routingu. Reguły translacji portów i translacji adresów są definiowane na urządzeniach WUS. Te reguły umożliwiają korzystanie z pojedynczego prywatnego punktu końcowego w izolowanej sieci wirtualnej w celu uzyskania dostępu do wielu zależności w sieci routingowej.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

• Federico Guerrini | Lider techniczny w regionie EMEA
• Khush Kaviraj | Architekt rozwiązań w chmurze
• Jack Tracey | Starszy architekt rozwiązań w chmurze

Inni współautorzy:

• Jodi Martis | Składnik zapisywania technicznego

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

• Wdrażanie usługi Azure Firewall w sieci wirtualnej
• Konfigurowanie protokołu SNAT w usłudze Azure Firewall
• Obsługiwane adresy IP w usłudze Azure Virtual Network
• Link prywatny platformy Azure
• Azure Load Balancer
• Komunikacja równorzędna sieci wirtualnych

Powiązane zasoby

• Projektowanie architektury sieci
• Metody architektury dla sieci w rozwiązaniach wielodostępnych
• Topologia sieci piasty i szprych