Dans le cadre des changements dans la législation concernant les services de confiance (« À propos des services de confiance électroniques » Ukraine), l'entreprise a besoin que plusieurs départements travaillent avec des clés situées sur des jetons (pour le moment, la question du nombre de clés matérielles est toujours ouverte ).

En tant qu'outil le moins coûteux (gratuitement), le choix s'est immédiatement porté sur usip. Le serveur sur Ubintu 18.04 a commencé à fonctionner grâce à la publication Apprivoiser USB/IP et testé avec succès sur plusieurs lecteurs flash (en raison de l'absence de jeton à ce moment-là). Aucun problème particulier autre que la propriété monopolistique (réservation à l'utilisateur) n'a été identifié à cette époque. Il est clair que pour organiser l'accès de plusieurs utilisateurs (au moins deux pour commencer), il faut diviser leurs accès dans le temps et les obliger à travailler à tour de rôle.

La question était : comment puis-je le faire avec le moins de danse possible pour que tout fonctionne pour tout le monde...

La partie est maladroite

Option XNUMX. Plusieurs raccourcis vers les fichiers bat, à savoir
a) Connexion de la clé d'accès.
b) Déconnexion volontaire.

Paragraphe "б» controversé, il a donc été décidé de donner le temps nécessaire pour travailler avec la clé à 3 minutes.

La particularité du client usbip est qu'après son lancement, il reste suspendu dans la console ; sans interrompre la session console, vous pouvez fermer la connexion « grossièrement » côté client et aussi côté serveur.

Voici ce qui a bien fonctionné pour nous :

premièrement : la connexion sur.bat

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

deuxième : arrêt off.bat

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

Sans dépendre de la conscience de l'utilisateur, les scripts ont été combinés en jeton.bat

on.bat | off.bat

Que se passe-t-il : tous les fichiers sont dans le même dossier, lancé par le fichier token.bat, si la connexion est fermée, l'utilisateur reçoit immédiatement un message indiquant que la clé n'est pas disponible, dans un autre cas, seulement après 180 pings. Les lignes de code ci-dessus peuvent être équipées de « @ECHO OFF » et du sens console vers « > nul » pour ne pas trop choquer l'utilisateur, mais il n'est pas nécessaire de lancer des tests. Le premier « exécution » sur une clé USB a montré que tout était prévisible, fiable et clair. De plus, aucune manipulation n’est requise du côté du serveur.

Naturellement, en travaillant directement avec le token, tout ne s'est pas passé comme prévu : avec une connexion physique dans le gestionnaire de périphériques, le token est enregistré comme 2 appareils (WUDF et une carte à puce), et avec une connexion réseau uniquement comme WUDF (bien que cela suffit pour demander un code PIN).

Il s'avère également que le "taskkill" brutal n'est pas si grave, et la fermeture de la connexion sur le client est problématique et même si elle réussit, cela ne garantit pas sa fermeture sur le serveur.

Après avoir sacrifié toutes les consoles sur le client, le deuxième script a pris la forme :

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

bien que son efficacité soit inférieure à 50%, puisque le serveur continue obstinément à considérer la connexion ouverte.

Des problèmes de connexion ont conduit à réfléchir à une mise à niveau côté serveur.

Partie serveur

Ce que vous devez:

1. Déconnectez les utilisateurs inactifs du service.
2. Découvrez qui utilise actuellement (ou emprunte encore) le jeton.
3. Vérifiez si le jeton est connecté à l'ordinateur lui-même.

Ces problèmes ont été résolus à l'aide des services crontab et apache. Le caractère discret de la réécriture de l'état des résultats de surveillance des points 2 et 3 qui nous intéressent indique que le système de fichiers peut être localisé sur le ramdrive. Ligne ajoutée à /etc/fstab

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

Un dossier de scripts avec les scripts a été créé à la racine : démontage-montage du 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

obtenir une liste des appareils actifs 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

obtention d'une liste d'adresses IP actives (avec modification ultérieure pour afficher les identifiants utilisateur) usbip_client_ip.sh

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

la crontab elle-même ressemble à ceci :

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

Nous avons donc : toutes les 5 minutes, un nouvel utilisateur peut se connecter, quelle que soit la personne qui a travaillé avec le token. Le dossier /ramdrive est connecté au serveur http à l'aide d'un lien symbolique, dans lequel 2 fichiers texte sont enregistrés, indiquant l'état du serveur usbip.

Partie suivante : « Moche dans un emballage »

Option II. Pour plaire un peu à l'utilisateur avec au moins une interface moins intimidante. Intrigué par le fait que les utilisateurs disposent de différentes versions de Windows avec des frameworks différents, des droits différents, une approche moins problématique que Lazare Je ne l'ai pas trouvé (je suis bien sûr pour le C#, mais pas dans ce cas). Vous pouvez lancer des fichiers bat depuis l'interface en arrière-plan, minimisés, mais sans tests appropriés, je suis personnellement d'avis : il faut le visualiser pour recueillir l'insatisfaction des utilisateurs.

Les tâches suivantes ont été résolues par l'interface et le logiciel :

1. Affiche si le jeton est actuellement occupé.
2. Lors du premier lancement, la configuration initiale consiste à générer les fichiers bat « corrects » qui implémentent le lancement et l'interruption d'une session avec le serveur de jetons. Aux démarrages suivants, mise en place du mode « service » à l'aide d'un mot de passe.
3. Vérification de la présence d'une connexion avec le serveur, à la suite de quoi il interroge s'il est occupé ou affiche des messages sur des problèmes. Lorsque la communication reprend, le programme commence automatiquement à fonctionner en mode normal.

Le travail avec le serveur WEB est implémenté à l'aide du composant logiciel enfichable fphttpclient supplémentaire.

voici un lien vers la version actuelle du client

il y a aussi d'autres considérations sur le sujet de l'article, ainsi qu'un enthousiasme initial partiel pour le produit VirtualHere et ses fonctionnalités...

Source: habr.com