Peering w Azure czy VPN z VNet do VNet? Zdecyduj przed routingiem

Azure daje co najmniej dwa sposoby połączenia dwóch sieci wirtualnych i nie są to wymienne ustawienia tego samego obiektu. Peering łączy VNet-y w szkielecie Microsoftu bez bramy; VPN z VNet do VNet umieszcza relację IPsec między dwiema bramami, które wdrażasz, dobierasz pod względem rozmiaru i monitorujesz. Decyzja sprowadza się do trzech warunków, a jeśli nie potrafisz odpowiedzieć na wszystkie trzy przed dodaniem trasy, właśnie budujesz obejście dla modelu, którego nigdy nie wybrałeś.

Trzy warunki, które decydują o modelu

Pierwszy to, czy cokolwiek w wymaganiu potrzebuje granicy IPsec, która należy do Ciebie i na którą możesz wskazać. Drugi to, czy przestrzenie adresowe są czyste i czy dwa VNet-y mają tylko ze sobą rozmawiać. Trzeci to, kto jest właścicielem dowolnej ścieżki tranzytowej i rachunku za bramę. Odpowiadaj w tej kolejności, bo pierwszy może wyeliminować peering, niezależnie od tego, jak atrakcyjnie wygląda drugi.

Wspólna dla obu modeli jest twarda zasada adresowania: przestrzenie adresowe VNet-ów nie mogą się nakładać. Ani peering, ani VPN z VNet do VNet nie są obsługiwanym sposobem na jednoznaczne rozdzielenie dwóch identycznych zakresów, a nakładanie wymaga projektu mapowania lub przeprojektowania, a nie innego typu połączenia.

Warunek 1: czy potrzebujesz granicy IPsec, która należy do Ciebie?

Peering przenosi ruch po prywatnym szkielecie Azure i nie wymaga bramy VPN dla samego połączenia peered. To stwierdzenie o transporcie, a nie stwierdzenie o szyfrowaniu, które możesz przekazać audytorowi jako «uruchamiamy IPsec». Jeśli wymaganie wskazuje tunel konfigurowany przez klienta, konkretną politykę IKE albo granicę kończącą się na sprzęcie, który kontrolujesz, peering tego nie spełnia, niezależnie od tego, jak prywatny jest szkielet.

VPN z VNet do VNet zapewnia tę granicę: dwie bramy, relację IPsec/IKE, współdzielone klucze i całą powierzchnię operacyjną, która z tym idzie. Dziedziczysz stan tunelu, pojemność bramy, limity SKU i monitoring, który dowodzi, że tunel działa. To właściwa odpowiedź, gdy wymaganie dotyczy właśnie tej granicy, opisanej w przeglądzie peeringu jako odrębny typ połączenia.

Bądź równie ostrożny w drugą stronę. «Potrzebujemy szyfrowania między VNet-ami» często spełnia własny TLS obciążenia, a wtedy brama jest kosztem bez wymagania za nim. Napisz zdanie, które przeczyta audytor, zanim wybierzesz mechanizm.

Warunek 2: czy topologia jest bezpośrednia, czy coś musi tranzytować?

Peering nie jest tranzytywny. Dwa VNet-y peered do koncentratora nie są przez to połączone ze sobą, a trasa, która wygląda na działającą w jednym kierunku, to zwykle peering, który osiągnął Connected tylko po jednej stronie. Obie strony muszą istnieć i obie muszą pokazywać Connected, i to jest pierwsza rzecz, którą sprawdzasz, gdy ruch cicho znika.

Jeśli wymaganiem jest dostęp do sieci lokalnej przez koncentrator, tranzyt bramy jest osobnym projektem o konkretnych rolach: koncentrator posiada bramę, peering spoke'a pozwala na tranzyt bramy, a spoke musi pozwalać na ruch przekazywany. To właściwości peeringu, a nie automatyczne skutki połączenia VNet-ów:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Efektywna tabela tras jest uczciwą odpowiedzią na «czy ścieżka istnieje?». Pokazuje typ następnego przeskoku, którego platforma naprawdę użyje, więc peering, który wygląda na skonfigurowany, ale nie jest połączony, pojawia się jako brakująca lub błędna trasa, a nie jako zagadka.

Warunek 3: kto jest właścicielem ścieżki tranzytowej i rachunku?

Każdy dodatkowy przeskok ma właściciela. Przy peeringu nowy VNet oznacza nową parę peeringów po obu stronach, a dla tranzytu koncentrator, który dalej przekazuje ruch, oraz tabelę tras, która dalej na niego wskazuje. Przy VPN nowy VNet oznacza kolejną bramę lub kolejne połączenie na istniejącej, z własnym pułapem pojemności do pilnowania.

Koszt podąża za tym samym kształtem, ale nie za tymi samymi pozycjami: opłaty za peering to połączenie i transfer danych, a VPN dodaje godziny bramy i własne opłaty za transfer. Porównaj sumę dla topologii, którą naprawdę będziesz utrzymywać przez rok, łącznie z drugim tunelem i monitoringiem, a nie cenę jednego połączenia dzisiaj. Wlicz pracę, której nikt nie fakturowuje: ktoś musi rotować klucze, pilnować stanu tunelu i odpowiadać na alert o trzeciej w nocy, gdy brama się restartuje. Zwykle właśnie ta pozycja rozstrzyga spór, bo jest jedyną, która nigdy nie pojawia się w ofercie.

Cokolwiek wybierzesz, przetestuj trzy przepływy: zamierzony, odrzucony, który ma pozostać odrzucony, oraz przypadek odzyskania, gdy brama koncentratora lub peering nie działa. Model, który wyjaśnia tylko szczęśliwą ścieżkę, nie został zweryfikowany, został zademonstrowany.

Zweryfikuj wybór wobec jego własnego twierdzenia

Napisz jedno zdanie, które nazywa model, granicę i właściciela, a potem sprawdź, czy wdrożony stan mu odpowiada. Dla peeringu oznacza to oba stany peeringu Connected, efektywną trasę pokazującą następny przeskok peeringu dla prefiksu docelowego i brak bramy na ścieżce. Dla VPN z VNet do VNet oznacza to oba połączenia Connected, zgodne klucze i zasady na obu bramach oraz trasę, której następnym przeskokiem jest brama sieci wirtualnej.

Jeśli kontrole przeczą zdaniu, najpierw popraw zdanie. Większość zamieszania w tych projektach bierze się z hybrydy, której nikt nie opisał: peering dla podsieci obciążenia, VPN dla jednej starej usługi i tabela tras, która po cichu preferuje jedną z nich.