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

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

Въпросът беше: Как да накарам всичко да работи за всички с най-малките танци ...

Частично тромав

I опция. Няколко преки пътища към bat файлове, а именно
a) Връзка с ключ за достъп.
б) Умишлено изключване.

параграф "б” е спорен, така че беше решено да се даде време за работа с ключа за 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 ping. Горните редове от код могат да бъдат оборудвани с „@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

В основата се създава папка със скриптове: демонтиране-монтиране на токена 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 минути нов потребител може да се свърже, независимо кой е работил с токена. Папката /ramdrive е свързана към http сървъра чрез символна връзка, в която се записват 2 текстови файла, показващи състоянието на usbip сървъра.

Следваща част: "Грозно в обвивка"

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

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

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

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

тук ще има връзка към текущата версия на клиента

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

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