Równorzędne połączenia sieci VNet i punkty końcowe usług

Zasoby znajdujące się w różnych sieciach Azure VNet nie mogą domyślnie komunikować się ze sobą — nawet jeśli znajdują się w tym samym regionie Azure. Duże organizacje często mają jednak wiele sieci VNet: oddzielne sieci VNet na potrzeby programowania, testów i produkcji albo różne sieci VNet dla poszczególnych działów. VNet Peering łączy dwie sieci VNet bezpośrednio za pośrednictwem prywatnej sieci szkieletowej firmy Microsoft, umożliwiając zasobom w obu sieciach VNet komunikację tak, jakby znajdowały się w tej samej sieci — bez przesyłania ruchu przez publiczny internet i bez konieczności używania bramy VPN.

VNet Peering to połączenie nietranzytywne: jeśli VNet A ma peering z VNet B, a VNet B ma peering z VNet C, VNet A nie może komunikować się z VNet C, dopóki nie zostanie utworzony oddzielny peering między A i C. Łącza peering są dwukierunkowe, ale trzeba je skonfigurować po obu stronach — utworzenie peeringu z A do B nie powoduje automatycznego utworzenia peeringu z B do A. Po skonfigurowaniu obu stron ruch między połączonymi sieciami VNet korzysta z sieci szkieletowej Azure, zapewniając małe opóźnienia i dużą przepustowość porównywalne z komunikacją między podsieciami w ramach jednej sieci VNet.

VNet Peering ma dwa zakresy działania: Local VNet Peering łączy dwa VNet-y w tym samym regionie Azure. Ruch pozostaje w obrębie regionu i wiąże się z niewielką opłatą za transfer każdego GB. Global VNet Peering łączy dwa VNet-y w różnych regionach Azure, a ruch jest kierowany przez globalną sieć szkieletową firmy Microsoft. Dzięki temu zasoby w regionie East US mogą komunikować się prywatnie z zasobami w regionie West Europe bez przechodzenia przez publiczny internet. Peering globalny wiąże się z nieco wyższym kosztem transferu niż peering lokalny, ale nadal jest znacznie tańszy i bardziej niezawodny niż kierowanie ruchu przez VPN.

Popularny wzorzec stosowany w przedsiębiorstwach wykorzystuje VNet Peering do implementacji topologii hub-and-spoke. Centralny VNet typu hub udostępnia współdzielone usługi: Azure Firewall, VPN Gateway, serwery DNS i monitorowanie. Wiele VNet-ów typu spoke (po jednym dla każdego środowiska lub obciążenia) nawiązuje peering z hubem. Kierowanie całego ruchu ze spoke przez firewall w hubie pozwala centralnie kontrolować bezpieczeństwo bez konieczności złożonego zarządzania regułami NSG w każdym spoke. Ponieważ peering nie jest tranzytywny, firewall w hubie kieruje ruch między spoke za pomocą User-Defined Routes (UDRs).

VNet Peering ma jedno kluczowe wymaganie: przestrzenie adresowe VNet-ów objętych peeringiem nie mogą się nakładać. Jeśli VNet A używa zakresu 10.0.0.0/16, a VNet B również używa zakresu 10.0.0.0/16, peering kończy się niepowodzeniem, ponieważ Azure nie może kierować ruchu między identycznymi zakresami adresów. Dlatego tak ważne jest zaplanowanie niepokrywających się zakresów CIDR dla wszystkich VNet-ów — a także dla sieci lokalnych — jeszcze przed rozpoczęciem pracy. Zmiana przestrzeni adresowej VNet-u po wdrożeniu zasobów wymaga ponownego utworzenia VNet-u albo użycia (ograniczonej) funkcji dodawania i usuwania przestrzeni adresowej.

Service Endpoints rozszerzają tożsamość VNet-u na usługi Azure PaaS, takie jak Azure Storage, Azure SQL Database, Azure Key Vault i Cosmos DB. Po włączeniu punktu końcowego usługi w podsieci ruch z zasobów w tej podsieci do określonej usługi Azure jest kierowany przez sieć szkieletową Azure, a nie przez publiczny internet — nawet jeśli używany jest publiczny adres IP usługi. Usługa może następnie ograniczyć dostęp wyłącznie do zasobów znajdujących się w VNet-ach, w których włączono dany punkt końcowy usługi, co zapewnia znacznie wyższy poziom bezpieczeństwa niż punkty końcowe dostępne z internetu.

