Zapobieganie wyczerpaniu protokołu IPv4 na platformie Azure

Sieci firmowe zwykle używają przestrzeni adresowych z prywatnych zakresów adresów IPv4 zdefiniowanych przez żądanie komentarzy (RFC) 1918, takich jak 10.0.0.0/8, 172.16.0.0/12i 192.168.0.0/16. 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. Często nie ustalają priorytetów efektywnego użycia przestrzeni adresowej IPv4.

W chmurze duże sieci można łatwo tworzyć. Niektóre typowe wzorce architektury, takie jak mikrousługi lub konteneryzacja, mogą prowadzić do zwiększenia użycia adresów IPv4. Dlatego ważne jest, aby przyjąć bardziej konserwatywne praktyki zarządzania adresami i traktować adresy IPv4 jako ograniczony zasób.

Uwaga / Notatka

Zalecamy używanie bloków adresów zdefiniowanych przez RFC 1918 w sieciach wirtualnych platformy Azure. Aby uzyskać więcej informacji, zobacz Zakresy adresów dla sieci wirtualnych.

W tym artykule opisano dwie metody minimalizowania użycia przestrzeni adresowej IPv4 podczas tworzenia dużych sieci na platformie Azure. Metody korzystają z topologii sieci, które ponownie korzystają z tych samych bloków adresów IPv4 w wielu sieciach wirtualnych lub strefach docelowych.

• Metoda 1: Użyj peeringu podsieci IPv4, aby wykluczyć co najmniej jedną podsieć z peeringu między siecią wirtualną szprychy strefy przyziemienia a siecią wirtualną hubu. Do podsieci wykluczonych z relacji komunikacji równorzędnej we wszystkich strefach docelowych można przypisać te same nieskierowalne zakresy adresów IP. Te zakresy adresów IP nie mogą nakładać się na inne zakresy adresów IP, które mogą być routowane.

• Metoda 2: Wdrażanie aplikacji w izolowanych sieciach wirtualnych, które nie są połączone z sieciami wirtualnymi stref docelowych. Kojarzenie punktów końcowych z usługami Azure Private Link. W sieciach wirtualnych szprych w strefach docelowych utwórz prywatne punkty końcowe skojarzone z usługami Private Link. Izolowane sieci wirtualne mogą używać dowolnej przestrzeni adresowej IPv4, nawet jeśli nakładają się na przestrzeń adresową sieci firmowej.

Metoda 1 działa najlepiej w tradycyjnych środowiskach przedsiębiorstwa, w których wiele systemów i aplikacji zależy od siebie nawzajem. Metoda 2 działa najlepiej w luźno powiązanych środowiskach, w których aplikacje działają niezależnie.

Wyrównanie strefy docelowej platformy Azure

Zalecenia zawarte w tym artykule dotyczą topologii sieci opartych na architekturze strefy docelowej platformy Azure:

• Każdy region hostujący zasoby platformy Azure ma sieć o gwiaździstej strukturze.

• Sieci gwiaździste w różnych regionach łączą się poprzez globalny peering wirtualnych sieci.

• Sieci typu hub-and-spoke łączą się z lokalnymi obiektami za pośrednictwem łączy Azure ExpressRoute lub VPN-ów między lokacjami.

W architekturze strefy wstrzymania platformy Azure każda aplikacja działa we własnej sieci wirtualnej w modelu 'szprychy'. Każda sieć wirtualna spoke używa unikalnej przestrzeni adresowej IPv4 w całej sieci korporacyjnej.

Wszystkie zasoby w strefie docelowej mogą łączyć się w następujący sposób:

• Użyj swojego adresu IP, aby zainicjować połączenia z innymi zasobami w sieci firmowej

• Odbieranie połączeń bezpośrednich z całej sieci firmowej za pośrednictwem ich adresu IP

Jednak zasoby nie zawsze wymagają dostępności z całej sieci firmowej. Na przykład w strefie docelowej zawierającej aplikację internetową trójwarstwową, taką jak fronton HTTP, logika biznesowa i warstwa danych, tylko fronton HTTP musi być dostępny spoza strefy docelowej. Pozostałe warstwy muszą łączyć się ze sobą oraz z interfejsem użytkownika, ale nie muszą przyjmować połączeń od klientów. Ten przykład sugeruje, że można zminimalizować użycie adresów IPv4, przypisując następujące składniki do każdej strefy docelowej:

