Partajarea în rețea a unui token criptografic între utilizatorii bazați pe usbip

În legătură cu modificările aduse legislației privind serviciile de încredere („Despre serviciile electronice de încredere” Ucraina), întreprinderea are nevoie de mai multe departamente să lucreze cu chei situate pe jetoane (în acest moment, problema numărului de chei hardware este încă deschisă ).

Ca instrument cu cel mai mic cost (gratuit), alegerea a căzut imediat usbip. Serverul de pe Ubintu 18.04 a început să funcționeze datorită publicației Îmblanzirea USB/IP și testat cu succes pe mai multe unități flash (din cauza lipsei unui token la acel moment). La acel moment nu au fost identificate probleme speciale, altele decât deținerea monopolului (rezervarea pentru utilizator). Este clar că pentru a organiza accesul pentru mai mulți utilizatori (cel puțin doi, pentru început), este necesar să le împărțim în timp accesul și să-i forțezi să lucreze pe rând.

Întrebarea a fost: Cum pot să fac asta cu cât mai puțin dans, astfel încât totul să funcționeze pentru toată lumea...

Partea este neîndemânatică

Partajarea în rețea a unui token criptografic între utilizatorii bazați pe usbip
Opțiunea XNUMX. Mai multe comenzi rapide către fișierele bat, și anume
a) Conectarea cheii de acces.
b) Deconectarea în mod deliberat.

Paragraful "б» controversat, așa că s-a decis să se acorde timpul de lucru cu cheia la 3 minute.

Particularitatea clientului usbip este că după ce este lansat, acesta rămâne agățat în consolă; fără a întrerupe sesiunea consolei, puteți închide „aproximativ” conexiunea din partea clientului și, de asemenea, din partea serverului.

Iată ce a funcționat bine pentru noi:

primul: conexiune pe.bat

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

a doua: oprire off.bat

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

Fără a ne baza pe conștiința utilizatorului, scripturile au fost combinate în jeton.bat

on.bat | off.bat

Ce se întâmplă: toate fișierele sunt în același folder, lansat de fișierul token.bat, dacă conexiunea este închisă utilizatorul primește imediat un mesaj despre indisponibilitatea cheii, în alt caz, abia după 180 de ping-uri. Liniile de cod de mai sus pot fi echipate cu „@ECHO OFF” și direcția consolei către „> nul” pentru a nu șoca prea mult utilizatorul, dar nu este necesar să rulați testarea. „Rularea” inițială pe o unitate USB a arătat că totul era previzibil, fiabil și clar. În plus, nu sunt necesare manipulări din partea serverului.

Partajarea în rețea a unui token criptografic între utilizatorii bazați pe usbip

Desigur, atunci când lucrați direct cu jetonul, totul nu a decurs așa cum era de așteptat: cu o conexiune fizică în managerul de dispozitive, jetonul este înregistrat ca 2 dispozitive (WUDF și un smart card), iar cu o conexiune la rețea doar ca WUDF (deși este suficient pentru a solicita un cod PIN).

Partajarea în rețea a unui token criptografic între utilizatorii bazați pe usbip

De asemenea, se dovedește că brutalul „taskkill” nu este atât de sever, iar închiderea conexiunii la client este problematică și chiar dacă a avut succes, nu garantează închiderea acesteia pe server.

După ce a sacrificat toate consolele de pe client, al doilea script a luat forma:

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

deși eficiența sa este mai mică de 50%, din moment ce serverul a continuat să considere conexiunea deschisă cu încăpățânare.

Problemele cu conexiunea au dus la gânduri despre actualizarea părții server.

Partea serverului

Ce aveți nevoie de:

  1. Deconectați utilizatorii inactivi de la serviciu.
  2. Vedeți cine utilizează (sau încă împrumută) tokenul.
  3. Vedeți dacă jetonul este conectat la computerul însuși.

Aceste probleme au fost rezolvate folosind serviciile crontab și apache. Natura discretă a rescrierii stării rezultatelor monitorizării punctelor 2 și 3 care ne interesează indică faptul că sistemul de fișiere poate fi localizat pe ramdrive. Linia adăugată la /etc/fstab

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

În rădăcină a fost creat un folder de scripturi cu scripturi: unmounting-mounting the token 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

obținerea unei liste de dispozitive active 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

obținerea unei liste de IP-uri active (cu modificarea ulterioară pentru afișarea ID-urilor de utilizator) usbip_client_ip.sh

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

crontab-ul în sine arată astfel:

*/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)

Deci avem: la fiecare 5 minute se poate conecta un nou utilizator, indiferent cine a lucrat cu tokenul. Folderul /ramdrive este conectat la serverul http folosind un link simbolic, în care sunt salvate 2 fișiere text, care arată starea serverului usbip.

Partea următoare: „Urât într-un ambalaj”

Opțiunea II. Pentru a mulțumi puțin utilizatorul cu cel puțin o interfață mai puțin intimidantă. Nedumerit de faptul că utilizatorii au versiuni diferite de Windows cu cadre diferite, drepturi diferite, o abordare mai puțin problematică decât Lazăr Nu l-am găsit (desigur că sunt pentru C#, dar nu în acest caz). Puteți lansa fișiere bat din interfață în fundal, minimizate, dar fără testare adecvată, eu personal sunt de părere: trebuie să le vizualizați pentru a colecta nemulțumirile utilizatorilor.

Partajarea în rețea a unui token criptografic între utilizatorii bazați pe usbip

Următoarele sarcini au fost rezolvate de interfață și software:

  1. Afișează dacă jetonul este ocupat în prezent.
  2. La prima lansare, configurarea inițială presupune generarea fișierelor bat „corecte” care implementează lansarea și întreruperea unei sesiuni cu serverul de token. La pornirile ulterioare, implementarea modului „serviciu” folosind o parolă.
  3. Verificarea prezenței unei conexiuni cu serverul, în urma căreia interoghează dacă este ocupat sau afișează mesaje despre probleme. Când comunicarea este reluată, programul începe automat să funcționeze în modul normal.

Lucrul cu serverul WEB este implementat utilizând snap-in-ul suplimentar fphttpclient.


aici va fi un link către versiunea curentă a clientului

Există, de asemenea, considerații suplimentare cu privire la subiectul articolului, precum și entuziasm inițial parțial pentru produsul VirtualHere cu caracteristicile sale...

Sursa: www.habr.com

Adauga un comentariu