Debido a un cambio en la legislación sobre servicios de confianza ("Sobre los servicios de confianza electrónicos" en Ucrania), la empresa ha tenido la necesidad de que varios departamentos trabajen con claves almacenadas en tokens (en este momento, la cuestión sobre la cantidad de claves hardware aún está abierta).

Como herramienta con el menor costo (gratuíta) se eligió inmediatamente usbip. El servidor en Ubuntu 18.04 comenzó a funcionar gracias a la publicación Domando USB/IP y ha sido probado con éxito en varios dispositivos de almacenamiento USB (dado que en ese momento no se contaba con un token). No se detectaron problemas especiales, excepto la monopolización (reservación al usuario) en ese momento. Está claro que para organizar el acceso a varios usuarios (al menos dos, para comenzar) es necesario dividir su acceso temporalmente y hacer que trabajen por turnos.

Surge la pregunta: ¿Cómo hacer que todos funcionen con el menor esfuerzo posible?

Parte rudimentaria

Opción I. Varios accesos directos a archivos .bat, a saber,
a) Conexión de la clave de acceso.
b) Desconexión consciente.

El punto "b" es controvertido, por lo que se decidió dar un tiempo de trabajo con la clave de 3 minutos.

La característica del cliente usbip es que después de su inicio permanece en la consola, sin interrupción de la sesión de consola, se puede cerrar la conexión "brutalmente" desde el lado del cliente y también desde el lado del servidor.

Esto es lo que funcionó bien para nosotros:

primero: conexión on.bat

usbip -a 172.16.12.26 4-1
msg * "La firma/token no está disponible o está ocupada"

segundo: desconexión off.bat

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

sin confiar en la conciencia del usuario, los scripts se combinaron en token.bat

on.bat | off.bat

¿Qué obtenemos? Todos los archivos están en una carpeta, se ejecuta el archivo token.bat; si la conexión se cierra por parte del usuario, se enviará inmediatamente un mensaje de clave no disponible, en el otro caso, solo después de 180 pings. Las líneas de código presentadas se pueden equipar con "@ECHO OFF" y redirigir la consola a "> nul" para no asustar demasiado al usuario, pero para la ejecución en pruebas no es necesario. La primera "prueba" en un dispositivo USB mostró que todo es predecible, confiable y preciso. Además, desde el lado del servidor no se requieren manipulaciones.

Naturalmente, al trabajar directamente con el token, todo salió diferente a lo esperado: al conectarse físicamente, en el administrador de dispositivos, el token se registra como 2 dispositivos (WUDF y tarjeta inteligente), mientras que por red solo como WUDF (aunque para solicitar el código PIN esto es suficiente).

También resultó que el severo «taskkill» no es tan drástico, y cerrar la conexión en el cliente es problemático y, aunque se logre, no garantiza que se cierre en el servidor.

Sacrificando todas las consolas en el cliente, el segundo script asumió 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

aunque su efectividad es inferior al 50%, ya que el servidor siguió considerando la conexión como no cerrada.

Los problemas de conexión llevaron a pensar en una actualización en la parte del servidor.

Parte del servidor

Lo que se necesita:

1. Desconectar a los usuarios inactivos del servicio.
2. Ver quién está usando (o todavía ocupa) el token.
3. Ver si el token está conectado a la misma computadora.

Resolver estas tareas se decidió mediante servicios crontab y apache. La discreción al registrar el estado de los resultados de monitoreo de los puntos 2 y 3 sugiere que el sistema de archivos podría estar ubicado en un ramdrive. Se añadió la línea al /etc/fstab:

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

Se creó una carpeta llamada script en la raíz con los scripts: desmontar-montar el 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

obtener la lista de dispositivos activos 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

obtener la lista de IPs activas (con posterior modificación para mostrar los identificadores de usuarios) usbip_client_ip.sh

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

el crontab mismo se ve así:

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

Así que tenemos: cada 5 minutos puede conectarse un nuevo usuario, independientemente de quién haya trabajado con el token. La carpeta /ramdrive, conectada al servidor http mediante un symlink, almacena 2 archivos de texto que muestran el estado del servidor usbip.

Parte siguiente: «Lo poco atractivo en el envoltorio»

Opción II. Brindar un poco de alegría al usuario con una interfaz menos intimidante. Al considerar que los usuarios tienen diferentes versiones de Windows con distintos frameworks y permisos, no encontré un enfoque menos problemático que Lazarus mi opinión es que, aunque prefiero C#, no es el caso aquí. Se pueden ejecutar archivos bat desde la interfaz, incluso en segundo plano y minimizados, pero sin pruebas adecuadas, yo creo que es necesario visualizar para recopilar las quejas de los usuarios.

Se resolvieron las siguientes tareas en cuanto a la interfaz y la parte de software:

1. Mostrar si el token está ocupado en ese momento.
2. En el primer inicio, se realiza una configuración inicial generando archivos bat 'correctos' que implementan el inicio y la interrupción de la sesión de trabajo con el servidor del token. En los siguientes inicios, se implementa un modo 'de servicio' con contraseña.
3. Comprobar la conexión con el servidor, a partir de cuyo resultado se interroga sobre su ocupación o se muestran mensajes sobre problemas. Al restablecer la conexión, el programa comienza a funcionar automáticamente en modo normal.

La interacción con el servidor WEB se realizó mediante el complemento adicional fphttpclient.

también hay continuación de reflexiones sobre el tema del artículo, así como una parte de la emoción inicial por el producto VirtualHere con sus características...

Fuente: habr.com