• Przestrzeń adresowa unikatowa w całej sieci firmowej. Tej przestrzeni adresowej używają tylko zasoby, które muszą być dostępne poza ich strefą docelową. W tym artykule przestrzeń adresowa jest określana jako routowalna przestrzeń adresowa strefy docelowej.

• Wewnętrzna przestrzeń adresowa zasobów, które muszą komunikować się tylko z innymi zasobami wewnątrz własnej strefy docelowej. Ta przestrzeń adresowa nie wymaga bezpośredniego zasięgu z sieci firmowej. Ten artykuł odnosi się do tej przestrzeni adresowej jako niezroutowalnej przestrzeni adresowej strefy docelowej.

W poniższych sekcjach składnik frontonu odwołuje się do składnika aplikacji, który musi być dostępny z całej sieci firmowej. 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 w ramach własnej strefy docelowej.

Metoda 1: Nieroutowalne podsieci w szprychowych sieciach wirtualnych

Możesz użyć połączenia równorzędnego dla podsieci IPv4, aby ograniczyć relację między dwiema sieciami wirtualnymi do określonych podsieci. Tylko podsieci uwzględnione w konfiguracji peeringu mogą kierować ruch do siebie nawzajem. Podsieci wykluczone z konfiguracji peeringu pozostają niewidoczne i niedostępne z równorzędnej sieci wirtualnej.

W topologii piasty i szprych, jeśli wykluczysz jedną lub więcej podsieci w każdej szprychy z konfiguracji komunikacji równorzędnej, te podsieci pozostają niewidoczne i niemożliwy do osiągnięcia z centrum oraz z dowolnej sieci zdalnej połączonej z piastą za pośrednictwem innych połączeń komunikacji równorzędnej, połączeń usługi ExpressRoute lub połączeń sieci VPN. W związku z tym można przypisać ten sam zakres adresów do wszystkich podsieci wykluczonych z konfiguracji komunikacji równorzędnej we wszystkich sieciach wirtualnych szprych. Ten zakres musi być zdefiniowany jako nietypowy i nie może być używany nigdzie indziej w sieci firmowej.

Poniższy diagram zawiera następujące składniki:

• Zakres 10.57.0.0/16 służy jako nieroutowalna przestrzeń adresowa.

• Sieć wirtualna piasty i każda sieć wirtualna będąca szprychą strefy docelowej używają unikalnych, możliwych do routingu zakresów adresów IP (10.0.0.0/24, 10.1.0.0/24, i 10.2.0.0/24).

• Każda sieć wirtualna typu spoke strefy docelowej zawiera również jedną lub więcej nieroutowalnych podsieci w zakresie nieroutowalnym 10.57.0.0/16. Przestrzeń adresowa sieci wirtualnej platformy Azure może zawierać wiele zakresów adresów IP.

• Te podsieci są wykluczone z relacji równorzędnej z koncentratorem. W związku z tym nieroutowalne podsieci w odgałęzieniach w różnych strefach docelowych mogą mieć te same lub nakładające się zakresy adresów wewnątrz 10.57.0.0/16.

Ten diagram zawiera węzeł i dwa ramiona w oddzielnych strefach docelowych. Piasta zawiera trzy routowalne podsieci. Każda odnoga strefy docelowej zawiera dwie podsieci routowalne i dwie podsieci nieroutowalne. Koncentrator jest połączony z każdą strefą lądowania za pośrednictwem peeringu podsieci. W połączeniach równorzędnych znajdują się tylko routowalne podsieci w węźle centralnym i spoke'ach.

Pobierz plik programu PowerPoint tej architektury.

Takie podejście zachowuje pełną łączność w sieci wirtualnej w ramionach strefy lądowania. Wszystkie zasoby w tej samej sieci wirtualnej typu szprychowego mogą łączyć się ze sobą, niezależnie od tego, czy znajdują się w podsieciach routowalnych, czy nieroutowalnych. Jednak tylko zasoby w podsieciach routingu mogą łączyć się z zasobami poza własną strefą docelową.

