Ku shkon kodi i sfidës statike në një hyrje OpenVPN

Klienti shfaq një kuti të dytë pas fushës së fjalëkalimit, ju shkruani kodin nga shenja e harduerit, dhe hyrja vazhdon të dështojë me një gabim vërtetimi. Ajo kuti ekziston, pra profili e kërkoi. Nëse serveri e mori ndonjëherë vlerën në një formë që e kupton është pyetje tjetër, dhe është ajo që ia vlen të përgjigjesh së pari.

Filloni nga kërkesa që klienti juaj shfaq vërtet

Një profil mund të mbajë një direktivë sfide statike me një varg kërkese dhe një flamur që kontrollon nëse përgjigjja shfaqet ndërsa shkruani. Kërkesa është ajo që shihni në dialog; flamuri është një preferencë shfaqjeje për të njëjtin hyrje. Asnjëri prej tyre nuk i thotë serverit si të verifikojë diçka.

Numëroni fushat që ju janë dhënë vërtet. Një fushë për emrin e përdoruesit plus një fushë e maskuar është një hyrje normale me fjalëkalim pa asnjë sfidë. Fusha e dytë që shfaqet pas fjalëkalimit, me etiketën e vet, është klienti që zbaton ndërveprimin e sfidës.

Nëse kutia e dytë nuk shfaqet kurrë në klientin që përdorni, ai klient mund të mos e zbatojë ndërveprimin, ose ta zbatojë vetëm përmes një fronti tjetër si një ndërfaqe administrimi. Kontrollimi i klientit kushton më pak se rishkrimi i profilit, dhe zakonisht aty është në të vërtetë mospërputhja.

Çfarë duhet të mbështesë tashmë serveri

Profili përshkruan çfarë duhet të mbledhë klienti. Nuk aktivizon verifikimin në server, dhe një server pa integrimin përkatës të vërtetimit thjesht do të marrë një fjalëkalim që nuk e njeh. Kjo është arsyeja pse disa vendosje shfaqin kërkesën dhe refuzojnë çdo kod, dhe pse përgjigjja e operatorit për mekanizmin që kryen kontrollin është ajo që ka rëndësi.

Pyetni operatorin cili mekanizëm kryen kontrollin. Mund të jetë një shtojcë që flet me PAM, një grep skripti që vërteton përgjigjjen kundrejt një shërbimi shenjash, ose një integrim i bazuar në administrim që e analizon vetë vlerën e paketuar. Secili prej tyre pret një hyrje pak të ndryshme.

Këtu duhen kalibruar edhe pritshmëritë. Kërkesa e dytë është një mekanizëm hyrjeje, jo provë që zbatohet një faktor i dytë, sepse zbatimi ndodh në anën e serverit dhe duket vetëm kur testoni një kod të gabuar.

Fusha e koduar që dërgon ndërfaqja e administrimit

Kur një front e drejton lidhjen përmes ndërfaqes së administrimit, fjalëkalimi dhe përgjigjja e sfidës paketohen në një vlerë të vetme përpara dërgimit. Referenca e ndërfaqes së administrimit dokumenton formatin: një parashtesë, pastaj fjalëkalimi dhe përgjigjja si komponentë të veçantë Base64.

Base64 është kodim, jo mbrojtje. Nuk fsheh asgjë nga kushdo që mund ta lexojë fushën, dhe nuk e kthen një kod njëpërdorimësh në diçka të ripërdorshme. Vlera e paketuar meriton të njëjtin trajtim si fjalëkalimi: jashtë profileve të përbashkëta, jashtë rreshtave të komandës dhe jashtë regjistrave diagnostikues.

Ky kodim është gjithashtu burimi më i zakonshëm i konfuzionit, sepse tani ekzistojnë tre forma që duken të ngjashme dhe nuk janë të këmbyeshme. Një skedar i thjeshtë kredencialesh mban një fjalëkalim. Një bashkim literal i fjalëkalimit dhe kodit mban një varg tjetër. Përgjigjja e paketuar e një klienti administrimi mban të tretën. Konfirmoni cilën pret rruga juaj e verifikimit përpara se të ndryshoni një fushë vetëm sepse një gabim u zhduk.

Statike kundrejt dinamike: kohë të ndryshme

Një sfidë statike dihet përpara se të dorëzohet kredenciali i parë, kështu që klienti mund ta kërkojë paraprakisht. Një sfidë dinamike vjen më vonë, e dërguar nga rrjedha e vërtetimit pasi një shkëmbim ka filluar tashmë, dhe kërkon një klient që mund të trajtojë një kërkesë në mes të bisedës.

Mbështetja për njërën nuk jep tjetrën. Një direktivë profili që konfiguron një kërkesë statike nuk zbaton një sfidë të nisur nga serveri, dhe një front që trajton kërkesa dinamike mund të mos shfaqë ende një statike. Leximi i asaj se cila anë e nisi kërkesën është mënyra më e shpejtë për t’i dalluar.

Funksionimi pa mbikëqyrje është pika ku kjo bëhet çështje dizajni dhe jo çështje ndërfaqeje. Një kod i ruajtur nuk është kredencial i qëndrueshëm në nisje, dhe një rilidhje orë më vonë do të kërkojë hyrje të re, përveç nëse vendosja mbështet një rregullim shenjash që operatori e ka aktivizuar me qëllim.

Testoni suksesin dhe dështimin, jo vetëm dialogun

Ekzekutoni të dyja gjysmat e testit. Kredencialet e sakta me një përgjigje të vlefshme duhet të kalojnë; kredencialet e sakta me një përgjigje qëllimisht të gabuar duhet të refuzohen. Nëse të dyja kalojnë, klienti po mbledh hyrje që asgjë nuk e verifikon, dhe dialogu është marrë për një kontroll. Ai test i vetëm kap më shumë vendosje sesa çdo rishikim profili.

Pastaj përsëritni lidhjen pas një rilidhjeje, me një llogari që nuk është regjistruar, dhe përmes klientit që përdoruesit tuaj ekzekutojnë vërtet. Shfaqja e kërkesës është sjellje e klientit; refuzimi i një kodi të gabuar është serveri që zbaton diçka.