Framed-IP-Address w RADIUS dla stabilnego adresu klienta VPN

RADIUS może odpowiedzieć adresem dla konkretnego użytkownika; to, czy tunel go faktycznie otrzyma, zależy od bramy. Właśnie w tej luce między zwróconym a zastosowanym zawodzą większość planów stabilnego adresu. Atrybut w odpowiedzi testowej dowodzi, że serwer potrafi go wysłać, a nie że usługa dostępu zdalnego go stosuje. Poniższa sekwencja sprawdza obie połowy, zanim adres trafi do reguł zapory.

Zdecyduj, która warstwa posiada adres

Bramy dostępu zdalnego zwykle mają lokalną pulę, a wiele potrafi też przyjąć adres z odpowiedzi uwierzytelniania. To, która wygra, zależy od platformy, protokołu i konfiguracji usługi, więc przeczytaj regułę pierwszeństwa dla dokładnie używanej wersji. Tam, gdzie pierwszeństwo ma pula lokalna, atrybut jest tylko ozdobą, a klient i tak trafia na losowy adres. Zapisz decyzję, w tym czy zwrócona wartość musi mieścić się w zakresie puli, czy może wykraczać poza niego.

RFC 2865 definiuje Framed-IP-Address jako adres, który należy skonfigurować dla użytkownika, i nic nie mówi o gotowości konkretnej bramy do jego respektowania. Dokumentacja producenta jest autorytetem w kwestii pierwszeństwa, a nie definicja atrybutu.

Wyślij żądanie testowe i odczytaj odpowiedź

Najpierw przetestuj serwer osobno, aby brakujący atrybut nie został pomylony z problemem bramy. radtest wysyła jedno Access-Request i wypisuje atrybuty, które wracają.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Poszukaj Framed-IP-Address w Access-Accept i potwierdź, że wartość jest zamierzona, a nie adresem puli z reguły zapasowej. Gdy atrybutu brakuje, wpis użytkownika lub polityka autoryzacji nie pasują, a dostrajanie bramy nie dostarczy tego, czego serwer nigdy nie wysłał. Powtórz żądanie, gdy serwer działa w trybie debugowania, jeśli odpowiedź trudno powiązać z konkretną regułą. Trzymaj wspólny sekret poza historią powłoki i zgłoszeniami, bo powyższy symbol zastępczy nie jest danymi logowania.

Potwierdź, że brama uszanowała wartość

Poprawna odpowiedź to tylko połowa umowy. Adres, który pojawia się na interfejsie tunelu, jest obserwacją, która ma znaczenie, i odczytuje się go na kliencie, a nie wnioskuje z konfiguracji bramy.

ip -4 addr show tun0

Porównaj ten adres z atrybutem z Access-Accept. Niezgodność oznacza, że brama zignorowała lub przepisała wartość, co ponownie otwiera kwestię pierwszeństwa z pierwszej sekcji. Połącz się jeszcze raz, ponieważ rezerwacja działająca tylko przy pierwszej próbie zwykle wskazuje na nieaktualną sesję lub dzierżawę wciąż trzymaną przez poprzednie połączenie. Zapisz wersję bramy i protokół obok wyniku, aby następna osoba mogła ocenić, czy zachowanie zależy od wersji.

Zaplanuj współbieżność i unieważnianie

Jedna nazwa użytkownika na dwóch urządzeniach nie może odpowiadać jednemu adresowi, chyba że brama rozróżnia sesje czymś więcej niż logowaniem. Zdecyduj, czy mapowanie należy do osoby, zarejestrowanego urządzenia czy tożsamości certyfikatu, i wyraźnie zapisz ten wybór w magazynie polityk. Przetestuj drugiego jednoczesnego klienta i porównaj oba przydzielone adresy, ponieważ kolizja tutaj pojawia się później jako błąd routingu. Ta sama staranność należy do planu unieważniania, ponieważ adres przydzielony ponownie, gdy stare reguły zapory nadal go wskazują, staje się błędem autoryzacji.

Stabilne adresowanie upraszcza reguły i logi, ale nigdy nie dowodzi, kto wygenerował pakiet. Uwierzytelnianie i autoryzacja celu nadal mają znaczenie, gdy ten adres później przejdzie do innej sesji.