Wdrażanie aplikacji w strefach docelowych

W przypadku używania peeringu podsieci do tworzenia stref docelowych z podsieciami nieroutowalnymi, można zastosować różne wzorce w celu dystrybucji składników front-endu i back-endu aplikacji między podsieciami routowalnymi i nieroutowalnymi. Poniższe zagadnienia dotyczą zarówno nowo utworzonych aplikacji, jak i aplikacji migrowanych z tradycyjnych stref docelowych korzystających z jednej, w pełni routingowej przestrzeni adresowej.

• Aplikacje udostępniane za pośrednictwem kontrolerów dostarczania aplikacji warstwy 7: Te kontrolery dostarczania aplikacji obejmują usługę Azure Application Gateway lub nienależące do Microsoftu wirtualne urządzenia sieciowe (NVA). Tylko punkt końcowy kontrolera dostarczania aplikacji musi być dostępny z klientów spoza strefy docelowej. W związku z tym kontroler dostarczania aplikacji jest jedynym składnikiem front-endowym, który musi znajdować się w routowalnej podsieci.

• Aplikacje uwidocznione za pośrednictwem modułu równoważenia obciążenia platformy Azure: Jeśli aplikacja używa wewnętrznego modułu równoważenia obciążenia platformy Azure, maszyny wirtualne w puli zaplecza modułu równoważenia obciążenia muszą znajdować się w podsieci routingu. Wszystkie pozostałe składniki można wdrożyć w podsieciach niemożliwych do routowania.

Na poniższym diagramie przedstawiono następujące wzorce:

• Strefa docelowa A hostuje trzywarstwową aplikację internetową uwidocznioną za pośrednictwem kontrolera dostarczania aplikacji, który jest jedynym składnikiem w podsieci routingu.

• Strefa docelowa B hostuje aplikację trójwarstwową udostępnioną za pośrednictwem wewnętrznego modułu równoważenia obciążenia platformy Azure.

Ten diagram zawiera węzeł i dwa ramiona w oddzielnych strefach docelowych. Piasta zawiera trzy routowalne podsieci. Strefa docelowa A zawiera kontroler dostarczania aplikacji w routowalnej podsieci oraz front-end HTTP, logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Część strefy docelowej B zawiera interfejs TCP/IP w routowalnej podsieci oraz logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Węzeł centralny jest połączony z routowalnymi podsieciami w każdym rozgałęzieniu za pośrednictwem parowania podsieci.

Pobierz plik programu PowerPoint tej architektury.

Zależności wychodzące

Składniki zaplecza aplikacji nie muszą odbierać połączeń przychodzących z sieci firmowej. Może jednak być konieczne zainicjowanie połączeń z punktami końcowymi poza ich strefą docelową. Typowe przykłady obejmują rozpoznawanie systemu nazw domen (DNS), interakcję z kontrolerami domeny usług Active Directory Domain Services (AD DS) oraz dostęp do aplikacji w innych strefach docelowych lub usługach udostępnionych, takich jak zarządzanie dziennikami lub systemy tworzenia kopii zapasowych.

Jeśli zasoby w podsieciach nieroutowalnych muszą inicjować połączenia z punktami końcowymi poza ich strefą docelową, te połączenia muszą używać źródłowego translatora adresów sieciowych (SNAT) za routowalnym adresem IP. W związku z tym należy wdrożyć w każdej strefie docelowej urządzenie wirtualne (NVA) obsługujące NAT w routowalnej podsieci. Na poniższym diagramie przedstawiono tę konfigurację.

Ten diagram zawiera węzeł i dwa ramiona w oddzielnych strefach docelowych. Piasta zawiera trzy routowalne podsieci. Strefa docelowa A zawiera kontroler dostarczania aplikacji i translator adresów sieciowych w osobnych routowalnych podsieciach. Zawiera również interfejs HTTP, logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Kontroler dostarczania aplikacji wskazuje trzy elementy w podsieci HTTP frontend. Połączenie ze składnika przechodzi przez zaporę w centrum za pośrednictwem protokołu SNAT. Ramię strefy docelowej B zawiera interfejs wejsciowy TCP/IP oraz translator adresów sieciowych w oddzielnych podsiecach routowalnych. Zawiera również logikę biznesową i warstwę danych w oddzielnych podsieciach niepodstawialnych. Połączenie ze składnika w podsieci logiki biznesowej przechodzi przez zaporę w centrum za pośrednictwem protokołu SNAT. Piasta jest połączona z każdą szprychą strefy docelowej.

