Devido à mudança na legislação em relação aos serviços de certificação eletrônica ("Sobre serviços de certificação eletrônica" na Ucrânia), tornou-se necessário que vários departamentos trabalhassem com chaves localizadas em tokens (no momento, a questão do número de chaves de hardware ainda está em aberto).

Como uma ferramenta com o menor custo (gratuitamente), a escolha recaiu imediatamente sobre usbip. O servidor no Ubuntu 18.04 funcionou graças à publicação Domando USB/IP e foi testado com sucesso em várias unidades flash (na falta de um token naquele momento). Não foram identificados problemas significativos, exceto pela posse monopolista (reserva para o usuário) naquele momento. É claro que, para organizar o acesso para vários usuários (pelo menos dois, para começar), é necessário dividir o acesso no tempo e fazê-los trabalhar em alternância.

Surgiu a questão: Como fazer com o menor esforço para que todos funcionassem...

Parte tosca

Primeira opção. Vários atalhos para arquivos bat, a saber,
a) Conexão da chave de acesso.
b) Desconexão intencional.

O item "b" é controverso, portanto, foi decidido dar um tempo de trabalho com a chave de 3 minutos.

A peculiaridade do cliente usbip é que, após sua execução, ele permanece pendurado no console, sem a interrupção da sessão do console, a desconexão pode ser feita "brutalmente" tanto do lado do cliente quanto do servidor.

Aqui está o que funcionou normalmente para nós:

primeiro: conexão on.bat

usbip -a 172.16.12.26 4-1
msg * "A assinatura/token não está disponível ou está ocupada "

segundo: desconexão off.bat

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

não confiando na consciência do usuário, os scripts foram combinados em token.bat

on.bat | off.bat

O que acontece: todos os arquivos estão em uma única pasta, iniciando com o arquivo token.bat, se a conexão for fechada pelo usuário, há imediata mensagem de indisponibilidade da chave, no outro caso, apenas após 180 pings. As linhas de código apresentadas podem ser dotadas de "@ECHO OFF" e direcionamento do console para "> nul" para não chocar muito o usuário, mas para execução em teste não é obrigatório. A primeira "execução" em uma unidade USB mostrou que tudo era previsível, confiável e claro. Além disso, do lado do servidor, nenhuma manipulação era necessária.

Naturalmente, ao trabalhar diretamente com o token, tudo aconteceu de maneira diferente do esperado: ao conectar fisicamente no gerenciador de dispositivos, o token é registrado como 2 dispositivos (WUDF e cartão inteligente), enquanto na conexão de rede é registrado apenas como WUDF (embora para solicitar o código PIN isso seja suficiente).

Além disso, descobriu-se que o brutal «taskkill» não é tão severo assim, e fechar a conexão no cliente é problemático, e mesmo que isso seja bem-sucedido, não garante que a conexão seja fechada para ele no servidor.

Deixando de lado todos os consoles no cliente, o segundo script ficou assim:

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

embora sua eficácia seja inferior a 50%, pois o servidor continuou a considerar a conexão não encerrada.

Problemas de conexão levaram a reflexões sobre a modernização na parte do servidor.

Parte do servidor

O que é necessário:

1. Desconectar usuários inativos do serviço.
2. Ver quem está usando (ou ainda ocupa) o token.
3. Ver se o token está conectado ao próprio computador.

Resolver essas tarefas foi decidido por meio dos serviços crontab e apache. A discretização da reescrita do estado dos resultados de monitoramento dos pontos 2 e 3 indica que o sistema de arquivos pode ser colocado no ramdrive. A linha adicionada ao /etc/fstab é

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

Na raiz foi criada uma pasta script com os scripts: desmontar-montar o 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

obter a lista de dispositivos ativos 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

obter a lista de IPs ativos (com posterior desenvolvimento para exibir os identificadores dos usuários) usbip_client_ip.sh

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

o crontab em si aparece assim:

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

Portanto, temos: a cada 5 minutos, um novo usuário pode se conectar, independentemente de quem trabalhou com o token. A pasta /ramdrive, conectada ao servidor http por meio de um symlink, armazena 2 arquivos de texto, mostrando o estado do servidor usbip.

Próxima parte: “Feio por fora”

II opção. Um pouco de prazer ao usuário com uma interface menos intimidadora. Ao considerar que os usuários têm diferentes versões do Windows com diferentes frameworks e permissões, não encontrei uma abordagem menos problemática do que Lazarus Eu realmente não encontrei (eu sou a favor do C#, mas não neste caso). É possível executar arquivos bat pela interface, mesmo em segundo plano e minimizados, mas sem o devido teste, pessoalmente acredito que precisamos visualizar para coletar as insatisfações dos usuários.

A interface e a parte do software resolveram as seguintes tarefas:

1. Mostrar se o token está ocupado no momento.
2. Na primeira execução, a configuração inicial gera os arquivos bat "corretos" para iniciar e interromper a sessão de trabalho com o servidor do token. Em execuções subsequentes, implementa-se o modo "serviço" por senha.
3. Verificação da conectividade com o servidor, cujo resultado determina a consulta sobre a ocupação ou exibe mensagens sobre problemas. Ao restabelecer a conexão, o programa começa automaticamente a trabalhar em modo normal.

O trabalho com o servidor WEB foi implementado utilizando a ferramenta adicional fphttpclient.

também há continuação das reflexões sobre o tema do artigo, assim como o entusiasmo inicial parcial com o produto VirtualHere e suas peculiaridades...

Fonte: habr.com