A causa della modifica della legislazione riguardante i servizi fiduciari ( "Sui servizi fiduciari elettronici" Ucraina), si è resa necessaria la collaborazione di diversi reparti con le chiavi situate sui token (al momento, la questione sul numero di chiavi hardware è ancora aperta).

Come strumento con il minor costo possibile (gratuitamente) la scelta è caduta immediatamente su usbip. Il server su Ubuntu 18.04 ha funzionato grazie alla pubblicazione Domiamo USB/IP ed è stato testato con successo su diverse chiavette USB (in mancanza di token al momento). Non sono state riscontrate particolari problematiche, eccetto la proprietà monopolistica (riservata a un utente) in quel momento. È chiaro che per organizzare l'accesso a più utenti (almeno due, per iniziare) è necessario dividere il loro accesso nel tempo e farli lavorare a turno.

È emersa la domanda: come fare in modo che tutti possano lavorare con il minor fastidio possibile...

Parte grezza

Opzione I. Diversi collegamenti a file bat, in particolare
a) Collegamento della chiave di accesso.
b) Disattivazione consapevole.

Il punto "b" è controverso, quindi è stato deciso di dare un tempo di lavoro con la chiave di 3 minuti.

Una particolarità del client usbip è che una volta avviato rimane attivo nella console, senza interrompere la sessione della console è possibile chiudere la connessione "brutalmente" dal lato del client e anche dal lato del server.

Ecco cosa ha funzionato correttamente:

primo: collegamento on.bat

usbip -a 172.16.12.26 4-1
msg * "La firma/token non è disponibile o è occupata"

secondo: disconnessione off.bat

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

non fidandosi della coscienza dell'utente, gli script sono stati uniti in token.bat

on.bat | off.bat

Cosa succede: tutti i file si trovano in una sola cartella, eseguendo il file token.bat, se la connessione è chiusa dall'utente appare immediatamente un messaggio di chiave non disponibile, nell'altro caso, solo dopo 180 ping. Le righe di codice fornite possono essere dotate di "@ECHO OFF" e di reindirizzamento della console in "> nul" per non scioccare troppo l'utente, ma per l'avvio per i test non è necessario. La prima "prova" su una chiavetta USB ha mostrato che tutto funziona in modo prevedibile, affidabile e preciso. Inoltre, dal lato del server non sono necessarie manipolazioni.

Naturalmente, durante il lavoro direttamente con il token, le cose non sono andate come previsto: collegandolo fisicamente nel gestore dispositivi, il token viene registrato come 2 dispositivi (WUDF e smart card) mentre in rete solo come WUDF (anche se questo è sufficiente per richiedere il PIN).

Si è anche scoperto che il brutale «taskkill» non è così severo, e la chiusura della connessione sul client è problematica e anche se ci si riesce, non garantisce la chiusura della stessa sul server.

Dopo aver sacrificato tutti i terminali sul client, il secondo script è apparso così:

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

anche se la sua efficacia è inferiore al 50%, poiché il server continuava a considerare la connessione non chiusa.

I problemi di connessione hanno portato a riflessioni su un upgrade nella parte server.

Parte server

Cosa serve:

1. Disconnettere gli utenti inattivi dal servizio.
2. Vedere chi sta attualmente utilizzando (o occupando) il token.
3. Controllare se il token è collegato al computer.

Queste problematiche sono state affrontate utilizzando i servizi crontab e apache. La discrezionalità nella riscrittura dello stato dei risultati di monitoraggio dei punti 2 e 3 ci suggerisce che il filesystem può essere posizionato su ramdrive. Nel /etc/fstab è stata aggiunta la riga

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

Nella radice è stata creata una cartella script con gli script: smontaggio-montaggio del 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

ottenere la lista dei dispositivi attivi 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

ottenere la lista degli IP attivi (con successiva integrazione per la visualizzazione degli identificatori utenti) usbip_client_ip.sh

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

il crontab stesso appare così:

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

Quindi abbiamo: ogni 5 minuti può connettersi un nuovo utente, indipendentemente da chi ha lavorato con il token. La cartella /ramdrive a cui si accede tramite un symlink salva 2 file di testo, mostrando lo stato del server usbip.

Parte successiva: «Brutto nella confezione»

II opzione. Rendere l'interfaccia utente un po' meno intimidatoria per gli utenti. Tenendo conto che gli utenti hanno versioni diverse di Windows con vari framework e diritti, non ho trovato un approccio meno problematico rispetto a Lazarus (naturalmente sarei a favore di C#, ma non in questo caso). È possibile eseguire file .bat dall'interfaccia anche in background, ridotti a icona, ma senza un'adeguata sperimentazione, personalmente ritengo sia necessario visualizzare per raccogliere i malcontenti degli utenti.

L'interfaccia e la parte software hanno risolto i seguenti compiti:

1. Mostrare se un token è attualmente occupato.
2. Al primo avvio, si realizza una configurazione iniziale con la generazione di file .bat 'corretti' che realizzano l'avvio e l'interruzione della sessione di lavoro con il server del token. Nei successivi avvii, viene implementata la 'modalità servizio' tramite password.
3. Controllo della connessione al server, i cui risultati determinano l'interrogazione della sua disponibilità o la visualizzazione di messaggi di errore. Al ripristino della connessione, il programma riprende automaticamente a funzionare normalmente.

Il lavoro con il server WEB è stato implementato utilizzando il componente aggiuntivo fphttpclient.

c'è anche un proseguimento delle considerazioni relative all'argomento dell'articolo, così come una parziale iniziale entusiamsmo per il prodotto VirtualHere con le sue peculiarità...

Fonte: habr.com