A seguito del cambiamento della legislazione riguardante i servizi fiduciari ("Sui servizi fiduciari elettronici" Ucraina), l'azienda ha ritenuto necessario che diversi reparti lavorassero con le chiavi memorizzate su token (al momento, il numero di chiavi hardware è ancora aperto).

Come strumento a costi minimi (senza costi) la scelta è ricaduta su usbip. Il server su Ubuntu 18.04 ha funzionato grazie alla pubblicazione Controlliamo USB/IP ed è stato testato con successo su diverse chiavette USB (dato che al momento non si disponeva di un token). Non ci sono stati problemi particolari, a parte il monopolio (riservato all'utente) in quel momento. È chiaro che per consentire l'accesso a più utenti (almeno due, per iniziare) è necessario suddividere l'accesso nel tempo e farli lavorare a turno.

Si pone la questione: come fare in modo che tutti possano lavorare con le minime complicazioni...

Parte grezza

E variante. Diverse scorciatoie per file bat, in particolare
a) Collegamento della chiave di accesso.
b) Disconnessione consapevole.

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

La peculiarità del client usbip è che dopo il suo avvio rimane attivo nella console, senza interrompere la sessione della console; la connessione può essere terminata "bruscamente" sia dal lato del client che da quello del server.

Ecco cosa ha funzionato correttamente per noi:

primo: connessione on.bat

usbip -a 172.16.12.26 4-1
msg * "Firma/token non disponibili o occupati"

secondo: disconnessione off.bat

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

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

on.bat | off.bat

Ecco il risultato: tutti i file si trovano nella stessa cartella; eseguendo il file token.bat, se la connessione viene chiusa dall'utente riceve immediatamente un messaggio di chiave non disponibile, altrimenti solo dopo 180 ping. Le righe di codice fornite possono essere arricchite con "@ECHO OFF" e reindirizzate nella console in "> nul" per non traumatizzare troppo l'utente, ma per l'esecuzione nei test non è necessario. La prima "esecuzione" su una chiavetta USB ha mostrato che tutto funziona in modo prevedibile, affidabile e preciso. Inoltre, dal lato del server non sono necessarie ulteriori manipolazioni.

Naturalmente, durante la lavorazione direttamente con il token, tutto è andato diversamente da quanto previsto: quando è collegato fisicamente nel gestore dispositivi, il token viene registrato come 2 dispositivi (WUDF e smart card), mentre in rete solo come WUDF (anche se per la richiesta del codice PIN questo è sufficiente).

È anche emerso che il brutale 'taskkill' non è poi così severo, e chiudere la connessione sul client è problematico e anche se ci si riesce, non garantisce la chiusura sul server.

Sacrificando tutte le console sul client, il secondo script è diventato:

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 ancora aperta.

I problemi di connessione hanno portato a considerare un aggiornamento della parte server.

Parte server

Cosa serve:

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

È stato deciso di affrontare queste attività utilizzando i servizi crontab e apache. La discrezionalità della registrazione dello stato dei risultati del monitoraggio dei punti 2 e 3 ci indica che il file system può essere posizionato su ramdrive. È stata aggiunta la riga nel /etc/fstab

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

È stata creata una cartella principale chiamata 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

ottenimento dell'elenco 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

ottenimento dell'elenco degli IP attivi (con successiva modifica per visualizzare gli identificatori degli 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 è collegata al server http tramite un symlink, in cui vengono salvati 2 file di testo che mostrano lo stato del server usbip.

Parte successiva: «Brutto nella confezione»

II opzione. Rendere un po' più piacevole l'interfaccia per gli utenti con qualcosa di meno spaventoso. Considerando che gli utenti hanno versioni di Windows diverse con framework e diritti diversi, non ho trovato un approccio meno problematico rispetto a questo. Lazarus Posso sicuramente consigliare C#, ma non in questo caso. È possibile eseguire file bat dall'interfaccia anche in background, minimizzati, ma senza un'adeguata prova, personalmente ritengo che sia necessario visualizzare per raccogliere i disagi degli utenti.

Sono stati risolti i seguenti compiti con l'interfaccia e la parte software:

1. Visualizzare se il token è attualmente occupato.
2. Al primo avvio, la configurazione iniziale con la generazione di file bat «corretti» per l'avvio e l'interruzione della sessione di lavoro con il server del token. Nei successivi avvi, implementazione della «modalità servizio» tramite password.
3. Controllo della connessione al server, i cui risultati vengono utilizzati per interrogarlo sulla disponibilità o visualizzare messaggi di problemi. Al ripristino della connessione, il programma inizia automaticamente a funzionare normalmente.

La gestione del server WEB è realizzata tramite un'estensione aggiuntiva fphttpclient.

ci sono anche ulteriori considerazioni sull'argomento dell'articolo, così come un'iniziale entusiastico apprezzamento per il prodotto VirtualHere e le sue caratteristiche...

Fonte: habr.com