Pobierz plik programu PowerPoint tej architektury.

Podsieci niezwiązane z routingiem muszą używać niestandardowej tabeli tras, która przekazuje cały ruch kierowany poza strefę docelową do wirtualnego urządzenia sieciowego obsługującego translator adresów sieciowych. Na poprzednim diagramie zakres 10.57.0.0/16 jest nieroutowalny, a inne zakresy w obrębie 10.0.0.0/8 są routowalne. Niestandardowa tabela tras dla każdej podsieci innej niż trasa zdefiniowana przez użytkownika musi zawierać następującą trasę zdefiniowaną przez użytkownika.

Destynacja	Typ następnego przeskoku	Adres IP następnego przeskoku
10.0.0.0/8	VirtualNetworkAppliance	<Adres IP NVA z obsługą NAT będący w konfiguracji szprychy>

Tabela tras systemowych sieci wirtualnej zawiera już trasę systemową dla miejsc docelowych w zakresie nieroutale 10.57.0.0/16 . Nie musisz definiować tras zdefiniowanych przez użytkownika dla ruchu w tym zakresie.

Routowalne podsieci, w tym podsieć, która hostuje urządzenie NVA obsługujące NAT, muszą używać niestandardowej tabeli tras, która przekazuje ruch na zewnątrz strefy lądowania, zazwyczaj do urządzeń NVA w sieci wirtualnej koncentratora. Te urządzenia NVAs kierują ruch między węzłami. Te urządzenia centrów NVAs nie wykonują operacji translacji adresów sieciowych. Na poprzednim diagramie niestandardowa tabela tras dla każdej trasowalnej podsieci musi zawierać następujące UDR.

Destynacja	Typ następnego przeskoku	Adres IP następnego przeskoku
10.0.0.0/8	VirtualNetworkAppliance	<Router koncentratora/adres IP zapory>
10.0.0.0/24	VirtualNetworkAppliance	<Router koncentratora/adres IP zapory>

Druga UDR z miejscem docelowym 10.0.0.0/24 zapewnia, że połączenia z zasobami w sieci wirtualnej koncentratora są kierowane przez zaporę sieciową koncentratora. Niektóre aplikacje mogą wymagać więcej UDR. Jeśli maszyny wirtualne w strefie docelowej wymagają dostępu do Internetu za pośrednictwem NVAs, które są zwykle hostowane w centralnym węźle, należy również zdefiniować domyślną trasę 0.0.0.0/0.

Uwaga / Notatka

Komunikacja kontrolera domeny klientato-AD AD DS za pośrednictwem funkcji NAT jest obsługiwana. Komunikacja między kontrolerami domen przez NAT nie została przetestowana i nie jest obsługiwana. Aby uzyskać więcej informacji, zobacz Granice wsparcia dla usługi Active Directory systemu Windows Server za pośrednictwem NAT. Zalecamy wdrożenie kontrolerów domeny usługi Active Directory systemu Windows Server w podsieciach routingu.

Możesz użyć usługi Azure Firewall lub innych niż Microsoft wirtualnych urządzeń sieciowych (NVA) jako urządzeń umożliwiających translację adresów sieciowych (NAT). W poniższych sekcjach omówiono obie opcje. Nie można użyć Azure NAT Gateway, ponieważ obsługuje ona tylko SNAT dla ruchu kierowanego do Internetu.

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

Jeśli priorytetowe traktowanie niskiej złożoności i minimalnego zarządzania jest wymagane, Azure Firewall zapewnia najlepsze rozwiązanie do implementacji SNAT dla połączeń pochodzących z nieroutowalnych podsieci. Usługa Azure Firewall zapewnia następujące korzyści:

