У зв'язку зі зміною законодавства щодо довірчих послуг («Про електронні довірчі послуги» Україна), на підприємстві виникла потреба декільком відділам працювати з ключами, розташованими на токенах (на даний момент, питання про кількість апаратних ключів ще відкрите).

Як інструмент з найменшими витратами (безоплатно) відразу вибір ліг на 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 (хоча для запиту PIN-коду і цього достатньо).

Також виявилося, що жорстокий «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 текстові файли, що показують про стан сервера usbip.

Частина така: «Некрасиве в обгортці»

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

Інтерфейсом та програмною частиною були вирішені наступні завдання:

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

Робота з ВЕБ сервером реалізована засобами додаткового оснащення fphttpclient.

тут буде Посилання на поточну версію клієнта

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

Джерело: habr.com