Kodėl redaguojant .ovpn failą MFA serveryje neįsijungia

Pridedate auth-user-pass prie profilio, prisijungiate iš naujo, ir klientas prašo vartotojo vardo bei slaptažodžio. Atrodo, kad MFA įjungtas. Tada įvedate kodą iš neteisingos paskyros arba kodą, kurio galiojimas baigėsi prieš dešimt minučių, o tunelis vis tiek pakyla. Tai simptomas: klientas pasikeitė, serveris – ne. Vienkartinis slaptažodis yra veiksnys tik tada, kai serverio tikrintojas nusprendžia, ar jis galioja tapatybei, kuri jo reikalauja.

Užklausa įrodo tik tai, kad klientas paprašė, ir nieko daugiau

.ovpn failas yra kliento pusės dokumentas. Jis gali liepti klientui prašyti prisijungimo duomenų, saugoti juos talpykloje arba nustoti tai daryti. Jis negali užregistruoti vartotojo, įdiegti PAM modulio ar priversti serverį reikalauti antrojo veiksnio, kurio jis dabar netikrina.

Autentifikavimo programėlės įdiegimas telefone taip pat nesukuria šio ryšio. Google Authenticator PAM projektas yra OTP tikrinimo komponentas, kuris gali stovėti už OpenVPN; tai nėra būdas priklijuoti Google paskyros prisijungimą prie importuoto profilio.

Registracija yra ta dalis, kurios profilis negali atlikti

TOTP reikia registracijos medžiagos, bendros autentifikavimo programėlei ir jos tikrintojui. Šeši skaitmenys telefone yra išvestis; už jų esanti sėkla yra paslaptis, ir ji priklauso vienai tapatybei.

Todėl operatoriui reikia registracijos proceso, kuris susieja tinkamą sėklą su tinkama VPN tapatybe, be to, patikrinto pakeitimo kelio pamestam telefonui. Leidus vartotojams įkelti failą, pavadintą jų vardu, registracija tampa paskyros užgrobimo galimybe, o įkėlimo šifravimas to nekeičia.

PAM pagrindu sukurtas sprendimas neprivalo kurti atskiros Unix paskyros kiekvienam VPN vartotojui. Modulio dokumentacija palaiko alternatyvius slaptųjų raktų kelius ir atskirą paskyrą failų prieigai, o tai yra failų sistemos tapatybė, o ne tikrinama prisijungimo tapatybė.

Įprasta klaida – fiksuotas slaptasis kelias, pasibaigiantis vienu vartotojo vardu, nukopijuotas iš vieno vartotojo pavyzdžio. Tai vienos tapatybės demonstracija, o ne paieška pagal vartotoją, ir naudojant jį kiekvienai užklausai niekas negauna nepriklausomai užregistruotos autentifikavimo programėlės. Užsirašykite tapatybių susiejimą, apsaugokite sėklų failus ir laikykite slaptažodžio, sertifikato ir paskyros patikras tame pačiame autentifikavimo kamiene.

Perskaitykite PAM kamieną ir pažiūrėkite, ko iš tikrųjų reikalaujama

Eilutė kaip account required pam_permit.so neįgyvendina paskyros tinkamumo ir neprideda veiksnio. Ji leidžia tą PAM paskyrų valdymo etapą, o tai yra teiginys apie etapą, o ne apie jūsų vartotojus.

Tas pats galioja ir leidiems registracijos parametrams. Vartotojų be užregistruotos sėklos priėmimas gali būti sąmoningas diegimo sprendimas, bet tai neįrodo, kad MFA yra privalomas, ir tai turėtų būti užrašyta kaip laikina išimtis su pabaigos data.

Suderinkite kliento sąveiką su serverio dizainu

auth-user-pass

Ši direktyva prašo įvesti vartotojo vardą ir slaptažodį. Ji nesukonfigūruoja PAM, nesukuria registracijos įrašo ir nepasako serveriui, kad slaptažodžio lauke yra TOTP reikšmė. Serverio integracija ir klientas turi susitarti dėl sąveikos, kurią diegimas iš tikrųjų palaiko: iššūkis, dokumentuotas sujungtas prisijungimo duomenų formatas arba produktui būdingas srautas.

Nepridėkite kodo prie slaptažodžio vien todėl, kad klientas rodo vieną lauką. Tai veikia tik ten, kur serverio papildinys tikisi būtent tokio formato, o visur kitur nepavyksta klaidinančiai.

Laikykite sėklas ir QR medžiagą atokiau nuo bendrų profilių ir įprastų diagnostikos žurnalų. Kodas, pateiktas autentifikuotu prisijungimo kanalu, nėra tas pats objektas kaip sėkla, išduota kontroliuojamos registracijos metu, o jų sumaišymas pagalbos biliete yra kelias, kuriuo paslaptys ištrūksta.

Prisijungimai iš naujo, raktai ir testas, kuris viską išsprendžia

Suplanuokite, kas nutinka po pirmo sėkmingo prisijungimo. Anksčiau priimtas kodas gali būti pasibaigęs arba atmestas kaip kartojimas per kitą autentifikavimą. auth-nocache kontroliuoja prisijungimo duomenų saugojimą ir neįdiegia MFA, o reneg-sec 0 nėra TOTP palaikymo apibrėžimas, kad ir kaip dažnai jis pasirodytų forumo temose.

Kai kurie diegimai po pradinės patikros išduoda autentifikavimo raktus, kad prisijungimai iš naujo neprašytų dar kartą. Tai dizaino sprendimas su savo galiojimo laiku ir atšaukimo istorija, o ne numatytoji reikšmė, kurią paveldite.

Tada išbandykite priėmimo politiką su klientu, kurį žmonės iš tikrųjų naudoja. Užregistruotas vartotojas su teisingu slaptažodžiu, sertifikatu ir dabartiniu kodu turėtų prisijungti. Neteisingas kodas, vartotojas be registracijos ir uždrausta paskyra turėtų kiekvienas nepavykti, o priežastis turėtų būti matoma serverio žurnale. Kol nepamatėte tų atmetimų, turite užklausą, o ne politiką.