VPN-inloggningen fastnar efter en RADIUS Access-Challenge

Lösenordet är rätt, VPN-inloggningen misslyckas ändå, och RADIUS-servern har kanske gjort exakt det den blev tillsagd. Gatewayen har troligen tagit emot en Access-Challenge, inte visat något användbart och sedan tajmat ut eller behandlat svaret som ett avslag. Från klientsidan ser det ut som felaktiga inloggningsuppgifter eller en trasig tunnel. Orsaken ligger oftast mitt i ett samtal som ingen fångat.

En inloggning, två RADIUS-utbyten

När backend vill ha en andra faktor svarar den inte på den första begäran med accept eller avslag. Den svarar med kod 11 och väntar på användarens nästa svar, som gatewayen måste skicka tillbaka i en uppföljningsbegäran. Den uppföljningen hör till samma autentiseringssamtal, inte till ett nytt inloggningsförsök.

I en fungerande konfiguration ser användaren en andra fråga: först lösenordet, sedan en engångskod, eller en enda kombinerad fråga om operatören har dokumenterat en sådan. I en trasig konfiguration visas aldrig den andra frågan och inloggningen misslyckas helt enkelt.

Det är symptomet att jaga, och det är lätt att bekräfta bara från klientsidan: om VPN-klienten frågar efter exakt en hemlighet och sedan avvisar ett lösenord du vet är giltigt, slutade utbytet troligen vid utmaningen.

Vad utmaningen faktiskt bär

RADIUS-specifikationen beskriver kod 11 i avsnitt 4.4 och tillåter två attribut som spelar roll här. Reply-Message innehåller text avsedd för användaren, och State innehåller ett ogenomträngligt värde som servern vill ha tillbaka. NAS ska inte tolka State, bara returnera det oförändrat.

Uppföljningsbegäran använder en ny Identifier och en ny Request Authenticator, och den måste bära samma State-värde plus användarens svar. Servern matchar den mot den väntande utmaningen via den State, och därför kan en gateway som återskapar eller tappar attributet inte slutföra ceremonin. Även response authenticator i varje svar måste valideras, annars bör NAS kasta paketet.

Avsnitt 4.4 tillägger detaljen som förklarar de flesta tysta fel: en NAS som inte kan stödja utmaningar behandlar Access-Challenge som ett avslag. Om gatewayens VPN-tjänst är äldre än det stödet eller utelämnar det, blir backendens begäran om en andra faktor ett omedelbart «autentisering misslyckades» utan någon fråga.

Var den kedjade begäran går förlorad

Den första misstänkta är frågevägen, inte inloggningsuppgifterna. En portal som visar ett OTP-fält för webbinloggningar gör inte det automatiskt för VPN-tjänsten, och vissa gateways skickar bara en utmaning vidare till klienter som annonserar förmågan. Testa samma konto vid båda ingångarna; om portalen fungerar och VPN inte, tittar du på överlämningen, inte på token.

Inmatningsformatet är den andra misstänkta. Att sammanfoga lösenord och kod utan leverantörens dokumenterade avgränsare, eller låta sparade inloggningsuppgifter spela upp en gammal kod, misslyckas på ett sätt som ser identiskt ut med ett fel lösenord. Använd operatörens dokumenterade separata fråga eller kombinerade format, och hitta aldrig på en avgränsare.

Versionsspecifika fel finns, men en lista över rättade versioner från år tillbaka är inte en diagnos för dagens driftsättning. Läs release notes för den programvara du faktiskt kör, och håll det observerade utbytessteget som ditt bevis.

Följ ett enda försök från början till slut

Reproducera det en gång med felsökning på serversidan påslagen, och håll alla andra sessioner utanför inspelningsfönstret:

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

I utdata leta efter samtalets form i stället för en enda rad. En första Access-Request med Identifier 3, en Access-Challenge som bär State, sedan en andra Access-Request med Identifier 4 som upprepar den State och inkluderar användarens svar. Om den andra begäran saknas följde gatewayen aldrig upp. Om den kommer utan State kan servern inte matcha den mot den väntande utmaningen och avvisar den vanligen.

Dölj inloggningsuppgifter, tokens och onödiga identitetsuppgifter när du delar spåret, och korrelera händelser från det ena försöket i stället för att blanda upprepningar från flera webbläsarflikar. Tidsstämplar är din vän här; en utmaning som anländer efter att klienten gett upp ser ut som ett avslag för användaren och som ett långsamt svar i loggen.

Det sluttillstånd du vill ha är ett slutfört, auktoriserat samtal följt av den avsedda tjänsteåtkomsten. Ett svar som anländer från RADIUS-servern bevisar mycket mindre än det.