Prywatny IP VPN Azure przez ExpressRoute bez NVA

Mit głosi, że szyfrowanie ruchu przez prywatny peering ExpressRoute wymaga wirtualnego urządzenia sieciowego. Nie wymaga. Azure obsługuje Site-to-Site VPN Gateway, którego punkt końcowy tunelu jest prywatnym adresem RFC1918 przenoszonym przez obwód, a urządzenie jest opcjonalne, nie strukturalne. To, co mit o urządzeniu ukrywa, to część, która naprawdę boli: włączenie prywatnego punktu końcowego na jednym obiekcie zamiast dwóch i pozwolenie, by bezpośrednia trasa peeringu po cichu wygrała z zaszyfrowaną ścieżką.

Skąd wziął się mit

Twierdzenie ma szacowny rodowód. Przez lata praktyczną receptą na IPsec przez prywatny peering była NVA, ponieważ zarządzana brama udostępniała tylko publiczne punkty końcowe. To się zmieniło, a odpowiedzi napisane przed zmianą są wciąż cytowane w wątkach, w których nikt nie sprawdza daty. Poprawka jest wąska: brama VPN z prywatnym adresem istnieje i zmienia punkt końcowy, a nie logikę routingu wokół niego.

Nic z tego nie wysyła NVA na emeryturę. Wysyła na emeryturę założenie, że urządzenie jest jedyną drogą do wymagania.

Włącz prywatny punkt końcowy na obu poziomach

Zacznij od działającego połączenia prywatnego peeringu ExpressRoute powiązanego z VNet, w którym znajduje się brama VPN. Strona lokalna musi już docierać do odpowiednich prywatnych adresów przez ten obwód, ponieważ tunel użyje tych adresów jako transportu. Potem warunek wstępny bramy: procedura Microsoft dla VPN z prywatnym IP wymaga bramy zbudowanej na zasobie publicznego IP w warstwie Standard. Prywatne adresowanie tunelu nie usuwa tego wymogu, co zaskakuje osoby zakładające, że „prywatny” oznacza „nigdzie publicznego IP”.

Teraz włącz flagę w obu miejscach. Konfiguracja bramy ma własny przełącznik dla prywatnych IP, a pojedyncze połączenie Site-to-Site ma drugi, który każe temu połączeniu używać prywatnego adresu. Ustawienie jednego bez drugiego to najczęstsza niepełna konfiguracja; tunel albo się nie zestawia, albo zestawia się z niewłaściwym punktem końcowym.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Sprawdź nazwy właściwości względem zainstalowanej wersji CLI, ponieważ etykiety portalu i właściwości CLI nie zawsze mają to samo brzmienie. Brama aktywna-aktywna udostępnia dwa prywatne adresy tunelu, a urządzenie lokalne potrzebuje skonfigurowanych obu partnerów, jeśli ta redundancja ma coś znaczyć. BGP nie jest wymagany tylko po to, by podnieść ten tunel z prywatnym adresem, choć zwykle jest częścią sposobu dystrybucji prefiksów.

Drugi mit: zestawiony tunel szyfruje Twój ruch

Dwie ścieżki docierają teraz do sieci aplikacji: bezpośrednia ścieżka prywatnego peeringu i ścieżka przez VPN. Obie działają. Tylko jedna stosuje tę warstwę IPsec. Microsoft dokumentuje, że gdy identyczne prefiksy są ogłaszane przez ExpressRoute i przez VPN, Azure preferuje bezpośrednią ścieżkę ExpressRoute, więc zdrowy tunel ze zdrowymi licznikami niczego nie dowodzi co do tego, gdzie poszły pakiety aplikacji.

Udokumentowane metody sterowania to zakres obejmujący na ExpressRoute i bardziej szczegółowy zakres chroniony na VPN albo rozłączne prefiksy na obu ścieżkach. Na przykład prywatny peering może przenosić 10.40.0.0/16, a VPN ogłasza 10.40.12.0/24. Bardziej szczegółowy prefiks wygrywa, a reszta zakresu pozostaje bezpośrednia.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Wykonaj tę samą kontrolę w kierunku lokalnym, ponieważ preferencja routera decyduje, którędy wychodzi ruch wychodzący. I trzymaj własny transport tunelu na ścieżce ExpressRoute; trasa, która wciąga prywatny punkt końcowy bramy do tunelu, czyni tunel zależnym od samego siebie.

Zdecyduj, co się stanie, gdy tunel padnie

Bardziej szczegółowa trasa VPN znika, gdy tunel padnie, a szersza trasa bezpośrednia pozostaje. Ruch płynie wtedy bez szyfrowania i wszystko wygląda zdrowo, co jest najgorszym trybem awarii dla wymagania, które istnieje po to, by gwarantować szyfrowanie. Jeśli wymaganie zabrania takiego obejścia, routing i polityka dostępu muszą to powiedzieć wprost, zamiast polegać na dostępności tunelu.

Zapisz, które prefiksy mogą pozostać bezpośrednio osiągalne, a które muszą się zatrzymać, gdy brak zaszyfrowanej ścieżki. Następnie przetestuj dozwolony przypadek prawdziwym ruchem i porównaj liczniki połączenia, ponieważ sama tabela tras nie powie Ci, czy wymóg szyfrowania nadal obowiązuje.

Ta rama pozwala też ocenić NVA według jego rzeczywistych funkcji, takich jak wiele tuneli, przepustowość czy inspekcja dostawcy, zamiast kupować go dlatego, że punkt końcowy jest prywatny.