• W pełni zarządzany cykl życia
• Wbudowana wysoka dostępność
• Skalowanie automatyczne na podstawie woluminu ruchu

W przypadku korzystania z usługi Azure Firewall należy wziąć pod uwagę następujące czynniki:

• Wdróż usługę Azure Firewall we własnej zarezerwowanej podsieci o nazwie AzureFirewallSubnet, która musi używać routingowej przestrzeni adresowej.

• Niektóre jednostki SKU lub konfiguracje usługi Azure Firewall mogą wymagać drugiej zarezerwowanej podsieci na potrzeby zarządzania zaporą. Podsieć zarządzania nie wymaga routingowej przestrzeni adresowej.

• Usługa Azure Firewall ma trzy różne jednostki SKU. SNAT nie jest intensywnie obciążana zasobami, więc zacznij od jednostki SKU w warstwie Podstawowa. W przypadku stref lądowania, które generują duże ilości ruchu wychodzącego z podsieci nieroutowalnych, rozważ SKU Standard.

• Skonfiguruj usługę Azure Firewall przy użyciu opcji Wykonaj SNAT ustawioną na zawsze. Każde wystąpienie używa swoich nieuprzywilejowanych portów dla protokołu SNAT. Aby skonfigurować usługę Azure Firewall do implementowania protokołu SNAT na wszystkich odebranych połączeniach, wykonaj kroki konfiguracji SNAT.

• Skojarz wszystkie nieroutowalne podsieci z niestandardową tablicą tras, która przekierowuje cały ruch przeznaczony poza strefę docelową do prywatnego adresu IP zapory.

Na poniższym diagramie przedstawiono sieć gwiaździstą, w której każde ramię używa usługi Azure Firewall do realizacji SNAT dla połączeń z podsieci nieroutowalnych.

Ten diagram zawiera węzeł i dwa ramiona w oddzielnych strefach docelowych. Piasta zawiera trzy routowalne podsieci. Strefa docelowa A zawiera kontroler dostarczania aplikacji i zaporę w oddzielnych routowalnych podsieciach. Zawiera również interfejs HTTP, logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Kontroler dostarczania aplikacji wskazuje trzy elementy w podsieci HTTP frontend. Połączenie ze składnika przechodzi przez zaporę w centrum za pośrednictwem protokołu SNAT. Sekcja strefy docelowej B zawiera interfejs TCP/IP i zaporę w oddzielnych routowalnych podsieciach. Zawiera również logikę biznesową i warstwę danych w oddzielnych podsieciach niepodstawialnych. Połączenie ze składnika w podsieci logiki biznesowej przechodzi przez zaporę w centrum za pośrednictwem protokołu SNAT. Piasta jest połączona z każdą szprychą strefy docelowej.

Pobierz plik programu PowerPoint tej architektury.

Implementuj SNAT za pomocą wirtualnych urządzeń sieciowych innych niż Microsoft.

W Azure Marketplace można znaleźć inne niż Microsoft wirtualne urządzenia sieciowe (NVAs), które mają możliwości NAT. Rozważ użycie urządzenia WUS firmy innej niż Microsoft, jeśli wymagania przekraczają możliwości obsługi usługi Azure Firewall. Na przykład mogą być potrzebne następujące możliwości:

• Szczegółowa kontrola nad pulą NAT

• Niestandardowe zasady NAT, na przykład, może być konieczne użycie różnych adresów NAT dla różnych połączeń

• Szczegółowa kontrola nad zmniejszaniem i zwiększaniem zasobów

Korzystając z NVAs innych niż firmy Microsoft, należy wziąć pod uwagę następujące czynniki:

• Wdróż klaster, który zawiera co najmniej dwa Wirtualne Urządzenia Sieciowe (WUS), aby zapewnić wysoką dostępność.

• Użyj Standardowego SKU modułu równoważenia obciążenia Azure, aby rozdzielać połączenia z nieroutowalnej sieci wirtualnej typu spoke do urządzeń NVA. Wszystkie połączenia muszą używać protokołu SNAT niezależnie od portu docelowego, dlatego należy używać reguł równoważenia obciążenia o wysokiej dostępności, nazywanych również regułami równoważenia obciążenia dowolnego portu.

