VPN-ensaluto haltiĝas post Access-Challenge de RADIUS

Via pasvorto estas ĝusta, la VPN-ensaluto tamen malsukcesas, kaj la RADIUS-servilo eble faris ĝuste tion, kion oni diris al ĝi. La pordego verŝajne ricevis Access-Challenge, montris nenion utilan kaj poste tempolimis aŭ traktis tiun respondon kiel malakcepton. De la klienta flanko ĝi aspektas kiel malbonaj akreditaĵoj aŭ rompita tunelo. La kaŭzo kutime kuŝas meze de interparolo, kiun neniu kaptis.

Unu ensaluto, du interŝanĝoj kun RADIUS

Kiam la malantaŭa sistemo volas duan faktoron, ĝi ne respondas al la unua peto per akcepto aŭ malakcepto. Ĝi respondas per kodo 11 kaj atendas la sekvan respondon de la uzanto, kiun la pordego devas resendi en sekva peto. Tiu sekva peto apartenas al la sama aŭtentiga interparolo, ne al nova ensaluta provo.

En funkcianta agordo la uzanto vidas duan inviton: unue la pasvorton, poste unufojan kodon, aŭ unu kombinitan inviton se la operatoro dokumentis tian. En rompita agordo la dua invito neniam aperas kaj la ensaluto simple malsukcesas.

Tio estas la simptomo postsekvenda, kaj facile konfirmebla nur de la klienta flanko: se la VPN-kliento petas ĝuste unu sekreton kaj poste malakceptas pasvorton, kiun vi scias validan, la interŝanĝo verŝajne finiĝis ĉe la defio.

Kion la defio efektive portas

La RADIUS-specifo priskribas kodon 11 en sekcio 4.4 kaj permesas du atributojn gravajn ĉi tie. Reply-Message tenas tekston por la uzanto, kaj State tenas netravideblan valoron, kiun la servilo volas ricevi reen. La NAS ne rajtas interpreti State, nur redoni ĝin senŝanĝe.

La sekva peto uzas novan Identifier kaj novan Request Authenticator, kaj ĝi devas porti la saman State-valoron plus la respondon de la uzanto. La servilo parigas ĝin al la atendanta defio per tiu State, tial pordego, kiu regeneras aŭ forĵetas la atributon, ne povas fini la ceremonion. Ankaŭ la response authenticator en ĉiu respondo devas validiĝi, alie la NAS devus forĵeti la paketon.

Sekcio 4.4 aldonas la detalon, kiu klarigas plej multajn silentajn malsukcesojn: NAS, kiu ne povas subteni defiojn, traktas Access-Challenge kiel malakcepton. Se la VPN-servo de via pordego antaŭas tiun subtenon aŭ maltrafas ĝin, la peto de la malantaŭa sistemo pri dua faktoro fariĝas tuja «aŭtentigo malsukcesis» sen iu ajn invito.

Kie la ĉena peto perdiĝas

La unua suspektito estas la invita vojo, ne la akreditaĵo. Portalo, kiu montras OTP-kampon por retaj ensalutoj, ne faras tion aŭtomate por la VPN-servo, kaj kelkaj pordegoj transdonas defion nur al klientoj, kiuj anoncas la kapablon. Testu la saman konton ĉe ambaŭ enirejoj; se la portalo funkcias kaj la VPN ne, vi rigardas la transdonon, ne la ĵetonon.

La eniga formato estas la dua suspektito. Kunigi pasvorton kaj kodon sen la dokumentita apartigilo de la vendanto, aŭ lasi konservitajn akreditaĵojn ripeti malnovan kodon, malsukcesas tiel, ke ĝi aspektas idente al malĝusta pasvorto. Uzu la dokumentitan apartan inviton aŭ kombinitan formaton de la operatoro, kaj neniam elpensu apartigilon.

Eldonej-specifaj difektoj ekzistas, sed listo de riparitaj versioj de antaŭ jaroj ne estas diagnozo por la hodiaŭa sendo. Legu la eldonnotojn de la programaro, kiun vi efektive rulas, kaj konservu la observitan interŝanĝan stadion kiel vian pruvon.

Spuru unu provon de komenco ĝis fino

Reproduktu ĝin unufoje, kun la servila sencimigado ŝaltita, kaj tenu ĉiun alian seancon ekster la kapta fenestro:

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

En la eligo serĉu la formon de la interparolo anstataŭ unu linion. Unua Access-Request kun Identifier 3, Access-Challenge portanta State, poste dua Access-Request kun Identifier 4, kiu ripetas tiun State kaj inkluzivas la respondon de la uzanto. Se la dua peto mankas, la pordego neniam sekvis. Se ĝi alvenas sen State, la servilo ne povas parigi ĝin al la atendanta defio kaj kutime malakceptos.

Kaŝu akreditaĵojn, ĵetonojn kaj nenecesajn identigajn datumojn kiam vi dividas la spuron, kaj korelaciu eventojn el la unu provo anstataŭ miksi ripetojn el pluraj retumilaj langetoj. Tempomarkoj estas via amiko ĉi tie; defio, kiu alvenas post kiam la kliento rezignis, aspektas al la uzanto kiel malakcepto kaj en la protokolo kiel malrapida respondo.

La fina stato, kiun vi volas, estas finita, rajtigita interparolo sekvata de la intencita aliro al la servo. Respondo alvenanta de la RADIUS-servilo pruvas multe malpli ol tio.