Във връзка с промените в законодателството относно доверителните услуги ("За електронните доверителни услуги" Украйна), в предприятието се яви необходимостта няколко отдела да работят с ключове, разположени на токени (в момента, въпросът за броя на хардуерните ключове все още е отворен).

Като инструмент с най-ниски разходи (безвъзмездно) веднага избрахме usbip. Сървърът на Ubuntu 18.04 заработи благодарение на публикацията Укротяване на USB/IP и успешно е тестван на няколко USB памети (поради липса на токен в този момент). Никакви специални проблеми, освен монополната собственост (резервиране на потребител) в онзи момент не бяха установени. Ясно е, че за да се организира достъп на няколко потребители (поне двама, за начало), е необходимо да се раздели достъпът им във времето и да се принудят да работят по ред.

Възникна въпросът: Как с най-малко усилия да направим така, че всички да работят…

Част груб

I вариант. Няколко прякори към 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 паметта показа, че всичко е предсказуемо-надеждно-точно. Освен това от страна на сървъра не са необходими никакви манипулации.

Естествено, при работа с токена всичко не мина както се очакваше: при физическо свързване в диспечера на устройствата, токенът регистрира две устройства (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/null)

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

Следваща част: «Не красиво в опаковка»

ІІ вариант. Някак да зарадва потребителя с поне малко по-малко плашещ интерфейс. Разсъждавайки върху факта, че потребителите имат различни версии на Windows с различни фреймове, различни права, незабележим подход, от колкото Lazarus не намерих (разбира се, съм за C#, но не в този случай). Стартирането на bat файлове от интерфейса може да се извършва и на заден план, свити, но без достатъчно тестване, лично смятам, че трябва да визуализираме за събиране на недоволствата на потребителите.

С интерфейса и софтуерната част бяха решени следните задачи:

1. Показване на това дали токенът е зает в момента.
2. При първото стартиране, първоначалната настройка с генериране на "правилните" bat файлове за стартиране и прекратяване на сесията на работа с токеновия сървър. При последващи стартирания, реализация на "сервисния" режим по парола.
3. Проверка за наличие на свързаност с сървъра, в зависимост от резултата се извършва запитване за заетост или се извеждат съобщения за проблеми. При възстановяване на свързаността, програмата автоматично започва да работи в нормалния режим.

Работата с уеб сървъра е реализирана с помощта на допълнителния компонент fphttpclient.

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

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