Prijava v VPN se ustavi po Access-Challenge RADIUS

Geslo je pravilno, prijava v VPN kljub temu ne uspe, in strežnik RADIUS je morda naredil točno to, kar mu je bilo ukazano. Prehod je verjetno prejel Access-Challenge, ni pokazal nič koristnega in je nato potekel ali pa je ta odgovor obravnaval kot zavrnitev. Z odjemalčeve strani je videti kot napačne poverilnice ali pokvarjen tunel. Vzrok je običajno na sredini pogovora, ki ga ni nihče zajel.

Ena prijava, dve izmenjavi z RADIUS

Ko zaledni sistem želi drugi dejavnik, na prvo zahtevo ne odgovori s sprejemom ali zavrnitvijo. Odgovori s kodo 11 in čaka na naslednji odgovor uporabnika, ki ga mora prehod poslati nazaj v nadaljevalni zahtevi. Ta nadaljevalna zahteva pripada istemu pogovoru za preverjanje pristnosti, ne novemu poskusu prijave.

V delujoči nastavitvi uporabnik vidi drugi poziv: najprej geslo, nato enkratno kodo, ali en sam združen poziv, če ga je operater dokumentiral. V pokvarjeni nastavitvi drugi poziv nikoli ne pride in prijava preprosto ne uspe.

To je simptom, ki ga je treba loviti, in ga je enostavno potrditi samo z odjemalčeve strani: če odjemalec VPN zahteva natanko eno skrivnost in nato zavrne geslo, za katero veste, da je veljavno, se je izmenjava verjetno končala pri izzivu.

Kaj izziv dejansko nosi

Specifikacija RADIUS opisuje kodo 11 v razdelku 4.4 in dovoljuje dva atributa, ki sta tu pomembna. Reply-Message vsebuje besedilo za uporabnika, State pa vsebuje neprozorno vrednost, ki jo strežnik želi dobiti nazaj. NAS ne sme razlagati State, le vrniti ga nespremenjenega.

Nadaljevalna zahteva uporablja nov Identifier in nov Request Authenticator ter mora nositi isto vrednost State in uporabnikov odgovor. Strežnik jo poveže s čakajočim izzivom prav prek tega State, zato prehod, ki atribut znova ustvari ali ga spusti, ne more dokončati obreda. Tudi response authenticator v vsakem odgovoru mora biti potrjen, sicer mora NAS paket zavreči.

Razdelek 4.4 doda podrobnost, ki pojasni večino tihih neuspehov: NAS, ki ne more podpirati izzivov, obravnava Access-Challenge kot zavrnitev. Če je storitev VPN vašega prehoda starejša od te podpore ali jo izpušča, zahteva zalednega sistema po drugem dejavniku postane takojšnja «preverjanje pristnosti ni uspelo» brez kakršnega koli poziva.

Kje se verižna zahteva izgubi

Prvi osumljenec je pot poziva, ne poverilnice. Portal, ki za spletne prijave prikazuje polje OTP, tega ne počne samodejno za storitev VPN, in nekateri prehodi posredujejo izziv le odjemalcem, ki to zmožnost napovedo. Preizkusite isti račun na obeh vstopnih točkah; če portal deluje in VPN ne, gledate predajo, ne žetona.

Oblika vnosa je drugi osumljenec. Združevanje gesla in kode brez dobaviteljevega dokumentiranega ločila ali dovoljenje shranjenim poverilnicam, da ponovijo staro kodo, ne uspe na način, ki je videti enako kot napačno geslo. Uporabite dokumentirani ločen poziv ali združeno obliko operaterja in nikoli ne izmislite ločila.

Napake, specifične za izdajo, obstajajo, vendar seznam popravljenih različic izpred let ni diagnoza za današnjo namestitev. Preberite opombe ob izdaji programske opreme, ki jo dejansko poganjate, in opaženo fazo izmenjave obdržite kot svoj dokaz.

Sledite enemu poskusu od začetka do konca

Ponovite ga enkrat z vklopljenim odpravljanjem napak na strežniku in vse druge seje držite zunaj okna zajemanja:

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

V izpisu iščite obliko pogovora, ne ene vrstice. Prvi Access-Request z Identifier 3, Access-Challenge, ki nosi State, nato drugi Access-Request z Identifier 4, ki ta State ponovi in vključuje uporabnikov odgovor. Če druge zahteve ni, prehod nikoli ni nadaljeval. Če prispe brez State, je strežnik ne more povezati s čakajočim izzivom in jo običajno zavrne.

Ko delite sled, zakrijte poverilnice, žetone in nepotrebne identitetne podatke ter povežite dogodke iz enega poskusa, namesto da bi mešali ponovitve iz več zavihkov brskalnika. Časovni žigi so tu vaš prijatelj; izziv, ki prispe po tem, ko je odjemalec obupal, se uporabniku zdi zavrnitev, v dnevniku pa počasen odgovor.

Končno stanje, ki ga želite, je dokončan, pooblaščen pogovor, ki mu sledi predviden dostop do storitve. Odgovor, ki prispe s strežnika RADIUS, dokazuje veliko manj.