Stały adres VPN IP: Framed-IP-Address w RADIUS czy rezerwacja w puli

Trzy miejsca mogą przechowywać stały adres wewnętrzny klienta VPN, a tylko jedno z nich powinno go posiadać. RADIUS może zwrócić adres w Access-Accept, brama może przechowywać statyczne mapowanie konta, a adapter klienta można ustawić ręcznie. Pierwsze dwa to polityka, a trzecie to lokalne przypuszczenie, które brama może swobodnie zignorować lub nadpisać. Wybór między pierwszymi dwoma to prawdziwa decyzja i zależy od tego, co faktycznie implementuje serwer dostępu do sieci.

Trzy miejsca, w których może mieszkać stały adres

RADIUS posiada adres, gdy odpowiedź zawiera Framed-IP-Address, a brama stosuje tę wartość do sesji. Brama posiada go, gdy administrator mapuje konto na statyczny adres w puli. Klient nie posiada niczego, nawet gdy jego adapter pokazuje adres ręczny, ponieważ serwer przydziela adres wewnętrzny podczas negocjacji, a lokalne ustawienie ma znaczenie tylko wtedy, gdy serwer niczego nie wysyła. Wszystkie trzy wyglądają identycznie na działającym połączeniu, dlatego konflikty ujawniają się późno. Różnica pojawia się przy ponownym połączeniu, na drugim urządzeniu i po zmianie polityki.

Dwaj właściciele to konfiguracja, która się psuje. Odpowiedź RADIUS przydzielająca 172.28.4.77, podczas gdy brama ma statyczne mapowanie na 172.28.4.90, daje wartość, którą kod producenta sprawdza pierwszą, a przegrany jest odrzucany bez linii logu. To samo konto na drugim urządzeniu otrzymuje wtedy duplikat adresu, a objaw czyta się jak błąd routingu, a nie konflikt przydziału. Rozstrzygnij właściciela, zanim dodasz drugi mechanizm.

Opcję po stronie klienta warto wymienić tylko po to, by ją wykluczyć. Ręczny adres adaptera to preferencja, którą system operacyjny może pokazać, a nie rezerwacja, i nie może powstrzymać innej sesji przed otrzymaniem tego samego adresu.

Co odpowiedź RADIUS może obiecać, a czego nie

RFC 2865definiuje Framed-IP-Address jako adres IPv4, który należy skonfigurować dla użytkownika, i należy on do Access-Accept. Ten sam atrybut w Access-Request jest tylko wskazówką, którą serwer może zignorować, co ma znaczenie, gdy klient lub brama proponuje preferowany adres. Nic w protokole nie zmusza bramy do respektowania odpowiedzi, ponieważ serwer dostępu do sieci jest komponentem, który stosuje ją do sesji.

Wsparcie to kwestia produktu, a nie protokołu. Niektóre bramy stosują adresy ramkowe domyślnie, inne potrzebują włączonego przełącznika na poziomie grupy, a jeszcze inne przyjmują atrybut i nigdy nie używają go do sesji dostępu zdalnego. Ten ostatni przypadek jest niebezpieczny, ponieważ rekord rozliczeniowy może pokazywać odpowiedź, podczas gdy klient otrzymuje adres z puli. Potwierdź zachowanie na dokładnym modelu bramy i firmware, którego używasz, a nie w dokumentacji produktu siostrzanego.

Odpowiedź, którą brama ignoruje, wygląda dokładnie jak odpowiedź, która nigdy nie została wysłana. Czytanie Access-Accept i adresu sesji obok siebie to jedyny sposób rozdzielenia tych dwóch przypadków.

Zarezerwuj adres w puli, którą już routujesz

Wybierz stały adres z podsieci puli, którą brama już routuje i której firewall już ufa. Adres spoza tego zakresu zamienia zmianę polityki w projekt routingu, a VPN wstanie, podczas gdy nic za nim nie odpowie. Jeśli istnieją reguły dostępu na adres, dodaj stały adres do nich w tej samej zmianie.

Zdecyduj, co powinna zrobić druga jednoczesna sesja. Przydzielenie jednego adresu dwa razy nie jest zarządzaniem urządzeniami, a wynikowa kolizja pojawia się jako przerywane połączenie dla obu sesji. Albo wydawaj odrębne tożsamości na urządzenie, albo odrębne przydziały, albo wymuszaj jednoczesność obsługiwanym testem, takim jak Simultaneous-Use, zamiast mieć nadzieję, że klient nigdy nie połączy się ponownie przed wygaśnięciem starej sesji.

Trasy powrotne zasługują na taką samą uwagę jak przydział. Brama potrzebuje trasy do puli, wewnętrzne routery potrzebują trasy powrotnej do bramy, a stały adres dziedziczy obie. Jeden klient działający, gdy wszystkie inne zawodzą, zwykle oznacza, że trasa puli istnieje, ale trasy hosta dla zarezerwowanego adresu nie ma.

Przetestuj odpowiedź, zanim zaufasz rezerwacji

Przetestuj stronę AAA i stronę sesji osobno, ponieważ zawodzą z różnych powodów. Lokalny radtest pokazuje, co serwer zwraca dla konta bez udziału bramy, a wpis w pliku użytkowników pokazuje, z czym serwer powinien się zgadzać. Następnie połącz klienta ponownie i porównaj otrzymany adres z atrybutem w odpowiedzi.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

Access-Accept bez atrybutu oznacza, że serwer nie dopasował wpisu lub atrybut nie został zastosowany do tego użytkownika. Access-Accept z atrybutem i klient, który nadal otrzymuje adres z puli, oznacza, że brama go zignorowała. Access-Reject odsyła cię do poświadczeń lub polityki grupowej, a żadnego z tych wyników nie należy debugować, edytując adapter klienta.

Powtórz sprawdzenie po ponownym połączeniu i po drugim logowaniu z innego urządzenia. Rezerwacja, która trzyma się tylko pierwszej sesji, to konflikt puli czekający na wystąpienie, i taniej go znaleźć teraz niż podczas audytu.

Wybierz jednego właściciela i zapisz go

Jeśli brama niezawodnie stosuje adresy ramkowe, pozwól RADIUS-owi posiadać przydział i usuń wszelkie statyczne mapowanie dla tego samego konta. Jeśli nie, pozwól bramie go posiadać i usuń atrybut z odpowiedzi, aby dwa źródła nie mogły się nie zgadzać. Utrzymywanie obu, bo każde prawie działa, gwarantuje przyszłą sesję z niewłaściwym adresem i bez oczywistej przyczyny.

Zapisz wybranego właściciela, zarezerwowany adres i pulę, z której pochodzi, w rekordzie konta. Następna osoba dodająca urządzenie będzie mogła zobaczyć, czy adres jest polityką AAA, czy mapowaniem na bramie, zanim zmieni którekolwiek z nich.