• Wybierz między konfiguracjami z jednym ramieniem i dwoma ramionami dla wirtualnych urządzeń sieciowych obsługujących translator adresów sieciowych. Konfiguracje pojedynczego ramienia są prostsze i ogólnie zalecane.

Na poniższym diagramie przedstawiono, jak zaimplementować SNAT w topologii sieci hub-and-spoke przy użyciu urządzeń wirtualnych innych niż Microsoft.

Ten diagram zawiera węzeł i dwa ramiona w oddzielnych strefach docelowych. Piasta zawiera trzy routowalne podsieci. Strefa lądowania A zawiera kontroler dostarczania aplikacji w routowalnej podsieci oraz dwa wystąpienia NAT również w routowalnej podsieci. Zawiera również interfejs HTTP, logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Kontroler dostarczania aplikacji wskazuje trzy elementy w podsieci HTTP frontend. Połączenie ze składnika przechodzi przez instancję NAT, a następnie zaporę w hubie przez SNAT. Sekcja strefy docelowej B zawiera interfejs TCP/IP w trasowalnej podsieci oraz dwa wystąpienia NAT w trasowalnej podsieci. Zawiera również logikę biznesową i warstwę danych w oddzielnych podsieciach niepodstawialnych. Połączenie ze składnika w podsieci logiki biznesowej przechodzi przez instancję NAT, a następnie przez zaporę w hubie za pośrednictwem SNAT. Piasta jest połączona z każdą szprychą strefy docelowej.

Pobierz plik programu PowerPoint tej architektury.

Używanie metody 1 z usługą Azure Virtual WAN

Usługa Azure Virtual WAN nie obsługuje peeringu podsieci. Nie można więc tworzyć wirtualnych sieci lądowania, które mają niemarszrutowalne podsieci w sieciach typu hub-and-spoke opartych na Virtual WAN. Jednak nadal można zastosować podstawową zasadę metody 1 przy użyciu dwóch równorzędnych sieci wirtualnych dla każdej strefy docelowej.

• Przypisz trasowalną przestrzeń adresową do pierwszej sieci wirtualnej i połącz ją z koncentratorem usługi Virtual WAN.

• Przypisz nienadawaną przestrzeń adresową do drugiej sieci wirtualnej i sparuj ją z routowalną siecią wirtualną.

Na poniższym diagramie przedstawiono wynikowa topologia.

Ten diagram zawiera wirtualny koncentrator sieci WAN i dwie strefy docelowe. Strefa docelowa A zawiera szprychę z możliwością routingu i szprychę bez możliwości routingu, które są połączone przez peering sieci wirtualnej. Szprycha routingowa zawiera kontroler dostarczania aplikacji w podsieci routingu. Nieroutowalna gałąź zawiera interfejs HTTP, logikę biznesową i warstwę danych w oddzielnych nieroutowalnych podsieciach. Kontroler dystrybucji aplikacji łączy się z trzema komponentami w podsieci czołówki HTTP. Strefa lądowania B zawiera szprychę strefy lądowania z routingu i szprychę strefy lądowania bez routingu, które są połączone za pośrednictwem połączenia sieci równorzędnej wirtualnej. Szprycha routowalna zawiera interfejs TCP/IP w routowalnej podsieci. Nieroutowalna gałąź zawiera logikę biznesową i warstwę danych w oddzielnych podsieciach niedostępnych dla routingu. Koncentrator usługi Virtual WAN jest połączony z każdą szprychą routingową strefy docelowej.

Pobierz plik programu PowerPoint tej architektury.

Takie podejście nie ogranicza łączności w strefie docelowej. Dwie sieci wirtualne w strefie docelowej są bezpośrednio powiązane (peering), dzięki czemu wszystkie zasoby mogą łączyć się ze sobą, niezależnie od tego, czy znajdują się w sieci wirtualnej z trasowaniem, czy bez trasowania. Jednak tylko zasoby w routowalnej sieci wirtualnej mogą łączyć się z zasobami poza strefą przyłączeniową.

Z perspektywy routingu nie ma różnicy między następującymi konfiguracjami:

