В связи с изменением законодательства относительно доверительных услуг ( «Про электронные доверительные услуги» Украина), на предприятии появилась необходимость нескольким отделам работать с ключами, расположенными на токенах (на данный момент, вопрос о количестве аппаратных ключей еще открыт).

Как инструмент с наименьшими затратами (безвозмездно) сразу выбор пал на usbip. Сервер на Ubintu 18.04 заработал благодаря публикации Укрощаем USB/IP и успешно опробован на нескольких флеш накопителях (за неимением на тот момент токена). Никаких особых проблем, кроме монопольного владения (резервирования на пользователя) в тот момент времени выявлено не было. Понятно чтобы организовать доступ нескольким пользователям (хотя бы двум, для начала) необходимо разделить им доступ во времени и заставить работать по очереди.

Стал вопрос: Как с наименьшими танцами сделать чтобы у всех все работало…

Часть топорная

І вариант. Несколько ярлыков к bat файлам, а именно
а) Подключение ключа доступа.
б) Сознательно отключение.

Пункт «б» спорный, поэтому было решено дать количество времени на работу с ключом в 3 минуты.

Особенность клиента usbip в том что после его запуска он остается висеть в консоли, без прерывания консольной сессии закрыть подключение можно «грубо» со стороны клиента и так же со стороны сервера.

Вот что у нас нормально заработало:

первый: подключение on.bat

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

второй: отключение off.bat

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

не надеясь на сознательность пользователя, скрипты были объединены в token.bat

on.bat | off.bat

Что получается: все файлы находятся в одной папке, запуск файлом token.bat, если соединение закрыто у пользователя сразу сообщение о недоступности ключа, в другом случае, только через 180 пингов. Приведенные строки кода можно оснастить «@ECHO OFF» и направлением консоли в «> nul» дабы не сильно шокировать пользователя, но для запуска в тестирование не обязательно. Первичный «прогон» на USB накопителе показал, что все предсказуемо-надежно-четко. Причем со стороны сервера не нужно никаких манипуляций.

Естественно, при отработке непосредственно с токеном все пошло не так как ожидалось: при физическом подключении в диспетчере устройств, токен регистрируется как 2 устройства (WUDF и смарт-карта) а при сетевом только как WUDF (хотя для запроса ПИН кода и этого достаточно).

Также оказалось, что жестокий «taskkill» не так уж суров, и закрытие соединения на клиенте является проблемным и даже если это удалось, то это не гарантирует закрытие его для него на сервере.

Пожертвовав всеми консолями на клиенте второй скрипт принял вид:

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

хотя его результативность менее 50%, так как сервер упорно продолжал считать соединение незакрытым.

Проблемы с соединением привели к мыслям о модернизации в серверной части.

Часть серверная

Что нужно:

1. Отключать неактивных пользователей от сервиса.
2. Видеть кто сейчас использует (или еще занимает) токен.
3. Видеть подключен ли токен к самому компьютеру.

Решить эти задачи было решено при помощи сервисов crontab и apache. Дискретность перезаписи состояния результатов мониторинга интересующих нас 2 и 3 пунктов говорит о том что файловую систему можно расположить на ramdrive. В /etc/fstab добавлена строка

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

В корне создана папка script со скриптами: размонтирование-монтирование токена 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

получение списка активных устройств 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

получение списка активных IP (с последующей доработкой с отображением идентификаторов пользователей) usbip_client_ip.sh

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

сам crontab выглядит так:

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

Итак имеем: каждые 5 минут подключиться может новый пользователь, вне зависимости от того кто работал с токеном. К http серверу при помощи симлинка подключена папка /ramdrive в которой сохраняются 2 текcтовых файла, показывающих о состоянии сервера usbip.

Часть следующая: «Некрасивое в обертке»

ІІ вариант. Немного порадовать пользователя хоть каким-то менее устрашающим интерфейсом. Озадачившись тем, что у пользователей разные версии Windows с разным фреймворками, разными правами, менее проблемного подхода чем Lazarus я не нашел (я конечно за C#, но не в этом случае). Запускать bat файлы из интерфейса можно и в фоне, свернутыми, но без должного опробования, лично я придерживаюсь мнения: нужно визуализировать для сбора пользовательских недовольств.

Интерфейсом и программной частью были решены следующие задачи:

1. Отображение занят ли токен в данный момент.
2. При первом запуске первоначальная настройка с генерированием «правильных» bat файлов реализующих запуск и прерывание сеанса работы с сервером токена. При последующих запусках реализация «сервисного» режима по паролю.
3. Проверка наличия связи с сервером, по результату которой производится его опрос о занятости или выводится сообщения о проблемах. При возобновлении связи автоматически программа начинает работать в штатном режиме.

Работа с ВЕБ сервером реализована средствами дополнительной оснастки fphttpclient.

тут будет Ссылка на текущую версию клиента

есть также продолжение соображений по предмету статьи, как и частичный первоначальный восторг от продукта VirtualHere с его особенностями…

Источник: habr.com