Dėl pasitikėjimo paslaugų teisės aktų pasikeitimų („Apie elektronines pasitikėjimo paslaugas“ Ukraina), įmonei reikia kelių skyrių, kurie dirbtų su raktais, esančiais žetonuose (šiuo metu aparatinės įrangos raktų skaičiaus klausimas vis dar atviras ).

Kaip pigiausią įrankį (nemokamą), pasirinkimas iškart krito usbip. Publikacijos dėka Ubintu 18.04 serveris pradėjo veikti USB/IP prisijaukinimas ir sėkmingai išbandytas keliuose „flash drives“ (dėl to, kad tuo metu trūko žetono). Tuo metu nebuvo nustatyta jokių ypatingų problemų, išskyrus monopolinę nuosavybę (rezervavimas vartotojui). Akivaizdu, kad norint organizuoti prieigą keliems vartotojams (pradžioje bent dviem), būtina paskirstyti jų prieigą laiku ir priversti dirbti pakaitomis.

Klausimas buvo toks: kaip aš galiu tai padaryti su kuo mažiau šokių, kad viskas tiktų visiems...

Dalis nerangi

1 variantas. Keletas sparčiųjų klavišų į šikšnosparnių failus, būtent
a) Prieigos rakto prijungimas.
b) Sąmoningas atjungimas.

pastraipa "б» prieštaringa, todėl buvo nuspręsta duoti laiko dirbti su raktu 3 minutes.

Usbip kliento ypatumas yra tas, kad jį paleidus, jis lieka kaboti konsolėje, nenutraukiant konsolės seanso, galite „apytiksliai“ uždaryti ryšį iš kliento pusės ir taip pat iš serverio pusės.

Štai kas mums puikiai pasiteisino:

pirma: ryšys ant.šikšnosparnis

usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "

antra: išjungimas išjungti.šikšnosparnis

ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F

Nepasikliaujant vartotojo sąmone, scenarijai buvo sujungti į žetonas.šikšnosparnis

on.bat | off.bat

Kas atsitinka: visi failai yra tame pačiame aplanke, kurį paleido failas token.bat, nutraukus ryšį vartotojas iškart gauna pranešimą apie rakto nepasiekimą, kitu atveju tik po 180 pingų. Aukščiau pateiktose kodo eilutėse gali būti „@ECHO OFF“ ir konsolės kryptis į „> nul“, kad nebūtų per daug šokiruotas vartotojas, tačiau nebūtina atlikti testavimo. Pradinis „paleidimas“ USB atmintinėje parodė, kad viskas buvo nuspėjama, patikima ir aišku. Be to, nereikia jokių manipuliacijų iš serverio pusės.

Natūralu, kad dirbant tiesiogiai su žetonu viskas klostėsi ne taip, kaip tikėtasi: esant fiziniam ryšiui įrenginių tvarkyklėje, prieigos raktas registruojamas kaip 2 įrenginiai (WUDF ir intelektualioji kortelė), o prisijungus prie tinklo tik kaip WUDF (nors to pakanka norint paprašyti PIN kodo).

Taip pat pasirodo, kad žiaurus "taskkill" nėra toks rimtas, o ryšio nutraukimas klientui yra problemiškas ir net jei jis buvo sėkmingas, tai negarantuoja jo uždarymo serveryje.

Paaukojęs visas kliento konsoles, antrasis scenarijus įgavo tokią formą:

ping 127.0.0.1 -n 180 > nul
taskkill /IM usbip.exe /F /T  > nul
ping 127.0.0.1 -n 10 > nul
taskkill /IM conhost.exe /F /T  > nul

nors jo efektyvumas yra mažesnis nei 50%, nes serveris atkakliai ir toliau laikė ryšį atidarytu.

Ryšio problemos sukėlė minčių apie serverio pusės atnaujinimą.

Serverio dalis

Ką jums reikės:

1. Atjunkite neaktyvius vartotojus nuo paslaugos.
2. Pažiūrėkite, kas šiuo metu naudoja (ar vis dar skolinasi) žetoną.
3. Pažiūrėkite, ar tokenas yra prijungtas prie paties kompiuterio.

Šios problemos buvo išspręstos naudojant crontab ir apache paslaugas. Diskretus mus dominančių 2 ir 3 punktų stebėjimo rezultatų perrašymo pobūdis rodo, kad failų sistema gali būti ramiajame diske. Į /etc/fstab pridėta eilutė

tmpfs   /ram_drive      tmpfs   defaults,nodev,size=64K         0       0

Scenarijaus aplankas su scenarijais buvo sukurtas šaknyje: atjungimas-įjungimas prieigos raktas usb_restart.sh

usbip unbind -b 1-2
sleep 2
usbip bind -b 1-2
sleep 2
usbip attach --remote=localhost --busid=1-2
sleep 2
usbip detach --port=00

gauti aktyvių įrenginių sąrašą usblist_id.sh

usbip list -r 127.0.0.1 | grep ':' |awk -F ":" '{print $1}'| sed s/' '//g | grep -v "^$" > /ram_drive/usb_id.txt

gauti aktyvių IP sąrašą (su vėlesniais pakeitimais, kad būtų rodomi vartotojo ID) usbip_client_ip.sh

netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt

pats crontab atrodo taip:

*/5 * * * * /!script/usb_restart.sh > /dev/null 2>&1
* * * * * ( sleep 30 ; /!script/usblist_id.sh > /dev/null)
* * * * * (sleep 10 ; /!script/usbip_client_ip.sh > /dev/hull)

Taigi, mes turime: kas 5 minutes gali prisijungti naujas vartotojas, neatsižvelgiant į tai, kas dirbo su prieigos raktu. Aplankas /ramdrive yra prijungtas prie http serverio naudojant simbolinę nuorodą, kurioje yra išsaugoti 2 tekstiniai failai, rodantys usbip serverio būseną.

Kita dalis: „Bjaurusis įvyniojime“

II variantas. Norėdami šiek tiek pamaloninti vartotoją bent kiek mažiau bauginančia sąsaja. Glumina tai, kad vartotojai turi skirtingas Windows versijas su skirtingomis sistemomis, skirtingomis teisėmis, mažiau problemišku požiūriu nei Lozorius Aš jo neradau (aišku, aš už C#, bet ne šiuo atveju). Galite paleisti bat failus iš sąsajos fone, sumažindami, bet be tinkamo testavimo aš asmeniškai laikausi nuomonės: turite tai vizualizuoti, kad surinktumėte vartotojų nepasitenkinimą.

Sąsaja ir programinė įranga išsprendė šias užduotis:

1. Rodo, ar prieigos raktas šiuo metu užimtas.
2. Pirmą kartą paleidžiant, pradinė sąranka apima „teisingų“ šikšnosparnių failų generavimą, kurie įgyvendina seanso su žetonų serveriu paleidimą ir pertraukimą. Vėlesnių paleidimų metu „paslaugos“ režimo įgyvendinimas naudojant slaptažodį.
3. Tikrinama, ar yra ryšys su serveriu, dėl kurio jis apklausia, ar jis užimtas, ar rodo pranešimus apie problemas. Kai ryšys atnaujinamas, programa automatiškai pradeda veikti įprastu režimu.

Darbas su WEB serveriu įgyvendinamas naudojant papildomą fphttpclient priedą.

čia bus nuoroda į dabartinę kliento versiją

Taip pat yra papildomų svarstymų straipsnio tema, taip pat dalinis pradinis entuziazmas dėl VirtualHere produkto su jo funkcijomis...

Šaltinis: www.habr.com