• Trasowalne i nietrasowalne podsieci w tej samej sieci wirtualnej (opisane w poprzedniej sekcji w kontekście tradycyjnych sieci piasty i szprych)

• Bezpośrednio połączone sieci wirtualne (opisane w tej sekcji dla sieci piasty i szprych opartych na usłudze Virtual WAN)

W związku z tym w sieciach opartych na usłudze Virtual WAN obowiązują następujące wskazówki:

• Składniki aplikacji można dystrybuować między podsieciami routingu i nieroutowymi, korzystając z tych samych zagadnień opisanych we wcześniejszych sekcjach.

• Zależności wychodzące można zarządzać za pomocą NVAs obsługujących NAT w routowalnych podsieciach.

Metoda 2. Usługi Private Link

Usługa Private Link umożliwia klientom w sieci wirtualnej korzystanie z aplikacji w innej sieci wirtualnej bez konfigurowania łączności warstwy 3, takiej jak komunikacja równorzędna sieci wirtualnych lub sieć wirtualna-sieć VPN. Dwie sieci wirtualne mogą używać nakładających się zakresów adresów IP. Platforma Azure w sposób przezroczysty obsługuje wymaganą translację adresów sieciowych. Ta metoda dotyczy zarówno tradycyjnych sieci w modelu centrali i rozgałęzień, jak i sieci bazujących na Virtual WAN.

Aby uwidocznić aplikację za pomocą usługi Private Link, wykonaj następujące czynności:

1. Dodaj punkty dostępu aplikacji do puli zapleczowej wewnętrznego modułu równoważenia obciążenia platformy Azure przy użyciu SKU w wersji Standard.

2. Skojarz adres IP frontonu modułu równoważenia obciążenia z zasobem usługi Private Link.

3. Po stronie klienta utwórz zasób prywatnego punktu końcowego i skojarz go z usługą Private Link po stronie serwera.

Aby korzystać z aplikacji, klienci łączą się z prywatnym punktem końcowym. Platforma Azure w sposób niewidoczny kieruje połączenie do adresu IP frontendu modułu równoważenia obciążenia, który jest skojarzony z odpowiednią usługą Private Link.

Za pomocą usługi Private Link można ograniczyć wyczerpanie protokołu IPv4, przypisując dwie sieci wirtualne do każdej strefy docelowej:

• Sieć wirtualna, która ma routingową przestrzeń adresową połączoną z siecią firmową

• Izolowana sieć wirtualna, która ma dowolnie wybraną przestrzeń adresową, która może nawet nakładać się na przestrzeń adresową sieci firmowej

Wdróż aplikacje i usługi Private Link, które uwidaczniają swoje punkty końcowe w izolowanych sieciach wirtualnych. Wdróż prywatne punkty końcowe, które łączą się z tymi usługami, w routingowych sieciach wirtualnych.

Na poniższym diagramie przedstawiono dwie strefy docelowe korzystające z dużej przestrzeni adresowej , która nakłada się na przestrzeń 10.0.0.0/16adresową sieci firmowej. Każda strefa docelowa przypisuje to miejsce do izolowanej sieci wirtualnej. Aplikacje są wdrażane w odizolowanych sieciach wirtualnych szprych i skojarzone z usługami Private Link.

Diagram ten zawiera centrum i dwie strefy lądowania. Piasta zawiera trzy routowalne podsieci. Każda strefa lądowania zawiera połączoną szprychę routingu i izolowaną szprychę strefy lądowania. Szprycha routowalna zawiera podsieć prywatnych punktów końcowych i podsieć routowalną. Izolowany hub zawiera podsieć aplikacji i podsieć usługi Private Link, która łączy się z prywatnym punktem końcowym w routowalnym hubie. Podsieć aplikacji łączy się z podsiecią usługi Private Link. Koncentrator łączy się z każdą strefą docelową poprzez peering sieci wirtualnych.

Pobierz plik programu PowerPoint tej architektury.

Klienci w sieci firmowej, w tym klienci w innych strefach docelowych, używają aplikacji za pośrednictwem prywatnych punktów końcowych skojarzonych z usługami Private Link. Na poniższym diagramie przedstawiono sposób nawiązywania tych połączeń.

