Přihlášení k VPN se zasekne po Access-Challenge z RADIUS

Heslo je správné, přihlášení k VPN přesto selže a server RADIUS možná udělal přesně to, co mu bylo řečeno. Brána pravděpodobně dostala Access-Challenge, neukázala nic užitečného a pak vypršel čas nebo tuto odpověď považovala za odmítnutí. Z pohledu klienta to vypadá jako špatné přihlašovací údaje nebo rozbitý tunel. Příčina obvykle leží uprostřed konverzace, kterou nikdo nezachytil.

Jedno přihlášení, dvě výměny s RADIUS

Když backend chce druhý faktor, neodpovídá na první požadavek přijetím ani odmítnutím. Odpovídá kódem 11 a čeká na další odpověď uživatele, kterou musí brána poslat zpět v navazujícím požadavku. Tento navazující požadavek patří ke stejné autentizační konverzaci, ne k novému pokusu o přihlášení.

Ve funkčním nastavení uživatel vidí druhý dotaz: nejprve heslo, pak jednorázový kód, nebo jeden kombinovaný dotaz, pokud ho operátor zdokumentoval. V rozbitém nastavení se druhý dotaz nikdy neobjeví a přihlášení prostě selže.

To je příznak, který je třeba sledovat, a lze jej snadno potvrdit jen z pohledu klienta: pokud klient VPN žádá přesně jedno tajemství a poté odmítne heslo, o kterém víte, že je platné, výměna pravděpodobně skončila u výzvy.

Co výzva skutečně nese

Specifikace RADIUS popisuje kód 11 v části 4.4 a povoluje dva atributy, které zde hrají roli. Reply-Message nese text určený uživateli a State nese neprůhlednou hodnotu, kterou server chce vrátit. NAS nemá State interpretovat, jen jej vrátit beze změny.

Navazující požadavek používá nový Identifier a nový Request Authenticator a musí nést stejnou hodnotu State plus odpověď uživatele. Server jej přiřazuje k čekající výzvě právě přes tento State, a proto brána, která atribut znovu vytvoří nebo zahodí, nemůže obřad dokončit. Response authenticator v každé odpovědi musí také projít ověřením, jinak má NAS paket zahodit.

Část 4.4 dodává detail, který vysvětluje většinu tichých selhání: NAS, který neumí podporovat výzvy, považuje Access-Challenge za odmítnutí. Pokud služba VPN vaší brány tuto podporu nemá nebo ji vynechává, požadavek backendu na druhý faktor se změní na okamžité „autentizace selhala“ bez jakéhokoli dotazu.

Kde se řetězený požadavek ztrácí

Prvním podezřelým je cesta dotazu, ne přihlašovací údaj. Portál, který pro webová přihlášení zobrazuje pole OTP, to automaticky nedělá pro službu VPN, a některé brány předávají výzvu jen klientům, kteří tuto schopnost avizují. Otestujte stejný účet na obou vstupech; pokud portál funguje a VPN ne, díváte se na předání, ne na token.

Druhým podezřelým je formát vstupu. Spojení hesla a kódu bez výrobcem zdokumentovaného oddělovače nebo ponechání uložených údajů, aby přehrály starý kód, selhává způsobem, který vypadá stejně jako špatné heslo. Použijte operátorem zdokumentovaný samostatný dotaz nebo kombinovaný formát a nikdy nevymýšlejte vlastní oddělovač.

Defekty specifické pro vydání existují, ale seznam opravených verzí z dob dávno minulých není diagnózou pro dnešní nasazení. Čtěte poznámky k vydání softwaru, který skutečně provozujete, a jako důkaz si ponechte pozorovanou fázi výměny.

Sledujte jeden pokus od začátku do konce

Reprodukujte jej jednou se zapnutým laděním na straně serveru a všechny ostatní relace držte mimo zachytávané okno:

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

Ve výstupu hledejte tvar konverzace, ne jediný řádek. První Access-Request s Identifier 3, Access-Challenge nesoucí State, poté druhý Access-Request s Identifier 4, který tento State opakuje a obsahuje odpověď uživatele. Pokud druhý požadavek chybí, brána nikdy nenavázala. Pokud dorazí bez State, server jej nemůže přiřadit k čekající výzvě a obvykle jej odmítne.

Při sdílení trasování zredukujte přihlašovací údaje, tokeny a nepotřebné identitní údaje a korelujte události z jednoho pokusu místo míchání opakování z několika karet prohlížeče. Časová razítka jsou zde váš přítel; výzva, která dorazí poté, co klient vzdal, vypadá pro uživatele jako odmítnutí a v logu jako pomalá odpověď.

Konečný stav, který chcete, je dokončená, autorizovaná konverzace následovaná zamýšleným přístupem ke službě. Odpověď přicházející ze serveru RADIUS dokazuje mnohem méně.