Vzhledem ke změně legislativy týkající se důvěryhodných služeb („O elektronických důvěryhodných službách“ Ukrajina) se v podniku objevila potřeba, aby několik oddělení pracovalo s klíči umístěnými na tokenech (v současnosti je otázka počtu hardwarových klíčů stále otevřená).

Jako nástroj s minimálními náklady (bezúplatně) okamžitě padla volba na usbip. Server na Ubuntu 18.04 fungoval díky publikaci Zvládáme USB/IP a byl úspěšně otestován na několika flash discích (v té době nebyl k dispozici token). Nebyly zjištěny žádné zvláštní problémy, kromě monopolního vlastnictví (rezervace pro uživatele) v té době. Je jasné, že pro zajištění přístupu několika uživatelů (alespoň dvou, na začátek) je nutné rozdělit jim přístup v čase a donutit je pracovat na střídačku.

Otázka zněla: Jak s minimem obstrukcí zajistit, aby všechno fungovalo...

Varianta hrubého řešení

1. varianta. Několik zkratek k bat souborům, a to konkrétně
a) Připojení přístupového klíče.
b) Vědomé odpojení.

Bod „b“ je sporný, proto bylo rozhodnuto poskytnout čas na práci s klíčem na 3 minuty.

Specifikou klienta usbip je, že po jeho spuštění zůstává viset v konzoli, bez přerušení konzolové relace lze spojení zavřít „hrubě“ ze strany klienta i ze strany serveru.

Tady je to, co nám fungovalo:

první: připojení on.bat

usbip -a 172.16.12.26 4-1
msg * "Token není dostupný nebo je obsazen "

druhý: odpojení off.bat

ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F

ne spoléhajíce na svědomí uživatele, byly skripty sloučeny do token.bat

on.bat | off.bat

Co se ukazuje: všechny soubory se nacházejí ve stejné složce, spuštění souboru token.bat, pokud je spojení uzavřeno u uživatele, ihned je oznámení o nedostupnosti klíče, v opačném případě až po 180 pingech. Zmíněné řádky kódu lze vybavit „@ECHO OFF“ a nasměrováním konzole na „> nul“, aby se uživatel příliš nevyděsil, nicméně pro testování spuštění to není nutné. První „průchod“ na USB zařízení ukázal, že všechno funguje předvídatelně, spolehlivě a přesně. A z pohledu serveru nejsou potřeba žádné manipulace.

Samozřejmě, když jsme pracovali přímo s tokenem, všechno nešlo podle očekávání: při fyzickém připojení v správci zařízení se token registruje jako 2 zařízení (WUDF a čipová karta), ale při síťovém pouze jako WUDF (i když pro zadání PIN kódu to stačí).

Také se ukázalo, že tvrdý "taskkill" není tak krutý a uzavření spojení na klientovi je problematické, a i když se to podařilo, nezaručuje to uzavření na serveru.

Obětováním všech konzolí na klientovi se druhý skript přetvořil na:

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

přičemž jeho účinnost je méně než 50 %, protože server neúprosně považoval spojení za otevřené.

Problémy se spojením vedly k myšlenkám na modernizaci serverové části.

Serverová část

Co je potřeba:

Odpojit neaktivní uživatele od služby.
Vidět, kdo právě používá (nebo ještě drží) token.
Vidět, zda je token připojen k samotnému počítači.

Tyto úkoly bylo rozhodnuto vyřešit pomocí služeb crontab a apache. Diskretnost přepisování stavu sledování bodů 2 a 3 naznačuje, že souborový systém může být umístěn na ramdrive. Do /etc/fstab byla přidána řádka

tmpfs /ram_drive tmpfs defaults,nodev,size=64K 0 0

V kořenovém adresáři byla vytvořena složka script se skripty: odpojení-montáž tokena 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

získání seznamu aktivních zařízení 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

získání seznamu aktivních IP (s následným vylepšením pro zobrazení identifikátorů uživatelů) usbip_client_ip.sh

netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt

sam crontab vypadá takto:

*/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)

Takže máme: každých 5 minut se může připojit nový uživatel, nezávisle na tom, kdo pracoval s tokenem. K http serveru je pomocí symlink připojena složka /ramdrive, ve které se ukládají 2 textové soubory, které ukazují stav serveru usbip.

Další část: „Nepěkné v obalu“

Varianta II. Trochu potěšit uživatele nějakým méně odstrašujícím rozhraním. Zatímco uživatelé mají různá vydání systému Windows s různými frameworky a různými právy, méně problémový přístup než Lazarus jsem nenašel (samozřejmě preferuji C#, ale ne v tomto případě). Spouštět bat soubory z rozhraní lze i na pozadí, minimalizované, ale bez řádného testování, osobně se domnívám: je třeba vizualizovat, aby se shromáždila uživatelská nespokojenost.

Rozhraní a softwarová část vyřešily následující úkoly:

Zobrazení, zda je token v tuto chvíli obsazen.
Při prvním spuštění probíhá počáteční nastavení s generováním „správných“ bat souborů, které realizují spuštění a přerušení sezení práce se serverem tokenu. Při následných spuštěních se realizuje „servisní“ režim na základě hesla.
Kontrola připojení k serveru, na základě výsledku se provádí jeho dotazování na obsazenost nebo se zobrazují zprávy o problémech. Při obnovení spojení program automaticky začne pracovat v běžném režimu.

Práce s WEB serverem byla realizována prostřednictvím dodatkovoho nástroje fphttpclient.