Diagram ten zawiera centrum i dwie strefy lądowania. Piasta zawiera trzy routowalne podsieci. Każda strefa lądowania zawiera połączoną szprychę routingu i izolowaną szprychę strefy lądowania. Szprycha routowalna zawiera podsieć prywatnych punktów końcowych i podsieć routowalną. Izolowany hub zawiera podsieć aplikacji i podsieć usługi Private Link, która łączy się z prywatnym punktem końcowym w routowalnym hubie. Podsieć aplikacji łączy się z podsiecią usługi Private Link. Koncentrator łączy się z każdą strefą docelową poprzez peering sieci wirtualnych. Istnieją dwa przepływy. Jeden przepływ przechodzi z podsieci routingu w strefie docelowej A, do zapory w podsieci routingu w centrum, do podsieci prywatnego punktu końcowego w strefie docelowej B, do podsieci usługi Private Link w strefie docelowej B, a na koniec do podsieci aplikacji w strefie docelowej B. Drugi przepływ przechodzi z podsieci routingu H3 w centrum, do podsieci prywatnego punktu końcowego w strefie docelowej A, do podsieci usługi Private Link w strefie docelowej A, a na koniec do podsieci aplikacji w strefie docelowej A.

Pobierz plik programu PowerPoint tej architektury.

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

Aplikacje w izolowanych sieciach wirtualnych nie mogą inicjować połączeń z punktami końcowymi w sieci firmowej. Dlatego metoda 2 działa najlepiej w scenariuszach, w których aplikacje w różnych strefach docelowych działają niezależnie i nie korzystają z systemów w sieci firmowej. Jednak nadal można zastosować tę metodę, gdy aplikacje w izolowanych sieciach wirtualnych muszą uzyskiwać dostęp do określonych punktów końcowych poza ich strefą docelową.

Na poniższym diagramie pokazano, jak usługa Private Link umożliwia aplikacji w izolowanej sieci wirtualnej w strefie docelowej A korzystanie zarówno z usługi udostępnionej w sieci wirtualnej centrum, jak i punktu końcowego aplikacji w strefie docelowej B.

Diagram ten zawiera centrum i dwie strefy lądowania. Piasta zawiera dwie routowalne podsieci, podsieć usługi udostępnionej i podsieć usługi Private Link. Podsieć usługi udostępnionej łączy się z podsiecią usługi Private Link. Każda strefa lądowania zawiera połączoną szprychę routingu i izolowaną szprychę strefy lądowania. Szprycha routowalna zawiera podsieć prywatnych punktów końcowych i podsieć routowalną. Izolowany węzeł w strefie docelowej A zawiera podsieć aplikacji, podsieć usługową Private Link, która łączy się z prywatnym punktem końcowym we węźle routowalnym, oraz inną podsieć prywatnego punktu końcowego. Podsieć aplikacji łączy się z każdym prywatnym punktem końcowym w podsieci prywatnego punktu końcowego. Jeden prywatny punkt końcowy (oznaczony etykietą 1) łączy się z podsiecią usługi Private Link w centrum. Inny prywatny punkt końcowy (oznaczony etykietą 2) łączy się z podsiecią usługi Private Link w strefie docelowej B. Izolowana szprycha w strefie docelowej B zawiera podsieć usługi Private Link i podsieć aplikacji. Każda podsieć aplikacji łączy się z podsiecią usługi Private Link w tej samej strefie docelowej. Piasta łączy się z każdą routowalną szprychą strefy lądowania.

Pobierz plik programu PowerPoint tej architektury.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

• Federico Guerrini | Starszy architekt rozwiązań w chmurze, główny dyrektor techniczny ds. sieci platformy Azure w regionie EMEA
• Khush Kaviraj | Architekt rozwiązań w chmurze
• Jack Tracey | Starszy architekt rozwiązań w chmurze

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

Dalsze kroki

• Konfigurowanie równoległej podsieci
• 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
• Azure Load Balancer
• Peering sieci wirtualnych
• Topologia sieci piasty i szprych

Powiązane zasoby

• Projektowanie architektury sieci
• Metody architektury dla sieci w rozwiązaniach wielodostępnych