VPN-kirjautuminen jumittuu RADIUS Access-Challengen jälkeen

Salasana on oikein, VPN-kirjautuminen epäonnistuu silti, ja RADIUS-palvelin on ehkä tehnyt täsmälleen sen, mitä sille käskettiin. Yhdyskäytävä sai todennäköisesti Access-Challengen, ei näyttänyt mitään hyödyllistä ja joko aikakatkaisi tai käsitteli vastauksen hylkäyksenä. Asiakkaan puolelta se näyttää vääriltä tunnuksilta tai rikkinäiseltä tunnelilta. Syy on yleensä keskellä keskustelua, jota kukaan ei tallentanut.

Yksi kirjautuminen, kaksi RADIUS-vaihtoa

Kun taustajärjestelmä haluaa toisen tekijän, se ei vastaa ensimmäiseen pyyntöön hyväksynnällä tai hylkäyksellä. Se vastaa koodilla 11 ja odottaa käyttäjän seuraavaa vastausta, jonka yhdyskäytävän on lähetettävä takaisin jatkopyynnössä. Se jatkopyyntö kuuluu samaan todennuskeskusteluun, ei uuteen kirjautumisyritykseen.

Toimivassa kokoonpanossa käyttäjä näkee toisen kehotteen: ensin salasana, sitten kertakäyttökoodi, tai yhden yhdistetyn kehotteen, jos ylläpitäjä on sellaisen dokumentoinut. Rikkoutuneessa kokoonpanossa toista kehotetta ei koskaan ilmesty ja kirjautuminen yksinkertaisesti epäonnistuu.

Se on oire, jota kannattaa jahdata, ja se on helppo vahvistaa pelkästään asiakkaan puolelta: jos VPN-asiakas kysyy täsmälleen yhtä salaisuutta ja hylkää sitten salasanan, jonka tiedät olevan kelvollinen, vaihto päättyi todennäköisesti haasteeseen.

Mitä haaste oikeastaan kuljettaa

RADIUS-määritys kuvaa koodin 11 kohdassa 4.4 ja sallii kaksi attribuuttia, jotka ovat tässä olennaisia. Reply-Message sisältää käyttäjälle tarkoitetun tekstin, ja State sisältää läpinäkymättömän arvon, jonka palvelin haluaa takaisin. NAS:in ei ole tarkoitus tulkita Statea, vain palauttaa se muuttumattomana.

Jatkopyyntö käyttää uutta Identifieriä ja uutta Request Authenticatoria, ja sen on kuljetettava sama State-arvo sekä käyttäjän vastaus. Palvelin yhdistää sen odottavaan haasteeseen juuri sen Staten kautta, minkä vuoksi yhdyskäytävä, joka luo attribuutin uudelleen tai pudottaa sen, ei voi saattaa seremoniaa loppuun. Myös jokaisen vastauksen response authenticator on validoitava, tai NAS:in pitäisi hylätä paketti.

Kohta 4.4 lisää yksityiskohdan, joka selittää useimmat äänettömät epäonnistumiset: NAS, joka ei voi tukea haasteita, käsittelee Access-Challengen hylkäyksenä. Jos yhdyskäytäväsi VPN-palvelu on tuota tukea vanhempi tai jättää sen pois, taustajärjestelmän pyyntö toisesta tekijästä muuttuu välittömäksi «todennus epäonnistui» ilman mitään kehotetta.

Mihin ketjutettu pyyntö katoaa

Ensimmäinen epäilty on kehotepolku, ei tunnus. Portaali, joka näyttää verkkokirjautumisille OTP-kentän, ei tee sitä automaattisesti VPN-palvelulle, ja jotkin yhdyskäytävät välittävät haasteen vain asiakkaille, jotka ilmoittavat tämän kyvyn. Testaa sama tili molemmissa sisäänkäynneissä; jos portaali toimii eikä VPN, katsot luovutusta, et tokenia.

Syöttömuoto on toinen epäilty. Salasanan ja koodin yhdistäminen ilman toimittajan dokumentoimaa erotinta tai tallennettujen tunnusten antaminen toistaa vanhaa koodia epäonnistuu tavalla, joka näyttää täsmälleen väärältä salasanalta. Käytä ylläpitäjän dokumentoimaa erillistä kehotetta tai yhdistettyä muotoa äläkä koskaan keksi erotinta itse.

Julkaisuversiokohtaisia vikoja on olemassa, mutta luettelo vuosien takaisista korjatuista versioista ei ole tämän päivän käyttöönoton diagnoosi. Lue sen ohjelmiston julkaisutiedot, jota todella ajat, ja pidä havaittu vaihdon vaihe todisteenasi.

Jäljitä yksi yritys päästä päähän

Toista se kerran palvelinpuolen virheenjäljitys päällä ja pidä kaikki muut istunnot tallennusikkunan ulkopuolella:

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

Tulosteesta etsi keskustelun muotoa yksittäisen rivin sijaan. Ensimmäinen Access-Request Identifierillä 3, Statea kuljettava Access-Challenge, sitten toinen Access-Request Identifierillä 4, joka toistaa tuon Staten ja sisältää käyttäjän vastauksen. Jos toinen pyyntö puuttuu, yhdyskäytävä ei koskaan jatkanut. Jos se saapuu ilman Statea, palvelin ei voi yhdistää sitä odottavaan haasteeseen ja hylkää sen yleensä.

Peitä tunnukset, tokenit ja tarpeettomat henkilötiedot, kun jaat jäljen, ja korreloi tapahtumat yhdestä yrityksestä sen sijaan, että sekoitat uusintayrityksiä useista selaimen välilehdistä. Aikaleimat ovat täällä ystäväsi; haaste, joka saapuu sen jälkeen kun asiakas luovutti, näyttää käyttäjälle hylkäykseltä ja lokissa hitaalta vastaukselta.

Haluamasi lopputila on valmistunut, valtuutettu keskustelu, jota seuraa aiottu palvelun käyttö. RADIUS-palvelimelta saapuva vastaus todistaa paljon vähemmän.