Service Endpoints i Private Endpoints zapewniają bezpieczny dostęp do usług Azure PaaS, ale działają w różny sposób: Service Endpoint — kieruje ruch przez sieć szkieletową Azure, ale nadal używa publicznego adresu IP usługi; punkt końcowy usługi istnieje na poziomie podsieci. Private Endpoint — przypisuje usłudze prywatny adres IP z VNet-u; publiczny punkt końcowy można całkowicie wyłączyć, dzięki czemu usługa staje się rzeczywiście prywatna. Z prywatnych punktów końcowych można także korzystać z sieci lokalnej przez VPN/ExpressRoute, a ponadto zapewniają one silniejszą izolację. W przypadku najwyższych wymagań bezpieczeństwa preferowane są Private Endpoints; Service Endpoints stanowią prostszą i tańszą alternatywę.

Po włączeniu punktu końcowego usługi w podsieci należy skonfigurować usługę Azure tak, aby akceptowała połączenia wyłącznie z tej podsieci. W przypadku konta magazynu oznacza to dodanie reguły VNet w ustawieniach zapory konta magazynu. Po tej zmianie tylko maszyny wirtualne z określonej podsieci mogą uzyskać dostęp do konta magazynu — cały pozostały ruch z internetu jest odrzucany. To szybki i bezpłatny sposób na znaczne zwiększenie bezpieczeństwa konta magazynu w porównaniu z pozostawieniem go otwartego na cały ruch internetowy, szczególnie w przypadku kont przechowujących wrażliwe dane aplikacji.

VNet Integration (różna od VNet Peering) umożliwia aplikacjom Azure App Service wykonywanie połączeń wychodzących z zasobami znajdującymi się w VNet. Bez VNet Integration ruch wychodzący z App Service zawsze opuszcza sieć przez publiczny internet — nawet gdy aplikacja łączy się z zasobami takimi jak Azure SQL lub Azure Cache for Redis w tym samym VNet. Po włączeniu VNet Integration ruch wychodzący aplikacji jest kierowany do VNet-u i może docierać do prywatnych zasobów. Wymaga to dedykowanej delegowanej podsieci w VNet, dysponującej przestrzenią adresową co najmniej /28.

Ponieważ VNet Peering nie jest tranzytywny, połączenie więcej niż dwóch VNet-ów wymaga bezpośredniego peeringu między każdą parą (złożoność O(n²)) albo użycia centralnego huba routingu. W modelu hub-and-spoke VNet hub zawiera Network Virtual Appliance (NVA) lub Azure Firewall, który działa jako router tranzytowy między VNet-ami spoke. Każdy spoke dodaje UDR kierującą cały ruch (0.0.0.0/0 lub ruch do określonych zakresów CIDR spoke) do adresu IP NVA w hubie. NVA przekazuje następnie ruch do właściwego docelowego spoke, zapewniając w praktyce tranzytywną łączność przez hub.

Najważniejsze ograniczenia VNet Peering: Wymagane są niepokrywające się przestrzenie adresowe — zakresy CIDR należy starannie zaplanować przed utworzeniem VNet-ów. Brak tranzytywności — peering A-B i B-C nie zapewnia połączenia A-C. Nie można zmienić rozmiaru przestrzeni adresowej VNet-u, jeśli ma on aktywne połączenia peering, bez ich tymczasowego usunięcia. Gateway transit — VNet-y spoke mogą korzystać z bramy VPN lub ExpressRoute w VNet hub, jeśli w konfiguracji peeringu zostanie włączona opcja „Use Remote Gateways”, ale wymaga to wcześniejszego utworzenia bramy w hubie. Zrozumienie tych ograniczeń jest ważne podczas projektowania skalowalnych i łatwych w utrzymaniu architektur obejmujących wiele VNet-ów.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omawianych w tej lekcji.

W tej lekcji dowiedział się Pan / dowiedziała się Pani, że: VNet Peering łączy dwa VNet-y za pośrednictwem sieci szkieletowej firmy Microsoft, zapewniając prywatną komunikację o małych opóźnieniach bez VPN, ale peering nie jest tranzytywny, punkty końcowe usługi kierują ruch z podsieci do usług Azure PaaS przez sieć szkieletową, nie udostępniając ich publicznemu internetowi, a prywatne punkty końcowe są bezpieczniejszą alternatywą — przypisują usłudze PaaS prywatny adres IP, dzięki czemu publiczny punkt końcowy można całkowicie wyłączyć. W następnej części omówimy podstawy Azure DNS i Load Balancer.