Pagalbos tarnybos bilietai aprašo nepavykusį VPN prisijungimą ir RADIUS politiką, reikalaujančią stipresnio metodo, tarsi tai būtų ta pati problema, bet taip nėra. Sietuvas arba priima prisijungimo duomenis ir perduoda juos toliau, arba neša EAP pokalbį tarp kliento ir autentifikavimo serverio. Kuris iš jų vyksta, lemia, ar serverio pusės pakeitimas apskritai gali ką nors ištaisyti. Perskaitykite mainus prieš redaguodami serverio grupę.

Du autentifikavimo keliai, žurnale atrodantys vienodai

Pirmuoju keliu VPN sietuvas surenka vartotojo vardą ir slaptažodį bei siunčia RADIUS Access-Request su slaptažodžio atributu. Autentifikavimo serveris palygina jį su savo saugykla ir atsako priimti arba atmesti. Klientas niekada nevykdo EAP metodo, nes niekas to neprašė.

Antruoju keliu klientas ir autentifikavimo serveris vykdo EAP metodą nuo pradžios iki pabaigos, o sietuvas perduoda EAP-Message atributus tarp jų. Sietuvas vis dar užbaigia išorinį RADIUS pokalbį, bet metodo logika gyvena abiejuose galuose.

Abu keliai žurnale sukuria eilutę, kad autentifikavimas nepavyko. Tik antrajam gali turėti įtakos tai, kurį EAP metodą serveris teikia pirmenybę, o pirmajam – kaip sietuvas skaito slaptažodį. Laikyti juos keičiamais yra priežastis, kodėl komandos praleidžia dieną keisdamos serverio grupes klientui, kuris niekada neketino kalbėti PEAP.

Kur metodas iš tikrųjų veikia

RFC 3579 apibrėžia perdavimo tvarką: NAS neša EAP paketus RADIUS atributuose ir jam nereikia metodo specifinio kodo kiekvienam EAP tipui. Todėl sietuvas gali palaikyti PEAP ir EAP-TLS neįgyvendindamas nė vieno.

Sietuvas, kuris pateikia slaptažodį, neperneša PEAP, net jei backend priimtų PEAP iš kito kliento. PEAP įjungimas serverio politikoje neprideda metodo klientui, kuris niekada jo nepasiūlė.

PPP autentifikavimo nustatymai priklauso PPP tarnybai. Jie tyliai neperkonfigūruoja kiekvieno IPsec ar seno XAuth kelio, naudojančio tą patį AAA serverį, todėl pakeitimas, veikiantis vienam prieigos tipui, gali palikti kitą nepaliestą.

Ką turi palaikyti NAS

Perdavimas perkelia reikalavimą nuo metodo kodo prie nešėjo palaikymo. Sietuvas turi galėti nešti EAP savo VPN protokolu, o RADIUS klientas jame – siųsti ir priimti atitinkamo dydžio EAP-Message atributus.

IKEv2 atveju EAP yra apibrėžto autentifikavimo srauto dalis, o serverio tapatybės ir pasitikėjimo patikros kyla iš to srauto. PEAP etiketė, pasiskolinta iš 802.1X diegimo, automatiškai nepersikelia, nes derybos aplink ją skiriasi.

Kliento pusėje taip pat yra reikalavimų. Jis turi būti sukonfigūruotas metodui, pasitikėti serverio sertifikatu, kurį pateikia metodas, ir turėti prisijungimo duomenis, kuriuos metodas gali naudoti. Sertifikatu pagrįstas metodas be kliento sertifikato nepavyksta dar prieš RADIUS ką nors pamatant, ir tai yra aprūpinimo, o ne serverio politikos problema.

Perskaitykite vieną bandymą prieš keisdami politiką

Užfiksuokite vieną patvirtintą bandymą sietuve ir autentifikavimo serveryje. Ieškokite EAP-Message atributų RADIUS užklausoje. Jų buvimas rodo, kad naudojamas perdavimo kelias; jų nebuvimas nurodo prisijungimo duomenų mainus.

Linux sietuve užfiksuotas RADIUS prievado eismas parodo, kurie atributai yra linijoje:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

Tada palyginkite atmetimo tašką. Nesėkmė sietuve prieš bet kokį RADIUS paketą reiškia, kad klientas ir sietuvas nesusitarė dėl metodo. RADIUS atmetimas su EAP atributais reiškia, kad galai įvykdė metodą ir vienas jų atmetė rezultatą.

Planuokite migraciją kaip vieną pakeitimą nuo pradžios iki pabaigos

Pakeisti metodą reiškia kartu pakeisti kliento konfigūraciją, sietuvo nešėjo palaikymą, serverio metodo politiką ir prisijungimo duomenų saugyklą. Darykite tai tokia tvarka ir palaikykite veikiantį kelią, kol naujasis bus įrodytas. Vien serverio pusės pakeitimas yra spėjimas ir paprastai sugadina veikusius klientus. Paruoškite pakeitimą vienoje bandomojoje tapatybėje prieš liedami grupę.

Užsirašykite veikiančią kombinaciją: VPN protokolas, EAP nešėjas, partnerio metodas, serverio metodas, prisijungimo duomenų tipas ir serverio tapatybės patikra.

Laikykite administracinį AAA prisijungimą atskirai nuo VPN autentifikavimo, nebent užduotis aiškiai apima abu. Nuotolinės prieigos pakeitimas neturėtų atimti galimybės valdyti įrenginį, kuris jį užbaigia.

Susiję straipsniai