Kam spada koda statičnega izziva pri prijavi v OpenVPN
Statični izziv doda drugo polje ob geslu, podporni odjemalec pa lahko oba spakira v eno kodirano polje. Ugotovite, v katerem primeru ste.
Odjemalec prikaže drugo polje za poljem z geslom, vnesete kodo s strojnega žetona, prijava pa še vedno spodleti z napako overjanja. To polje obstaja, torej ga je profil zahteval. Ali je strežnik vrednost kdaj prejel v obliki, ki jo razume, je drugo vprašanje, in prav nanj se je vredno najprej odzvati.
Začnite s pozivom, ki ga vaš odjemalec dejansko prikazuje
Profil lahko nosi direktivo statičnega izziva z nizom poziva in zastavico, ki nadzira, ali se odgovor prikaže med tipkanjem. Poziv je tisto, kar vidite v pogovornem oknu; zastavica je nastavitev prikaza za isti vnos. Nobeno od tega strežniku ne pove, kako kaj preveriti.
Preštejte polja, ki ste jih dejansko dobili. Eno polje za uporabniško ime in eno zakrito polje je običajna prijava z geslom brez vsakršnega izziva. Drugo polje, ki se pojavi po geslu z lastno oznako, je odjemalec, ki izvaja interakcijo izziva.
Če se drugo polje v odjemalcu, ki ga uporabljate, nikoli ne pojavi, ta odjemalec interakcije morda ne izvaja, ali pa jo izvaja le prek drugega vmesnika, na primer vmesnika za upravljanje. Preverjanje odjemalca je cenejše od prepisovanja profila in navadno se neskladje res skriva prav tam.
Kaj mora strežnik že podpirati
Profil opisuje, kaj naj odjemalec zbere. Ne omogoči preverjanja na strežniku, strežnik brez ustrezne integracije overjanja pa bo preprosto prejel geslo, ki ga ne prepozna. Zato nekatere namestitve prikažejo poziv in zavrnejo vsako kodo, in zato je odgovor operaterja o tem, kateri mehanizem opravi preverjanje, tisti, ki šteje.
Vprašajte operaterja, kateri mehanizem opravi preverjanje. To je lahko vtičnik, ki govori s PAM, skriptna kavelj, ki preveri odgovor pri storitvi žetonov, ali integracija na podlagi upravljanja, ki spakirano vrednost razčleni sama. Vsak od njih pričakuje nekoliko drugačen vnos.
Tu je treba umeriti tudi pričakovanja. Drugi poziv je vhodni mehanizem, ne dokaz, da se uveljavlja drugi dejavnik, ker se uveljavljanje zgodi na strani strežnika in se pokaže šele, ko preizkusite napačno kodo.
Kodirano polje, ki ga pošlje vmesnik za upravljanje
Ko sprednji del vodi povezavo prek vmesnika za upravljanje, se geslo in odgovor na izziv pred pošiljanjem spakirata v eno vrednost. Referenca vmesnika za upravljanje dokumentira obliko: predpona, nato geslo in odgovor kot ločene komponente Base64.
Base64 je kodiranje, ne zaščita. Ničesar ne skrije pred nekom, ki lahko prebere polje, in enkratne kode ne spremeni v nekaj večkrat uporabnega. Spakirana vrednost si zasluži enako obravnavo kot geslo: stran od skupnih profilov, stran od ukaznih vrstic in stran od diagnostičnih dnevnikov.
To kodiranje je tudi najpogostejši vir zmede, ker zdaj obstajajo tri oblike, ki so videti podobne in niso zamenljive. Preprosta datoteka s poverilnicami vsebuje geslo. Dobesedna združitev gesla in kode vsebuje drug niz. Spakiran odgovor odjemalca za upravljanje vsebuje tretjo. Preden spremenite polje samo zato, ker je napaka izginila, potrdite, katero od njih pričakuje vaša pot preverjanja.
Statično proti dinamičnemu: drugačen čas
Statični izziv je znan pred pošiljanjem prve poverilnice, zato ga odjemalec lahko zahteva vnaprej. Dinamični izziv prispe pozneje, pošlje ga potek overjanja po tem, ko se je izmenjava že začela, in potrebuje odjemalca, ki zmore obdelati zahtevo sredi pogovora.
Podpora za eno ne daje drugega. Direktiva profila, ki nastavi statični poziv, ne izvede izziva, ki ga sproži strežnik, sprednji del, ki obdeluje dinamične zahteve, pa morda še vedno ne prikaže statičnega. Branje, katera stran je zahtevo sprožila, je najhitrejši način, da jih ločite.
Delovanje brez nadzora je kraj, kjer to postane vprašanje zasnove in ne vmesnika. Shranjena koda ni trajna poverilnica ob zagonu, ponovna povezava čez ure pa bo zahtevala svež vnos, razen če namestitev podpira ureditev žetonov, ki jo je operater namerno omogočil.
Preizkusite uspeh in neuspeh, ne le pogovornega okna
Izvedite obe polovici preizkusa. Pravilne poverilnice z veljavnim odgovorom bi morale uspeti; pravilne poverilnice z namerno napačnim odgovorom bi morale biti zavrnjene. Če uspeta oba, odjemalec zbira vnos, ki ga nič ne preverja, in pogovorno okno je bilo zamenjano za kontrolo. Ta en preizkus ujame več namestitev kot kakršen koli pregled profila.
Nato ponovite povezavo po ponovnem povezovanju, z računom, ki ni vpisan, in prek odjemalca, ki ga vaši uporabniki dejansko poganjajo. Prikaz poziva je vedenje odjemalca; zavrnitev napačne kode je strežnik, ki nekaj uveljavlja.