VPN-innlogging stopper etter en RADIUS Access-Challenge

Passordet er riktig, VPN-innloggingen feiler likevel, og RADIUS-serveren har kanskje gjort nøyaktig det den ble bedt om. Gatewayen har sannsynligvis mottatt en Access-Challenge, ikke vist noe nyttig og deretter timet ut eller behandlet svaret som en avvisning. Fra klientsiden ser det ut som dårlige påloggingsdata eller en ødelagt tunnel. Årsaken ligger vanligvis midt i en samtale som ingen har fanget opp.

Én innlogging, to RADIUS-utvekslinger

Når backend vil ha en andre faktor, svarer den ikke på den første forespørselen med aksept eller avvisning. Den svarer med kode 11 og venter på brukerens neste svar, som gatewayen må sende tilbake i en oppfølgingsforespørsel. Den oppfølgingen hører til den samme autentiseringssamtalen, ikke til et nytt innloggingsforsøk.

I et fungerende oppsett ser brukeren en andre forespørsel: først passordet, deretter en engangskode, eller én kombinert forespørsel hvis operatøren har dokumentert en. I et ødelagt oppsett vises aldri den andre forespørselen, og innloggingen feiler rett og slett.

Det er symptomet som må forfølges, og det er lett å bekrefte bare fra klientsiden: hvis VPN-klienten ber om nøyaktig én hemmelighet og deretter avviser et passord du vet er gyldig, endte utvekslingen sannsynligvis ved utfordringen.

Hva utfordringen faktisk bærer

RADIUS-spesifikasjonen beskriver kode 11 i avsnitt 4.4 og tillater to attributter som betyr noe her. Reply-Message inneholder tekst ment for brukeren, og State inneholder en ugjennomsiktig verdi som serveren vil ha tilbake. NAS skal ikke tolke State, bare returnere den uendret.

Oppfølgingsforespørselen bruker en ny Identifier og en ny Request Authenticator, og den må bære samme State-verdi pluss brukerens svar. Serveren kobler den til den ventende utfordringen gjennom den State, og derfor kan en gateway som regenererer eller dropper attributtet ikke fullføre seremonien. Response authenticator i hvert svar må også validere, ellers bør NAS forkaste pakken.

Avsnitt 4.4 tilføyer detaljen som forklarer de fleste stille feil: en NAS som ikke kan støtte utfordringer, behandler Access-Challenge som en avvisning. Hvis gatewayens VPN-tjeneste er eldre enn den støtten eller utelater den, blir backendens forespørsel om en andre faktor til et umiddelbart «autentisering mislyktes» uten noen forespørsel.

Hvor den kjedede forespørselen går tapt

Den første mistenkte er forespørselsveien, ikke påloggingsdataene. En portal som viser et OTP-felt for webinnlogginger, gjør ikke det automatisk for VPN-tjenesten, og noen gateways sender bare en utfordring videre til klienter som annonserer evnen. Test den samme kontoen på begge inngangene; hvis portalen virker og VPN ikke, ser du på overleveringen, ikke på tokenet.

Innskrivingsformatet er den andre mistenkte. Å sette sammen passord og kode uten leverandørens dokumenterte skilletegn, eller la lagrede påloggingsdata spille av en gammel kode, feiler på en måte som ser identisk ut med et feil passord. Bruk operatørens dokumenterte separate forespørsel eller kombinerte format, og finn aldri på et skilletegn.

Versjonsspesifikke feil finnes, men en liste over rettede versjoner fra for mange år siden er ikke en diagnose for dagens utrulling. Les utgivelsesnotatene for programvaren du faktisk kjører, og hold det observerte utvekslingstrinnet som beviset ditt.

Følg ett enkelt forsøk fra ende til annen

Reproduser det én gang med feilsøking på serversiden slått på, og hold alle andre økter utenfor opptaksvinduet:

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

I utdataene skal du se etter samtalens form framfor en enkelt linje. En første Access-Request med Identifier 3, en Access-Challenge som bærer State, deretter en andre Access-Request med Identifier 4 som gjentar denne State og inkluderer brukerens svar. Hvis den andre forespørselen mangler, fulgte gatewayen aldri opp. Hvis den kommer uten State, kan serveren ikke koble den til den ventende utfordringen og vil vanligvis avvise.

Tildekk påloggingsdata, tokens og unødvendige identitetsopplysninger når du deler sporet, og korreler hendelser fra det ene forsøket i stedet for å blande gjentakelser fra flere nettleserfaner. Tidsstempler er din venn her; en utfordring som kommer etter at klienten har gitt opp, ser ut som en avvisning for brukeren og som et tregt svar i loggen.

Sluttilstanden du ønsker, er en fullført, autorisert samtale etterfulgt av den tiltenkte tjenestetilgangen. Et svar som kommer fra RADIUS-serveren, beviser langt mindre enn det.