В связи с изменением законодательства относительно доверительных услуг ( «Про электронные доверительные услуги» Украина), на предприятии появилась необходимость нескольким отделам работать с ключами, расположенными на токенах (на данный момент, вопрос о количестве аппаратных ключей еще открыт).
Как инструмент с наименьшими затратами (безвозмездно) сразу выбор пал на
Стал вопрос: Как с наименьшими танцами сделать чтобы у всех все работало…
Часть топорная
І вариант. Несколько ярлыков к 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%, так как сервер упорно продолжал считать соединение незакрытым.
Проблемы с соединением привели к мыслям о модернизации в серверной части.
Часть серверная
Что нужно:
- Отключать неактивных пользователей от сервиса.
- Видеть кто сейчас использует (или еще занимает) токен.
- Видеть подключен ли токен к самому компьютеру.
Решить эти задачи было решено при помощи сервисов 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 с разным фреймворками, разными правами, менее проблемного подхода чем
Интерфейсом и программной частью были решены следующие задачи:
- Отображение занят ли токен в данный момент.
- При первом запуске первоначальная настройка с генерированием «правильных» bat файлов реализующих запуск и прерывание сеанса работы с сервером токена. При последующих запусках реализация «сервисного» режима по паролю.
- Проверка наличия связи с сервером, по результату которой производится его опрос о занятости или выводится сообщения о проблемах. При возобновлении связи автоматически программа начинает работать в штатном режиме.
Работа с ВЕБ сервером реализована средствами дополнительной оснастки fphttpclient.
есть также продолжение соображений по предмету статьи, как и частичный первоначальный восторг от продукта VirtualHere с его особенностями…
Источник: habr.com