In connessione con i cambiamenti nella legislazione relativa ai servizi fiduciari (“Informazioni sui servizi fiduciari elettronici” Ucraina), l'impresa ha bisogno che diversi dipartimenti lavorino con le chiavi situate sui token (al momento, la questione del numero di chiavi hardware è ancora aperta ).

Trattandosi di uno strumento dal costo più basso (gratuito), la scelta è caduta subito usip. Il server su Ubintu 18.04 ha iniziato a funzionare grazie alla pubblicazione Domare USB/IP e testato con successo su diverse unità flash (a causa della mancanza di un token in quel momento). In quel momento non furono individuati problemi particolari oltre alla proprietà di monopolio (prenotazione per l'utente). È chiaro che per organizzare l'accesso di più utenti (almeno due, per cominciare), è necessario suddividere i loro accessi nel tempo e obbligarli a lavorare a turno.

La domanda era: come posso farlo con il minor numero di balli in modo che tutto funzioni per tutti...

La parte è goffa

opzione XNUMX. Diverse scorciatoie per i file bat, vale a dire
a) Collegamento della chiave di accesso.
b) Disconnettersi deliberatamente.

Paragrafo "б» controverso, quindi si è deciso di dare il tempo per lavorare con la chiave a 3 minuti.

La particolarità del client usbip è che una volta avviato rimane sospeso nella console; senza interrompere la sessione della console è possibile chiudere “grossolanamente” la connessione sia dal lato client che dal lato server.

Ecco cosa ha funzionato bene per noi:

primo: connessione on.bat

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

secondo: spegnimento off.bat

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

Senza fare affidamento sulla coscienza dell'utente, gli script sono stati combinati in token.bat

on.bat | off.bat

Cosa succede: tutti i file sono nella stessa cartella, lanciata dal file token.bat, se la connessione viene chiusa l'utente riceve immediatamente un messaggio di non disponibilità della chiave, in un altro caso solo dopo 180 ping. Le righe di codice sopra possono essere dotate di "@ECHO OFF" e la direzione della console su "> nul" per non scioccare troppo l'utente, ma non è necessario eseguire test. La “corsa” iniziale su un’unità USB ha dimostrato che tutto era prevedibile, affidabile e chiaro. Inoltre, non sono necessarie manipolazioni da parte del server.

Naturalmente, lavorando direttamente con il token, tutto non è andato come previsto: con una connessione fisica in Gestione dispositivi, il token viene registrato come 2 dispositivi (WUDF e una smart card), e con una connessione di rete solo come WUDF (sebbene questo è sufficiente per richiedere un codice PIN).

Si scopre anche che il brutale "taskkill" non è così grave, e chiudere la connessione sul client è problematico e anche se ha avuto successo, non garantisce la sua chiusura sul server.

Dopo aver sacrificato tutte le console sul client, il secondo script ha preso la 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

nonostante la sua efficacia sia inferiore al 50%, poiché il server continuava ostinatamente a considerare aperta la connessione.

Problemi con la connessione hanno portato a pensare all'aggiornamento del lato server.

Parte server

Quello che vi serve:

1. Disconnettere gli utenti inattivi dal servizio.
2. Scopri chi sta attualmente utilizzando (o sta ancora prendendo in prestito) il token.
3. Verifica se il token è collegato al computer stesso.

Questi problemi sono stati risolti utilizzando i servizi crontab e apache. La natura discreta della riscrittura dello stato dei risultati del monitoraggio dei punti 2 e 3 che ci interessano indica che il file system può essere localizzato sul ramdrive. Aggiunta riga a /etc/fstab

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

Nella root è stata creata una cartella di script con gli script: unmounting-mounting 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 un elenco di 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 un elenco di IP attivi (con successiva modifica per visualizzare gli ID utente) 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 assomiglia a questo:

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

Quindi abbiamo: ogni 5 minuti un nuovo utente può connettersi, indipendentemente da chi ha lavorato con il token. La cartella /ramdrive è connessa al server http tramite un collegamento simbolico, in cui vengono salvati 2 file di testo, che mostrano lo stato del server usbip.

Parte successiva: “Brutto in un involucro”

Opzione II. Per compiacere un po' l'utente con almeno un'interfaccia meno intimidatoria. Perplesso dal fatto che gli utenti abbiano versioni diverse di Windows con framework diversi, diritti diversi e un approccio meno problematico rispetto a Lazarus Non l'ho trovato (ovviamente sono per C#, ma non in questo caso). Puoi avviare file bat dall'interfaccia in background, ridotti a icona, ma senza test adeguati, personalmente sono dell'opinione: devi visualizzarlo per raccogliere l'insoddisfazione dell'utente.

I seguenti compiti sono stati risolti dall'interfaccia e dal software:

1. Visualizza se il token è attualmente occupato.
2. Al primo avvio, il setup iniziale prevede la generazione dei file bat “corretti” che implementano l’avvio e l’interruzione di una sessione con il token server. Agli avviamenti successivi, implementazione della modalità “servizio” tramite password.
3. Verifica la presenza di una connessione con il server, a seguito della quale interroga se è occupato o visualizza messaggi sui problemi. Quando la comunicazione viene ripresa, il programma inizia automaticamente a funzionare in modalità normale.

Il lavoro con il server WEB viene implementato utilizzando lo snap-in aggiuntivo fphttpclient.

qui ci sarà un collegamento alla versione corrente del client

non mancano inoltre ulteriori considerazioni sull'oggetto dell'articolo, nonché un parziale entusiasmo iniziale per il prodotto VirtualHere con le sue funzionalità...

Fonte: habr.com