Kur OpenVPN pieteikšanās laikā nonāk statiskā izaicinājuma kods
Statiskais izaicinājums pievieno otru ievades lauku blakus parolei, un to atbalstošais klients abus var iesaiņot vienā kodētā laukā. Noskaidrojiet, kurā gadījumā esat.
Klients pēc paroles lauka rāda otru lodziņu, jūs ierakstāt kodu no aparatūras marķiera, un pieteikšanās joprojām neizdodas ar autentifikācijas kļūdu. Šis lodziņš pastāv, tātad profils to pieprasīja. Vai serveris kādreiz saņēma vērtību tādā formā, ko saprot, ir cits jautājums, un tieši uz to vispirms ir vērts atbildēt.
Sāciet ar uzvedni, ko jūsu klients patiešām rāda
Profils var saturēt statiskā izaicinājuma direktīvu ar uzvednes virkni un karodziņu, kas nosaka, vai atbilde tiek rādīta rakstīšanas laikā. Uzvedne ir tas, ko redzat dialogā; karodziņš ir tās pašas ievades attēlojuma iestatījums. Neviens no tiem nepasaka serverim, kā kaut ko pārbaudīt.
Saskaitiet laukus, kas jums patiešām tika doti. Viens lauks lietotājvārdam un viens maskēts lauks ir parasta paroles pieteikšanās bez jebkāda izaicinājuma. Otrs lauks, kas parādās pēc paroles ar savu apzīmējumu, ir klients, kas īsteno izaicinājuma mijiedarbību.
Ja otrais lodziņš nekad neparādās jūsu izmantotajā klientā, tas klients, iespējams, neīsteno mijiedarbību vai īsteno to tikai caur citu priekšgalu, piemēram, pārvaldības saskarni. Pārbaudīt klientu ir lētāk nekā pārrakstīt profilu, un parasti tieši tur arī ir neatbilstība.
Kas serverim jau jāatbalsta
Profils apraksta, kas klientam jāsavāc. Tas neieslēdz pārbaudi serverī, un serveris bez atbilstošas autentifikācijas integrācijas vienkārši saņems paroli, ko tas neatpazīst. Tāpēc daži izvietojumi rāda uzvedni un noraida katru kodu, un tāpēc operatora atbilde par to, kurš mehānisms veic pārbaudi, ir tā atbilde, kurai ir nozīme.
Pajautājiet operatoram, kurš mehānisms veic pārbaudi. Tas var būt spraudnis, kas sarunājas ar PAM, skripta āķis, kas pārbauda atbildi pret marķieru servisu, vai pārvaldībā balstīta integrācija, kas pati analizē iesaiņoto vērtību. Katrs no tiem gaida nedaudz citādu ievadi.
Šeit arī jākalibrē gaidītais. Otra uzvedne ir ievades mehānisms, nevis pierādījums, ka tiek piemērots otrs faktors, jo piemērošana notiek servera pusē un parādās tikai tad, kad pārbaudāt nepareizu kodu.
Kodētais lauks, ko sūta pārvaldības saskarne
Kad priekšgals vada savienojumu caur pārvaldības saskarni, parole un izaicinājuma atbilde pirms nosūtīšanas tiek iesaiņotas vienā vērtībā. Pārvaldības saskarnes uzziņa dokumentē formātu: prefikss, pēc tam parole un atbilde kā atsevišķas Base64 komponentes.
Base64 ir kodējums, nevis aizsardzība. Tas neko neslēpj no tā, kas var izlasīt lauku, un nepārvērš vienreizēju kodu kaut kā atkārtoti lietojamā. Iesaiņotā vērtība ir pelnījusi tādu pašu apiešanos kā parole: ārpus koplietotiem profiliem, ārpus komandrindām un ārpus diagnostikas žurnāliem.
Šis kodējums ir arī visbiežākais apjukuma avots, jo tagad ir trīs formas, kas izskatās līdzīgi un nav savstarpēji aizvietojamas. Vienkāršs akreditācijas datu fails satur paroli. Burtisks paroles un koda savienojums satur citu virkni. Pārvaldības klienta iesaiņotā atbilde satur trešo. Pirms mainīt lauku tikai tāpēc, ka kļūda pazuda, apstipriniet, kuru gaida jūsu pārbaudes ceļš.
Statiskais pret dinamisko: atšķirīgs laiks
Statiskais izaicinājums ir zināms pirms pirmo akreditācijas datu nosūtīšanas, tāpēc klients to var pieprasīt iepriekš. Dinamiskais izaicinājums pienāk vēlāk, to sūta autentifikācijas plūsma pēc tam, kad apmaiņa jau sākusies, un tam vajadzīgs klients, kas spēj apstrādāt pieprasījumu sarunas vidū.
Viena atbalsts nedod otru. Profila direktīva, kas iestata statisku uzvedni, neīsteno servera uzsāktu izaicinājumu, un priekšgals, kas apstrādā dinamiskus pieprasījumus, tomēr var nerādīt statisku. Lasīšana, kura puse uzsāka pieprasījumu, ir ātrākais veids, kā tos atšķirt.
Darbs bez uzraudzības ir vieta, kur tas kļūst par dizaina, nevis saskarnes jautājumu. Saglabāts kods nav ilgstoši lietojami palaišanas akreditācijas dati, un atkārtots savienojums pēc vairākām stundām prasīs svaigu ievadi, ja vien izvietojums neatbalsta marķieru kārtību, ko operators apzināti iespējojis.
Pārbaudiet gan panākumus, gan neveiksmi, ne tikai dialogu
Izpildiet abas testa puses. Pareizi akreditācijas dati ar derīgu atbildi drīkst izdoties; pareizi akreditācijas dati ar apzināti nepareizu atbildi ir jānoraida. Ja izdodas abi, klients vāc ievadi, ko nekas nepārbauda, un dialogs ir sajaukts ar vadīklu. Šis viens tests noķer vairāk izvietojumu nekā jebkura profila pārskatīšana.
Pēc tam atkārtojiet savienojumu pēc atkārtotas pievienošanās, ar kontu, kas nav reģistrēts, un caur to klientu, ko jūsu lietotāji patiešām lieto. Uzvednes parādīšanās ir klienta uzvedība; nepareiza koda noraidīšana ir serveris, kas kaut ko piemēro.