Framed-IP-Address RADIUS pentru o adresă stabilă de client VPN
O adresă VPN stabilă are nevoie de RADIUS și de un gateway care respectă atributul. Verificați precedența și comparați răspunsul cu adresa tunelului.
RADIUS poate răspunde cu o adresă pentru un anumit utilizator; dacă tunelul o primește cu adevărat depinde de gateway. Exact în această diferență dintre returnat și aplicat eșuează majoritatea planurilor de adresă stabilă. Un atribut într-un răspuns de test dovedește că serverul îl poate trimite, nu că serviciul de acces la distanță îl aplică. Secvența de mai jos verifică ambele jumătăți înainte ca adresa să ajungă în regulile de firewall.
Decideți ce nivel deține adresa
Gateway-urile de acces la distanță au de obicei un pool local, iar multe pot accepta și o adresă din răspunsul de autentificare. Care câștigă depinde de platformă, de protocol și de configurația serviciului, așa că citiți regula de precedență pentru versiunea exactă folosită. Acolo unde pool-ul local are prioritate, atributul este doar decor și clientul ajunge tot pe o adresă aleatorie. Notați decizia, inclusiv dacă o valoare returnată trebuie să se afle în intervalul pool-ului sau poate fi în afara lui.
RFC 2865 definește Framed-IP-Address ca adresa ce trebuie configurată pentru utilizator, și nu spune nimic despre disponibilitatea unui anumit gateway de a o respecta. Documentația producătorului este autoritatea în privința precedenței, nu definiția atributului.
Trimiteți o cerere de test și citiți răspunsul
Testați mai întâi serverul izolat, pentru ca un atribut lipsă să nu fie confundat cu o problemă a gateway-ului. radtest trimite o Access-Request și afișează atributele care se întorc.
radtest alice 'S3cret' 127.0.0.1 0 testing123Căutați Framed-IP-Address în Access-Accept și confirmați că valoarea este cea dorită, nu o adresă din pool provenită dintr-o regulă de rezervă. Când atributul lipsește, intrarea utilizatorului sau politica de autorizare nu se potrivesc, iar reglajul gateway-ului nu poate furniza ce serverul nu a trimis niciodată. Repetați cererea cât timp serverul rulează în modul debug dacă răspunsul este greu de urmărit până la o regulă anume. Țineți secretul partajat în afara istoricului shell-ului și a tichetelor, pentru că substituentul de mai sus nu este o acreditare.
Confirmați că gateway-ul a respectat valoarea
Un răspuns corect este doar jumătate din contract. Adresa care apare pe interfața tunelului este observația care contează, iar aceasta se citește pe client, nu se deduce din configurația gateway-ului.
ip -4 addr show tun0Comparați acea adresă cu atributul din Access-Accept. O nepotrivire înseamnă că gateway-ul a ignorat sau a rescris valoarea, ceea ce redeschide întrebarea precedenței din prima secțiune. Reconectați încă o dată, pentru că o rezervare care funcționează doar la prima încercare indică de obicei o sesiune veche sau un lease încă deținut de conexiunea anterioară. Notați versiunea gateway-ului și protocolul lângă rezultat, ca următoarea persoană să poată spune dacă comportamentul depinde de versiune.
Planificați concurența și revocarea
Un singur nume de utilizator pe două dispozitive nu poate corespunde unei singure adrese decât dacă gateway-ul distinge sesiunile prin altceva decât autentificarea. Decideți dacă maparea aparține unei persoane, unui dispozitiv înregistrat sau unei identități de certificat, și faceți această alegere explicită în depozitul de politici. Testați un al doilea client simultan și comparați ambele adrese atribuite, deoarece o coliziune aici reapare mai târziu ca o eroare de rutare. Aceeași grijă se aplică în planul de revocare, pentru că o adresă realocată în timp ce vechile reguli de firewall încă o menționează devine un defect de autorizare.
Adresarea stabilă simplifică regulile și jurnalele, dar nu dovedește niciodată cine a generat un pachet. Autentificarea și autorizarea destinației rămân importante când acea adresă trece mai târziu la altă sesiune.