Statyczny IP w Azure P2S VPN: dlaczego zmienia się adres klienta

Każdy klient Azure point-to-site otrzymuje adres z puli podczas uwierzytelniania i zachowuje go tylko na czas trwania tego połączenia. Nie ma tabeli rezerwacji, mapowania na użytkownika ani ustawienia bramy, które znaczyłoby „zawsze dawaj tej osobie 172.16.0.10”. Właśnie ten jeden mechanizm wyjaśnia oba objawy, na które ludzie trafiają później: regułę NSG, która przestaje pasować do użytkownika, do którego wcześniej pasowała, oraz listę dozwolonych, która po cichu wpuszcza maszynę, której nikt celowo nie dodał. Zastąpienie reguły sprytniejszą regułą IP nie naprawia żadnego z nich, bo to, co reguła nazywa, jest przydzielane ponownie według harmonogramu, którego nie kontrolujesz.

Pula to pojemność, nie tożsamość. Istnieje po to, by równoczesne tunele dostawały unikalne adresy, i odzyskuje je w chwili wygaśnięcia dzierżawy. Gdy to jest jasne, użyteczne pytanie przestaje brzmieć „jak przypiąć tego klienta”, a zaczyna „wobec czego mogę napisać regułę, której brama nie odzyska”.

Co brama faktycznie robi, gdy klient się łączy

Brama trzyma skonfigurowaną pulę adresów klientów i traktuje ją jak tabelę dzierżaw. Przy połączeniu bierze kolejny wolny adres, w praktyce najniższy dostępny, i przydziela go adapterowi tunelu, aż klient się rozłączy lub dzierżawa wygaśnie. Decyduje kolejność, nie tożsamość: kto pierwszy połączy się ponownie po spokojnym okresie, dostaje najniższy adres, który w tej chwili przypadkiem jest wolny.

Rozmiar puli ukrywa zachowanie. Pula laboratoryjna o jeden lub dwa adresy większa od liczby testerów wydaje się deterministyczna, bo ten sam laptop zwykle łączy się ponownie w tej samej kolejności każdego ranka. Dodaj trzecią maszynę, zmień rozmiar puli albo zostaw sesję podłączoną przez lunch, a wzorzec się psuje. Adres nigdy nie był stabilny; stabilna była kolejka.

Każda zmiana konfiguracji point-to-site resetuje też przestrzeń dzierżaw. Inny typ uwierzytelniania, pula o zmienionym rozmiarze, nowy zakres puli albo brama rozebrana i zbudowana od nowa — wszystkie odsyłają klientów do puli, która nie odpowiada już ich starym adresom. Nic w tej zmianie nie dotyka twojego NSG, dlatego awaria wygląda na samoistną.

Można to zobaczyć w około minutę. Połącz się, zapisz adres tunelu w szczegółach połączenia klienta, rozłącz się, podłącz drugą maszynę, a potem połącz ponownie pierwszą. Adres, który odzyskasz, zależy od tego, co trzyma druga maszyna, i żadne ustawienie portalu nie przywróci poprzedniego na żądanie.

NSG oparty na IP klienta jest w rzeczywistości regułą o kolejności połączeń

Reguła, którą ludzie piszą pierwszą, jest oczywista: reguła przychodząca na karcie sieciowej maszyny zarządzającej albo na jej podsieci, ze źródłem w postaci wewnętrznego adresu klienta VPN. Jest krótka, przechodzi test w dniu napisania i zawodzi, gdy tylko pula ma więcej niż jeden wolny adres.

Wynikają z tego dwa tryby awarii i tylko jeden wygląda jak błąd. Uprawniony użytkownik jest odrzucany, bo ktoś inny trzyma w tej chwili adres, który nazywa reguła, i przychodzi to jako irytujące zgłoszenie do pomocy technicznej. Albo nieprzewidziany użytkownik jest wpuszczany, bo odziedziczył adres, któremu reguła wciąż ufa, i nie przychodzi to jako nic, dopóki ktoś nie zrobi audytu dostępu.

Ponieważ reguła podąża za dzierżawą, efektywna polityka brzmi „pierwsza osoba, która się połączy, dostaje dostęp administracyjny”. To opis kolejności połączeń przebrany za intencję, i żadna higiena reguł nie czyni z niego wyrazu intencji.

Dzierżawa klienta i adres bramy to różne obiekty

Większość zamieszania bierze się z jednego słowa. Brama ma publiczny IP, który jest względnie stabilny; klienci mają prywatne adresy z puli, które takie nie są. Dla bramy VPN bez nadmiarowości strefowej publiczny IP jest przydzielany dynamicznie, ale przeżywa zmianę rozmiaru, reset i rutynową konserwację — zmienia się, gdy sama brama zostanie usunięta i utworzona od nowa. Jednostki SKU bramy nadmiarowe strefowo i strefowe używają publicznego IP jednostki Standard, a to przydzielenie musi być statyczne.

