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

Як прылада з найменшымі выдаткамі (бязвыплатна) адразу выбар упаў на usbip. Сервер на Ubintu 18.04/XNUMX запрацаваў дзякуючы публікацыі Утаймоўваем 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/hull)

Такім чынам маем: кожныя 5 хвілін падлучыцца можа новы карыстач, па-за залежнасцю ад таго хто працаваў з токенам. Да http сервера пры дапамозе симлинка падлучаная тэчка /ramdrive у якой захоўваюцца 2 тэкставых файла, якія паказваюць аб стане сервера usbip.

Частка наступная: "Непрыгожае ў абгортцы"

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

Інтэрфейсам і праграмнай часткай былі вырашаны наступныя задачы:

1. Адлюстраванне ці заняты токен ў дадзены момант.
2. Пры першым запуску першапачатковая налада з генераваннем "правільных" bat файлаў рэалізуюць запуск і перапыненне сеансу працы з серверам токена. Пры наступных запусках рэалізацыя "сэрвіснага" рэжыму па паролі.
3. Праверка наяўнасці сувязі з серверам, па выніку якой праводзіцца яго апытанне аб занятасці або выводзіцца паведамленні аб праблемах. Пры аднаўленні сувязі аўтаматычна праграма пачынае працаваць у штатным рэжыме.

Праца з ВЭБ серверам рэалізаваная сродкамі дадатковага абсталявання fphttpclient.

тут будзе Спасылка на бягучую версію кліента

ёсць таксама працяг меркаванняў па прадмеце артыкула, як і частковае першапачатковае захапленне ад прадукта VirtualHere з яго асаблівасцямі…

Крыніца: habr.com