Dlaczego Azure Point-to-Site VPN nie zmienia twojego publicznego IP

Podłączam klienta Azure VPN na laptopie z Windows, otwieram stronę echa adresu i widzę ten sam publiczny adres, który przydzielił mój domowy router. W tym czasie host przeskoku pod 10.20.0.4 odpowiada, a nazwa prywatnego punktu końcowego się rozwiązuje, więc tunel nie jest zepsuty. Brama point-to-site robi dokładnie to, co mówi jej domyślna konfiguracja: przenosi prefiksy prywatne, a wszystko inne zostawia na łączu lokalnym. Uzyskanie adresu wyjściowego należącego do Azure to zmiana projektu routingu, nie naprawa.

Co brama ogłasza domyślnie

Brama wypycha trasy dla przestrzeni adresowej sieci wirtualnej oraz sieci równorzędnych, w których dozwolony jest tranzyt bramy, a także prefiksy lokalne poznane przez połączenie site-to-site lub BGP. W tym zestawie nie ma 0.0.0.0/0. System operacyjny trzyma trasę domyślną na Wi-Fi lub Ethernet, więc pakiet do publicznego API nigdy nie wchodzi do tunelu.

Adres, który klient otrzymuje w tunelu, to prywatna dzierżawa z puli point-to-site. Identyfikuje klienta wobec zasobów w VNet; nie jest adresem, który może zobaczyć internet, i nigdy nie pojawi się jako źródło wychodzącego żądania do API SaaS. Wpis na liście dozwolonych zbudowany wokół tej dzierżawy nie może działać, niezależnie od tego, jak długo czekasz, aż pojawi się w logach dostawcy.

Tunel dzielony i tunel wymuszony obok siebie

Tylko drugi wiersz zmienia adres, który widzi usługa zdalna. Wszystko inne w tej tabeli to koszt i powierzchnia operacyjna, którą akceptujesz, gdy wyjście musi być sprawdzone lub przetłumaczone wewnątrz Azure. Jeśli ktoś prosi cię o zmianę publicznego IP, prosi o całą prawą kolumnę, a nie o drobną korektę w kliencie.

Jest opcja pośrednia, którą warto nazwać, zanim cokolwiek przebudujesz. Maszyna wirtualna proxy lub bramy w VNet daje ci kontrolowany adres źródłowy dla aplikacji, które można na nią skierować, bez przesuwania trasy domyślnej klienta. To zostawia zwykłe przeglądanie lokalnie i nadal zadowala partnera, który potrzebuje tylko jednego wywołania API z Azure. Zawodzi, gdy wymóg naprawdę dotyczy całego ruchu, bo wszystko, co ignoruje ustawienie proxy, i tak wychodzi lokalnie.

Spraw, by tunel przenosił trasę domyślną

Na bramie sieci wirtualnej obsługiwanym sposobem skierowania całego ruchu internetowego klienta do tunelu jest dodanie tras niestandardowych do konfiguracji point-to-site. Dwie połowy pokrywają całą przestrzeń IPv4, a każda jest bardziej szczegółowa niż lokalna trasa domyślna, więc klient preferuje je bez usuwania czegokolwiek:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Ten wiersz jest ilustracyjny, a nie kompletny do skopiowania: najpierw pobierz obiekt bramy poleceniem Get-AzVirtualNetworkGateway i podstaw go za GWOBJ, a przed uruchomieniem potwierdź, że SKU i model wdrożenia akceptują trasy niestandardowe. Te same prefiksy pojawiają się w portalu na stronie konfiguracji point-to-site, która jest bezpieczniejszym miejscem ich ustawienia, jeśli jeszcze nie skryptujesz bramy.

Zmiana tych prefiksów unieważnia pakiet klienta. Pobierz ponownie pakiet klienta VPN i zainstaluj go od nowa, ponieważ trasy podróżują wewnątrz profilu. Klient, który połączy się ponownie ze starym profilem, zachowa stary zestaw tras, a ty możesz stracić godzinę na debugowanie zmiany, która do niego nigdy nie dotarła.

W zabezpieczonym centrum wirtualnej sieci WAN odpowiednikiem jest trasa domyślna w tabeli tras centrum powiązanej z bramą point-to-site, a ruch przejmuje Azure Firewall w centrum. Zapora tłumaczy połączenia wychodzące do internetu na własne publiczne adresy IP, i z tego tłumaczenia pochodzi nowy adres wyjściowy. Gdy zapora ma kilka publicznych adresów IP, każdy z nich może pojawić się jako źródło, więc lista dozwolonych musi zawierać wszystkie.

Oba powyższe projekty są IPv4. Dwa prefiksy /1 nic nie robią dla IPv6, a obsługa IPv6 w point-to-site jest tak wąska, że kombinację należy przetestować, zanim obiecasz parytet.

Sprawdź trasę, potem wyjście

Po ponownej instalacji pakietu i ponownym połączeniu potwierdź, że klient naprawdę zainstalował połówki. W systemie Windows Get-NetRoute -DestinationPrefix 0.0.0.0/1 i to samo zapytanie dla 128.0.0.0/1 powinny wskazać interfejs tunelu, a route print pokazuje oba obok twojej pierwotnej trasy domyślnej. W systemie Linux ip route show musi wymienić dwa prefiksy; jeśli tego nie robi, profil nigdy ich nie przenosił.

Następnie sprawdź ponownie publiczny adres z klienta i przeczytaj log zapory dla tego samego połączenia. Źródłem powinien być publiczny adres IP zapory z przetłumaczonym portem. Klient, który nadal wychodzi lokalnie, choć istnieją obie trasy, oznacza, że pakiety dotarły do Azure i wyszły inną drogą: trasą zdefiniowaną przez użytkownika w podsieci bramy, zaporą, która sama jest wymuszenie tunelowana do sieci lokalnej, albo zasadą, która odrzuca przepływ przed tłumaczeniem.

Przetestuj ponownie jeden cel prywatny w tej samej sesji. Host przeskoku, który przestaje odpowiadać po zmianie, to zwykły znak, że nowe prefiksy coś wypchnęły: albo węższą trasę lokalną, która wcześniej była ogłaszana, albo rozwiązywanie nazw, które teraz idzie do resolwera bez przekazywania dla twoich stref prywatnych.

Kiedy zostawić tunel dzielony w spokoju

Jeśli celem jest tylko dotarcie do prywatnego API, prywatnego punktu końcowego lub wewnętrznej strony administracyjnej, domyślne zachowanie jest tańsze i cichsze. Wymuszony tunel dodaje godziny zapory i opłaty za przetwarzanie danych, dłuższą drogę i jeszcze jedno miejsce, w którym każdy przepływ klienta może zawieść. Przechwytuje też znacznie więcej ruchu niż ten jeden cel, na którym ci zależało.

Sięgnij po niego, gdy wymóg jest sformułowany w kategoriach wyjścia: partner musi widzieć stały adres Azure, bezpieczeństwo chce, aby połączenia były logowane i sprawdzane, albo dane muszą wychodzić przez jeden kontrolowany punkt. Nawet wtedy projekt daje każdemu użytkownikowi wspólne wyjście, więc odpowiedzialność za użytkownika musi pochodzić z tożsamości w aplikacji, a nie z adresu źródłowego.

Przed zamknięciem zmiany potwierdź cztery rzeczy: zainstalowany pakiet klienta jest nowy, dwie trasy /1 znajdują się na interfejsie tunelu, cel prywatny nadal odpowiada, a log usługi zdalnej pokazuje adres zapory.