VPN-innlogging stoggar etter ein RADIUS Access-Challenge

Passordet er riktig, VPN-innlogginga feilar likevel, og RADIUS-tenaren har kanskje gjort nøyaktig det han vart beden om. Gatewayen har truleg motteke ein Access-Challenge, ikkje vist noko nyttig og deretter tima ut eller handsama svaret som ei avvising. Frå klientsida ser det ut som dårlege påloggingsdata eller ein øydelagd tunnel. Årsaka ligg vanlegvis midt i ein samtale som ingen har fanga opp.

Éi innlogging, to RADIUS-utvekslingar

Når backend vil ha ein andre faktor, svarar han ikkje på den første førespurnaden med aksept eller avvising. Han svarar med kode 11 og ventar på neste svar frå brukaren, som gatewayen må senda tilbake i ein oppfølgingsførespurnad. Den oppfølginga høyrer til den same autentiseringssamtalen, ikkje til eit nytt innloggingsforsøk.

I eit fungerande oppsett ser brukaren ein andre førespurnad: først passordet, deretter ein eingongskode, eller éin kombinert førespurnad om operatøren har dokumentert ein. I eit øydelagt oppsett viser den andre førespurnaden seg aldri, og innlogginga feilar rett og slett.

Det er symptomet som må følgjast, og det er lett å stadfesta berre frå klientsida: om VPN-klienten ber om nøyaktig éin løyndom og deretter avviser eit passord du veit er gyldig, enda utvekslinga truleg ved utfordringa.

Kva utfordringa faktisk ber

RADIUS-spesifikasjonen skildrar kode 11 i avsnitt 4.4 og tillèt to attributt som betyr noko her. Reply-Message inneheld tekst meint for brukaren, og State inneheld ein ugjennomsiktig verdi som tenaren vil ha tilbake. NAS skal ikkje tolka State, berre returnera han uendra.

Oppfølgingsførespurnaden brukar ein ny Identifier og ein ny Request Authenticator, og han må bera same State-verdi pluss svaret frå brukaren. Tenaren koplar han til den ventande utfordringa gjennom den State, og difor kan ein gateway som regenererer eller droppar attributtet ikkje fullføra seremonien. Response authenticator i kvart svar må òg validera, elles bør NAS kasta pakken.

Avsnitt 4.4 legg til detaljen som forklarer dei fleste stille feila: ein NAS som ikkje kan støtta utfordringar, handsamar Access-Challenge som ei avvising. Om VPN-tenesta til gatewayen er eldre enn den støtta eller utelèt henne, blir førespurnaden frå backend om ein andre faktor til eit umiddelbart «autentisering mislykka» utan nokon førespurnad.

Kvar den kjeda førespurnaden går tapt

Den første mistenkte er førespurnadsvegen, ikkje påloggingsdataa. Ein portal som viser eit OTP-felt for webinnloggingar, gjer ikkje det automatisk for VPN-tenesta, og nokre gatewayar sender berre ei utfordring vidare til klientar som annonserer evna. Test den same kontoen på begge inngangane; om portalen verkar og VPN ikkje, ser du på overleveringa, ikkje på tokenet.

Innskrivingsformatet er den andre mistenkte. Å setja saman passord og kode utan det dokumenterte skiljeteiknet frå leverandøren, eller la lagra påloggingsdata spela av ein gamal kode, feilar på ein måte som ser identisk ut med eit feil passord. Bruk den dokumenterte separate førespurnaden eller det kombinerte formatet frå operatøren, og finn aldri på eit skiljeteikn.

Versjonsspesifikke feil finst, men ei liste over retta versjonar frå for mange år sidan er ikkje ein diagnose for dagens utrulling. Les utgivingsnotata for programvara du faktisk køyrer, og hald det observerte utvekslingstrinnet som beviset ditt.

Følg eitt enkelt forsøk frå ende til annan

Reproduser det éin gong med feilsøking på tenarsida slått på, og hald alle andre økter utanfor opptaksvindauget:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

I utdataa skal du sjå etter forma på samtalen framfor ei enkel linje. Ein første Access-Request med Identifier 3, ein Access-Challenge som ber State, deretter ein andre Access-Request med Identifier 4 som gientek denne State og inkluderer svaret frå brukaren. Om den andre førespurnaden manglar, følgde gatewayen aldri opp. Om han kjem utan State, kan tenaren ikkje kopla han til den ventande utfordringa og vil vanlegvis avvise.

Tildekk påloggingsdata, tokens og unødvendige identitetsopplysningar når du deler sporet, og korreler hendingar frå det eine forsøket i staden for å blanda gjentakingar frå fleire nettlesarfaner. Tidsstempel er venen din her; ei utfordring som kjem etter at klienten har gjeve opp, ser ut som ei avvising for brukaren og som eit tregt svar i loggen.

Sluttilstanden du ønskjer, er ein fullført, autorisert samtale etterfylgd av den tiltenkte tenestetilgangen. Eit svar som kjem frå RADIUS-tenaren, beviser langt mindre enn det.