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

Като инструмент с минимални разходи (без заплащане) веднага избрахме usbip. Сървърът на Ubuntu 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/null)

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

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

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

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

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

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

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

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