To właśnie ta stabilność jest potrzebna partnerowi lokalnemu w jego konfiguracji i nie mówi nic o identyfikowaniu pojedynczego klienta. Gdy partner pyta, jaki adres zobaczy, odpowiedzią jest publiczny IP bramy w site-to-site albo wspólny zakres NAT — nigdy dzierżawa tunelu laptopa.

Pule grupowe dają zakres, wobec którego warto pisać reguły

Virtual WAN point-to-site obsługuje grupy użytkowników, a każdej grupie można przydzielić własną pulę adresów klientów. Członkostwo jest ustalane przez tożsamość, więc zakres, w którym ląduje klient, staje się przewidywalny: operacje w jednym zakresie, wykonawcy w innym, a zakres jest czymś, co reguła firewalla lub NSG może nazwać bez zgadywania.

Powstały zestaw reguł ma kształt, który można przejrzeć:

• jedna pula na grupę odbiorców, dobrana do szczytu równoczesnych sesji, a nie do liczby osób;
• członkostwo w grupie zarządzane przez tożsamość, a nie przez edycję reguł za każdym razem, gdy ktoś dołącza;
• reguły NSG lub Azure Firewall pisane wobec zakresów puli, nigdy wobec pojedynczych dzierżaw;
• osobny koncentrator lub brama dla odbiorców, którzy nigdy nie powinni dzielić zakresu.

Wpisanie całej puli na listę dozwolonych jest uczciwe, ale grube: każdy podłączony klient w tym zakresie dostaje taki sam dostęp. To decyzja polityczna, którą warto wypowiedzieć na głos, a nie odkryć podczas przeglądu. Wszystko, co nadal wymaga odpowiedzi na osobę, należy do zasobu przez przypisania ról, a nie do filtra pakietów.

Gdy wdrożenie nie może przejść na Virtual WAN

Wiele bram pozostaje zwykłymi bramami VPN, a przejście na Virtual WAN nie jest drobną zmianą. Praktyczna odpowiedź to przeniesienie decyzji na użytkownika z filtra pakietów na coś, co już wie, kim jest użytkownik.

Tożsamość na poziomie zasobu jest najtańszą wersją. Storage, SQL i Key Vault obsługują uwierzytelnianie Entra ID z przypisaniami ról na użytkownika lub grupę, więc VPN musi tylko udowodnić osiągalność sieci. Host przeskoku z nazwanymi kontami robi to samo dla pracy administracyjnej, bo host zapisuje człowieka, a tunel tylko przenosi pakiety. Zarejestrowanie klientów w DNS i zezwolenie na nazwę zamiast numeru podnosi regułę o warstwę wyżej. Tożsamość na poziomie aplikacji — temat certyfikatu, oświadczenie tokenu, członkostwo w grupie — działa, gdy o decyzję proszona jest aplikacja, a nie sieć.

Dla partnera, który nalega na stały adres źródłowy, odpowiedzią jest site-to-site lub ExpressRoute ze zdefiniowanym prefiksem peera. Oni zezwalają na prefiks peera, adres widoczny po ich stronie należy do bramy i nie zmienia się, gdy ktoś uruchomi laptop ponownie.

Sprawdź pulę, zanim edytujesz kolejną listę dozwolonych

Dwie właściwości puli powodują większość zachowań, za które ludzie obwiniają klienta. Zbyt mała pula szybko odzyskuje dzierżawy, więc adresy wydają się ciągle przemieszczać, a każda reguła oparta na adresie wygląda na niestabilną z założenia. Pula, która pokrywa się z zakresami lokalnymi albo z przestrzenią adresową sieci wirtualnej, tworzy niejednoznaczność routingu, której nie naprawi żadna reguła firewalla.

Zrób trzy rzeczy na jednej stronie, zanim dotkniesz reguły: pulę point-to-site, przestrzeń adresową sieci wirtualnej i zakresy lokalne. Nie mogą się nakładać, a pula potrzebuje miejsca dla każdego równoczesnego klienta plus marginesu na ponowne połączenia.

Potem zamknij pętlę w tej kolejności:

• Połącz się z dwóch maszyn w obu kolejnościach i porównaj adresy; jeśli mogą się zamienić, żadna reguła oparta na adresie nie jest bezpieczna.
• Sprawdź, czy brama jest typu Virtual WAN; jeśli tak, używaj pul grupowych zamiast reguł na adres.
• Zapytaj, co się dzieje, gdy reguła trafi na niewłaściwą osobę; jeśli odpowiedzią jest incydent dostępu, przenieś kontrolę na tożsamość.
• Zapisz, który zakres należy do której grupy, w tym samym repozytorium co definicje NSG.
• Przetestuj ponownie po każdej zmianie puli, uwierzytelniania lub bramy, bo te zmiany przepisują mapowanie bez zapowiedzi.