Klienci VPN w RRAS potrzebują własnej puli IPv4 i drogi powrotnej

Klient VPN łączy się i otrzymuje adres, ale host LAN, którego potrzebuje, nadal nie potrafi mu odpowiedzieć. W Windows Routing and Remote Access wewnętrzny adres klientów VPN pochodzi z puli skonfigurowanej oddzielnie od karty LAN serwera, a strona LAN potrzebuje trasy powrotnej do tej puli. Dwie zmiany, nie jedna, i zawodzą w różny sposób. Przejdź przez nie po kolei, aby plan adresów i droga powrotna zostały udowodnione, zanim stare zakresy zostaną wycofane.

Zarezerwuj zakres, zanim otworzysz konsolę

Wybierz prefiks, który nie nakłada się na LAN, inne zakresy VPN ani nic, co jest routowane do lokalizacji. /24 to wygodny rozmiar do testu, a pierwszą użyteczną część można oddać klientom, podczas gdy reszta pozostaje wolna na rozwój. Zapisz go wraz z przeznaczeniem i właścicielem, zanim wpiszesz go w konsoli. Zostaw miejsce na obu końcach bloku, aby późniejszy podział nie wymusił przenumerowania.

Plan adresów, który żyje tylko w konsoli, jest jedno odbudowanie od kolizji. Ma też skłonność do rozrastania się: ktoś później dodaje drugi zakres i nikt nie sprawdza pierwszego. Trzymaj plan obok dokumentacji serwera, nie w wątku czatu.

Karta LAN serwera nie definiuje tej puli. Zmiana publicznego odbiornika lub dodanie karty do LAN robi coś zupełnie innego. Dlatego klienci mogą się łączyć i mimo to otrzymywać adres z niewłaściwego miejsca. Pula żyje we właściwościach IPv4 serwera, a nie na liście kart.

Zmiana metody to nie dodanie zakresu

RRAS ma metodę przypisywania i zestaw zakresów. Przejście z DHCP na pulę statyczną to zmiana metody. Dodanie kolejnego bloku, gdy pula statyczna jest już aktywna, to zmiana zakresu.

Podejrzyj obie operacje, zanim uruchomisz którąkolwiek, i przeczytaj, która pasuje do bieżącego stanu serwera:

Set-VpnIPAddressAssignment -IPAssignmentMethod StaticPool -IPAddressRange '10.250.50.10','10.250.50.100' -WhatIf
Add-VpnIPAddressRange -IPAddressRange '10.250.50.110','10.250.50.150' -WhatIf

Drugi cmdlet kończy się niepowodzeniem lub tworzy bezużyteczną pulę, jeśli serwer nadal korzysta z przypisywania DHCP. Pierwszy zastępuje metodę, zamiast rozszerzać istniejącą pulę. Żaden podgląd niczego nie stosuje, więc uruchom pasujący, a następnie potwierdź wynikową pulę w konsoli. Jeśli nie masz pewności, w jakim stanie jest serwer, odczytaj metodę przypisywania na stronie właściwości IPv4 i wylistuj skonfigurowane zakresy:

Get-VpnIPAddressRange

Metoda DHCP z pustą listą zakresów oznacza, że obowiązuje pierwszy podgląd. Pula adresów statycznych z istniejącym zakresem oznacza, że obowiązuje drugi.

Uwzględnij restart usługi, którego może wymagać ustawienie, i nie zakładaj, że połączeni klienci zostaną od razu przenumerowani. Klient, który zachowuje stary adres do ponownego połączenia, zachowuje się normalnie. Zaplanuj zmianę na okno, w którym ponowne połączenie jest dopuszczalne.

LAN potrzebuje trasy powrotnej

Załóżmy, że LAN to 10.60.0.0/24, a serwer RRAS to 10.60.0.10 w niej. Host w tej sieci LAN, który odpowiada klientowi w 10.250.50.0/24, potrzebuje ścieżki do puli przez serwer RRAS. Bez tej ścieżki żądanie dociera, a odpowiedź ginie.

Jeśli bramą domyślną hosta jest inny router, ten router potrzebuje trasy powrotnej dla prefiksu VPN. Statyczna trasa na serwerze RRAS tu nie pomoże; droga powrotna musi istnieć na urządzeniu, które posiada bramę LAN, więc dodaj ją do tabeli routingu lub do procesu routingu dynamicznego, zależnie od tego, czego używa lokalizacja.

Sprawdź też zaporę hosta i wszystkie reguły dostępu do sieci wobec nowego zakresu źródłowego. Reguły napisane dla starego zakresu klientów odrzucają nowy, nawet jeśli przypisanie się powiodło. Trasy klienta do LAN i rozwiązywanie DNS to osobne wymagania i oba mogą zawieść, gdy tunel wygląda zdrowo. Przetestuj każde osobno.

Udowodnij nową pulę na jednym urządzeniu, zanim wycofasz starą

Weź jedno uprawnienie, które kontrolujesz, połącz się ponownie i odczytaj adres puli, który otrzymał klient. Ta jedna liczba oddziela przypisanie od routingu. Następnie uruchom nazwaną aplikację, obserwuj ruch powrotny i wypróbuj cel, który powinien pozostać zabroniony. Trzy obserwacje, trzy różne tryby awarii.

Rozwiązywanie nazw zasługuje na własny test: dostęp przez IP może działać, gdy DNS klienta nadal wskazuje resolver, do którego nie może dotrzeć. Serwer DNS w LAN jest osiągalny tylko wtedy, gdy klient ma do niego trasę, a serwer przyjmuje zapytania z nowego zakresu. Oba są częstymi przeoczeniami przy przenoszeniu puli.

Wycofaj stare zakresy i ich wyjątki dopiero po uwzględnieniu aktywnych sesji i procesu utrzymania. Połączony klient z nowym adresem dowodzi przypisania, a nie polityki dostępu. Trzymaj stary zakres udokumentowany, aż wygaśnie ostatnia sesja, która go używała.

Sprawdź wynik trzema obserwacjami

Akceptacja wymaga trzech faktów: klient ma adres z nowej puli, host LAN może do niego dotrzeć i otrzymać odpowiedź, a zabroniony cel pozostaje zabroniony. Każdy ma własną kontrolę, więc awaria wskazuje na przypisanie, routing lub politykę. Wykonaj je w tej kolejności.

Z klienta potwierdź adres i trasę do jednego hosta LAN:

ipconfig | findstr /i "IPv4"
route print -4

Z hosta LAN potwierdź drogę powrotną i politykę w jednym przebiegu. Jeśli ping zawodzi, ale aplikacja działa, brakującym elementem jest prawdopodobnie reguła ICMP, a nie trasa. Jeśli zawiodą oba, przeczytaj trasę na hoście przed edycją VPN. Zapisz trzy wyniki w zgłoszeniu zmiany, aby następna osoba zaczęła od dowodów.