En relación cos cambios na lexislación sobre servizos de confianza ("Sobre os servizos electrónicos de confianza" Ucraína), a empresa necesita que varios departamentos traballen con claves situadas en tokens (de momento, a cuestión do número de claves de hardware aínda está aberta ).
Como ferramenta co menor custo (gratis), a elección caeu inmediatamente
A pregunta era: como podo facelo coa menor cantidade de baile para que todo funcione para todos...
A parte é torpe
Opción XNUMX. Varios atallos para ficheiros bat, a saber
a) Conexión da clave de acceso.
b) Desconectar intencionadamente.
Parágrafo "б» polémico, polo que se decidiu dar a cantidade de tempo para traballar coa chave aos 3 minutos.
A peculiaridade do cliente usbip é que despois do lanzamento, permanece colgado na consola; sen interromper a sesión da consola, pódese pechar a conexión "aproximadamente" dende o lado do cliente e tamén desde o lado do servidor.
Aquí está o que funcionou ben para nós:
primeiro: conexión on.bat
usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "
segundo: apagado apagado.morcego
ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F
Sen depender da conciencia do usuario, os guións combináronse ficha.bat
on.bat | off.bat
Que pasa: todos os ficheiros están no mesmo cartafol, lanzado polo ficheiro token.bat, se a conexión está pechada o usuario recibe inmediatamente unha mensaxe sobre a chave que non está dispoñible, noutro caso, só despois de 180 pings. As liñas de código anteriores pódense equipar con "@ECHO OFF" e a dirección da consola a "> nul" para non impactar demasiado ao usuario, pero non é necesario realizar probas. A "execución" inicial nunha unidade USB mostrou que todo era previsible, fiable e claro. Ademais, non se requiren manipulacións desde o lado do servidor.
Por suposto, ao traballar directamente co token, todo non saíu como se esperaba: cunha conexión física no xestor de dispositivos, o token rexístrase como 2 dispositivos (WUDF e unha tarxeta intelixente) e cunha conexión de rede só como WUDF (aínda que isto é suficiente para solicitar un código PIN).
Tamén resulta que o brutal "taskkill" non é tan grave, e pechar a conexión no cliente é problemático e aínda que tivese éxito, non garante pechalo no servidor.
Tras sacrificar todas as consolas do cliente, o segundo script tomou a 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
aínda que a súa efectividade é inferior ao 50%, xa que o servidor seguía teimudamente considerando a conexión aberta.
Os problemas coa conexión levaron a pensar sobre a actualización do lado do servidor.
Parte do servidor
O que necesitas:
- Desconecte os usuarios inactivos do servizo.
- Vexa quen está usando (ou aínda tomando prestado) o token.
- Vexa se o token está conectado ao propio ordenador.
Estes problemas resolvéronse mediante os servizos crontab e apache. A natureza discreta de reescribir o estado dos resultados do seguimento dos puntos 2 e 3 que nos interesan indica que o sistema de ficheiros pódese localizar no ramdrive. Engadida unha liña a /etc/fstab
tmpfs /ram_drive tmpfs defaults,nodev,size=64K 0 0
Creouse un cartafol de scripts con scripts na raíz: unmounting-mounting the 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
obtendo unha 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
obtención dunha lista de IPs activas (coa modificación posterior para mostrar os ID de usuario) usbip_client_ip.sh
netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt
o propio crontab ten o seguinte aspecto:
*/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)
Así temos: cada 5 minutos pódese conectar un novo usuario, independentemente de quen traballou co token. O cartafol /ramdrive conéctase ao servidor http mediante unha ligazón simbólica, na que se gardan 2 ficheiros de texto, que mostran o estado do servidor usbip.
Parte seguinte: "Feo nun envoltorio"
Opción II. Para agradar un pouco ao usuario con polo menos algunha interface menos intimidante. Desconcertado polo feito de que os usuarios teñan diferentes versións de Windows con diferentes marcos, dereitos diferentes, un enfoque menos problemático que
A interface e o software resolvéronse as seguintes tarefas:
- Mostra se o token está ocupado actualmente.
- No primeiro lanzamento, a configuración inicial implica xerar os ficheiros bat "correctos" que implementan o lanzamento e a interrupción dunha sesión co servidor de tokens. Nos inicios posteriores, implementación do modo "servizo" mediante un contrasinal.
- Comprobando a presenza dunha conexión co servidor, como resultado da cal consulta se está ocupado ou mostra mensaxes sobre problemas. Cando se retoma a comunicación, o programa comeza a funcionar automaticamente en modo normal.
O traballo co servidor WEB realízase mediante o complemento adicional fphttpclient.
tamén hai máis consideracións sobre o tema do artigo, así como un entusiasmo inicial parcial polo produto VirtualHere coas súas características...
Fonte: www.habr.com