Bumibitin ang pag-log in sa VPN pagkatapos ng Access-Challenge ng RADIUS

Tama ang password mo, nabibigo pa rin ang pag-log in sa VPN, at maaaring ginawa ng RADIUS server ang eksaktong sinabi sa kanya. Malamang nakatanggap ang gateway ng Access-Challenge, walang naipakitang kapaki-pakinabang, at pagkatapos ay nag-time out o itinuring ang sagot na iyon bilang pagtanggi. Sa panig ng kliyente mukhang maling kredensyal o sirang tunnel. Karaniwang nasa gitna ng usapan na walang nakahuli ang dahilan.

Isang pag-log in, dalawang palitan sa RADIUS

Kapag gusto ng backend ng pangalawang salik, hindi ito sumasagot sa unang kahilingan ng pagtanggap o pagtanggi. Sumasagot ito ng code 11 at naghihintay ng susunod na sagot ng user, na dapat ipadala pabalik ng gateway sa isang kasunod na kahilingan. Ang kasunod na kahilingang iyon ay kabilang sa parehong usapan ng pagpapatunay, hindi sa bagong pagtatangkang mag-log in.

Sa gumaganang setup, may nakikitang pangalawang prompt ang user: password muna, pagkatapos ay isang beses-gamitin na code, o isang pinagsamang prompt kung may naidokumento ang operator. Sa sirang setup, hindi kailanman lumilitaw ang pangalawang prompt at nabibigo lang ang pag-log in.

Iyon ang sintomas na dapat habulin, at madaling kumpirmahin mula sa panig ng kliyente lamang: kung humihingi ang VPN client ng eksaktong isang sikreto at pagkatapos ay tinatanggihan ang password na alam mong wasto, malamang natapos ang palitan sa hamon.

Ano ang talagang dinadala ng hamon

Inilalarawan ng espesipikasyon ng RADIUS ang code 11 sa seksyon 4.4 at pinapayagan ang dalawang attribute na mahalaga rito. Naglalaman ang Reply-Message ng tekstong para sa user, at naglalaman ang State ng malabong halaga na gustong makuha pabalik ng server. Hindi dapat bigyang-kahulugan ng NAS ang State, dapat lang itong ibalik nang walang pagbabago.

Gumagamit ang kasunod na kahilingan ng bagong Identifier at bagong Request Authenticator, at dapat nitong dalhin ang parehong halaga ng State at ang sagot ng user. Itinatapat ito ng server sa naghihintay na hamon sa pamamagitan ng State na iyon, kaya hindi makukumpleto ng gateway na muling gumagawa o nagtatapon ng attribute ang seremonya. Kailangan ding ma-validate ang response authenticator sa bawat sagot, kung hindi dapat itapon ng NAS ang packet.

Idinadagdag ng seksyon 4.4 ang detalyeng nagpapaliwanag sa karamihan ng tahimik na pagkabigo: itinuturing ng NAS na hindi kayang suportahan ang mga hamon ang Access-Challenge bilang pagtanggi. Kung mas luma kaysa sa suportang iyon ang serbisyo ng VPN ng iyong gateway o inaalis ito, nagiging agarang «nabigo ang pagpapatunay» ang kahilingan ng backend para sa pangalawang salik nang walang anumang prompt.

Saan nawawala ang kadena ng kahilingan

Ang unang pinaghihinalaan ay ang landas ng prompt, hindi ang kredensyal. Ang portal na nagpapakita ng OTP field para sa mga web login ay hindi awtomatikong gumagawa niyon para sa serbisyo ng VPN, at ang ilang gateway ay nagpapasa ng hamon lamang sa mga kliyenteng nagpapahayag ng kakayahang iyon. Subukan ang parehong account sa dalawang pasukan; kung gumagana ang portal at hindi ang VPN, ang tinitingnan mo ay ang paghahatid, hindi ang token.

Ang format ng input ang pangalawang pinaghihinalaan. Ang pagsasama ng password at code nang walang naidokumentong separator ng vendor, o pagpayag sa naka-save na kredensyal na i-replay ang lumang code, ay nabibigo sa paraang kamukhang-kamukha ng maling password. Gamitin ang naidokumentong hiwalay na prompt o pinagsamang format ng operator, at huwag kailanman mag-imbento ng delimiter.

May mga depektong partikular sa release, ngunit ang listahan ng naayos na bersyon mula sa mga nakaraang taon ay hindi diagnosis para sa deployment ngayon. Basahin ang release notes ng software na aktwal mong pinapatakbo, at itago ang naobserbahang yugto ng palitan bilang iyong ebidensya.

Subaybayan ang isang pagtatangka mula simula hanggang dulo

Ulitin ito nang isang beses, na bukas ang debugging sa panig ng server, at ilayo ang lahat ng iba pang session sa window ng paghuli:

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

Sa output, hanapin ang hugis ng usapan kaysa sa isang linya. Isang unang Access-Request na may Identifier 3, isang Access-Challenge na may dalang State, pagkatapos ay isang pangalawang Access-Request na may Identifier 4 na umuulit sa State na iyon at may kasamang sagot ng user. Kung wala ang pangalawang kahilingan, hindi kailanman sumunod ang gateway. Kung darating ito nang walang State, hindi ito maitatapat ng server sa naghihintay na hamon at karaniwang tinatanggihan.

Kapag ibinahagi ang trace, itago ang kredensyal, token, at hindi kailangang datos ng pagkakakilanlan, at iugnay ang mga kaganapan mula sa isang pagtatangka sa halip na paghalo-haluin ang mga pag-uulit mula sa maraming tab ng browser. Ang mga timestamp ay kaibigan mo rito; ang hamon na dumarating pagkatapos sumuko ng kliyente ay mukhang pagtanggi sa user at mabagal na sagot sa log.

Ang huling estadong gusto mo ay isang kumpleto at awtorisadong usapan, na sinusundan ng nilalayong pag-access sa serbisyo. Ang sagot na dumarating mula sa RADIUS server ay nagpapatunay ng higit na kaunti kaysa doon.