Czy Azure VNet połączony peeringiem potrzebuje własnej bramy VPN?
VNet połączony peeringiem może korzystać z bramy VPN huba z obsługiwanym SKU i jednym ustawieniem w każdym kierunku peeringu. Weryfikuj skuteczne trasy, a nie stan peeringu.
Pojawia się nowy spoke VNet, hub ma już działającą bramę site-to-site, a oczywiste pytanie brzmi, czy trzeba płacić za drugą bramę. Zwykle nie: tranzyt bramy pozwala spoke'owi używać bramy huba przez peering. O tym, czy to zadziała, decydują trzy warunki i żadnego z nich nie widać na plakietce stanu peeringu. Łączność peeringu i uprawnienie do korzystania z cudzej bramy to osobne ustawienia, więc dwa VM, które już się pingują, niczego nie dowodzą w kwestii ścieżki VPN.
Pierwszy warunek: brama i brak własnej w spoke
Azure obsługuje tranzyt bramy dla SKU VPN Gateway innych niż Basic, a unieść go może zarówno peering regionalny, jak i globalny. Spoke zużywa bramę, której nie posiada, więc nie może mieć własnej: jeśli w spoke już istnieje brama albo wybrano już opcję bramy zdalnej, żądane ustawienie tranzytu będzie niedostępne lub nieskuteczne. Sprawdź to, zanim zaczniesz cokolwiek debugować, ponieważ wyłączone pole wyboru jest objawem, a nie usterką. Najpierw przeczytaj SKU i istniejącą bramę, a potem zajrzyj do ustawień peeringu.
Nie usuwaj istniejącej bramy spoke, aby opcja się pojawiła, dopóki nie wiesz, co od niej zależy. Kolejność migracji jest ważniejsza niż pole wyboru.
Drugi warunek: jedno ustawienie w każdym kierunku peeringu
Peering to dwa obiekty, po jednym na każdym VNet, a ustawienia tranzytu żyją po różnych stronach tej pary. Peering huba w stronę spoke musi pozwalać bramie huba obsługiwać spoke; peering spoke w stronę huba musi akceptować bramę huba. Przewodnik Microsoftu po tranzyt bramy nazywa je według kierunku i to jedyny sposób, by utrzymać je prawidłowo:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Kontrolka oznaczona jako remote zmienia znaczenie w zależności od tego, którego peeringu VNet edytujesz, więc czytaj kierunek, a nie słowo. Ustaw obie strony, zapisz i potwierdź, że peering zgłasza połączenie w obu miejscach.
Trzeci warunek: przestrzeń adresowa i granice uprawnień
Tranzyt nie może sprawić, by ten sam prefiks docelowy oznaczał dwie sieci, więc zakresy huba, spoke i sieci lokalnej muszą być rozłączne, zanim cokolwiek z tego zadziała. VNety mogą też znajdować się w różnych subskrypcjach lub różnych dzierżawcach; to nie jest zakaz, ale tożsamość tworząca lub aktualizująca każdy peering potrzebuje wymaganych uprawnień w tej sieci. Zmiany między subskrypcjami często kończą się niepowodzeniem z powodu uprawnień, a błąd łatwo błędnie odczytać jako problem topologii.
Zapisz zakresy i właścicieli przed zmianą. Zgadywanie któregokolwiek z nich daje peering, który się łączy i niczego nie routuje.
Weryfikuj skutecznymi trasami, a nie stanem peeringu
Spójrz na skuteczne trasy na interfejsie sieciowym obciążenia spoke i znajdź rzeczywisty prefiks sieci lokalnej. Sprawdź tabelę tras podsieci i czy propagacja tras bramy jest wyłączona, ponieważ trasa zdefiniowana przez użytkownika lub urządzenie inspekcyjne może nadpisać ścieżkę sugerowaną przez flagi peeringu. Następnie potwierdź drugi kierunek: sieć lokalna musi wiedzieć, jak dotrzeć do prefiksu spoke przez połączenie site-to-site, czy to przez wyuczone komunikaty, czy przez jawną trasę i pasujący wpis chronionej sieci na urządzeniu klienta. Jeśli prefiksu brakuje po którejkolwiek stronie, flagi peeringu nie są tym, co trzeba zmienić.
Przetestuj jedną usługę z obciążenia spoke i śledź odpowiedź. Test z bramy VPN lub z VM huba ćwiczy inny prefiks źródłowy i inną ścieżkę.
Jeśli topologia obsługuje też klientów point-to-site, zweryfikuj osobno ich zainstalowane trasy. Pakiety klienta Windows mogą wymagać ponownego wygenerowania po zmianie topologii, i to jest zadanie routingu po stronie klienta, a nie dowód, że współdzielenie bramy zawiodło.
Czego współdzielenie bramy nie daje
Tranzyt bramy to udogodnienie routingu, nie autoryzacja. Grupy zabezpieczeń sieci, filtry lokalne i reguły na poziomie usługi nadal decydują, do czego obciążenie spoke może dotrzeć, więc włącz konkretną usługę od źródła do celu, zamiast zakładać, że współdzielony tunel pozwala na wszystko za nim.
Peering nie jest też tranzytywny tak, jak ludzie mają nadzieję. Dodanie kolejnego spoke'a lub prywatnego punktu końcowego wprowadza własne wymagania dotyczące routingu i dostępu, których istniejące ustawienie tranzytu nie obejmuje.