Уваход у VPN завісае пасля Access-Challenge ад RADIUS

Пароль правільны, а ўваход у VPN усё роўна не адбываецца, і сервер RADIUS, магчыма, зрабіў менавіта тое, што яму было загадана. Шлюз, хутчэй за ўсё, атрымаў Access-Challenge, не паказаў нічога карыснага, а затым выйшаў па тайм-ауце або ўспрыняў гэты адказ як адмову. З боку кліента гэта выглядае як няправільныя ўліковыя даныя або зламаны тунель. Прычына звычайна знаходзіцца ў сярэдзіне размовы, якую ніхто не зафіксаваў.

Адзін уваход, два абмены з RADIUS

Калі бэкенд хоча другі фактар, ён не адказвае на першы запыт ні прыняццем, ні адмовай. Ён адказвае кодам 11 і чакае наступнага адказу карыстальніка, які шлюз павінен адправіць у паўторным запыце. Гэты паўторны запыт належыць да той жа размовы аўтэнтыфікацыі, а не да новай спробы ўваходу.

У працоўнай канфігурацыі карыстальнік бачыць другі запыт: спачатку пароль, затым аднаразовы код, або адзін аб’яднаны запыт, калі аператар яго дакументаваў. У зламанай канфігурацыі другі запыт не з’яўляецца зусім, і ўваход проста не адбываецца.

Гэта і ёсць сімптом, які трэба пераследаваць, і яго лёгка пацвердзіць толькі з боку кліента: калі кліент VPN запытвае роўна адзін сакрэт, а затым адхіляе пароль, пра які вы ведаеце, што ён слушны, абмен, верагодна, скончыўся на выкліку.

Што насамрэч нясе выклік

Спецыфікацыя RADIUS апісвае код 11 у раздзеле 4.4 і дапускае два атрыбуты, якія тут важныя. Reply-Message змяшчае тэкст, прызначаны карыстальніку, а State захоўвае непаразумелае значэнне, якое сервер хоча атрымаць назад. NAS не павінен інтэрпрэтаваць State, толькі вяртаць яго без змен.

Паўторны запыт выкарыстоўвае новы Identifier і новы Request Authenticator, і ён павінен несці тое ж значэнне State плюс адказ карыстальніка. Сервер супастаўляе яго з чаканым выклікам праз гэтае State, таму шлюз, які перастварае або адкідае атрыбут, не можа завяршыць цырымонію. Response authenticator у кожным адказе таксама павінен правярацца, інакш NAS павінен адкінуць пакет.

Раздзел 4.4 дадае дэталь, якая тлумачыць большасць маўклівых збояў: NAS, які не можа падтрымліваць выклікі, трактуе Access-Challenge як адмову. Калі VPN-служба вашага шлюза старэйшая за гэтую падтрымку або не мае яе, запыт бэкенда на другі фактар становіцца імгненным «памылка аўтэнтыфікацыі» без якога-небудзь запыту.

Дзе губляецца ланцуговы запыт

Першы падазроны — гэта шлях запыту, а не ўліковыя даныя. Партал, які паказвае поле OTP для вэб-уваходаў, не робіць гэтага аўтаматычна для VPN-службы, і некаторыя шлюзы перадаюць выклік толькі кліентам, якія заяўляюць гэтую магчымасць. Праверце той жа ўліковы запіс на абодвух пунктах уваходу; калі партал працуе, а VPN не, вы глядзіце на перадачу, а не на токен.

Фармат уводу — другі падазроны. Злучэнне пароля і кода без дакументаванага вытворцам раздзяляльніка або дазвол захаваным уліковым даным паўтараць стары код няўдаецца так, што выглядае ідэнтычна няправільнаму паролю. Выкарыстоўвайце дакументаваны аператарам асобны запыт або аб’яднаны фармат і ніколі не выдумляйце раздзяляльнік.

Дэфекты, спецыфічныя для выпуску, існуюць, але спіс выпраўленых версій шматгадовай даўніны не з’яўляецца дыягназам для сённяшняга разгортвання. Чытайце заўвагі да выпуску праграмы, якую вы насамрэч выкарыстоўваеце, і трымайце назіраную стадыю абмену як доказ.

Прасочыце адну спробу ад пачатку да канца

Аднавіце адзін раз з уключанай адладкай на баку сервера і трымайце ўсе іншыя сесіі па-за акном захопу:

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

У вывадзе шукайце форму размовы, а не адзін радок. Першы Access-Request з Identifier 3, Access-Challenge, які нясе State, затым другі Access-Request з Identifier 4, які паўтарае гэтае State і ўключае адказ карыстальніка. Калі другога запыту няма, шлюз ніколі не зрабіў паўтор. Калі ён прыходзіць без State, сервер не можа супаставіць яго з чаканым выклікам і звычайна адхіляе.

Выдаляйце ўліковыя даныя, токены і непатрэбныя даныя асобы, калі дзеліцеся трасіроўкай, і карэлюйце падзеі з адной спробы, а не змешвайце паўторы з некалькіх браўзерных укладак. Часавыя меткі тут ваш сябар; выклік, які прыходзіць пасля таго, як кліент здаўся, выглядае для карыстальніка як адмова, а ў журнале — як павольны адказ.

Патрэбны вам завершаны стан — гэта завершаная, аўтарызаваная размова, за якой ідзе прадугледжаны доступ да службы. Адказ, які прыходзіць ад сервера RADIUS, даказвае значна менш.