V souvislosti se změnami v legislativě v oblasti důvěryhodných služeb („O elektronických důvěryhodných službách“ Ukrajina) podnik potřebuje, aby několik oddělení pracovalo s klíči umístěnými na tokenech (v tuto chvíli je stále otevřená otázka počtu hardwarových klíčů ).

Jako nástroj s nejnižšími náklady (zdarma) volba okamžitě padla usbip. Server na Ubintu 18.04 začal fungovat díky publikaci Zkrocení USB/IP a úspěšně testováno na několika flash discích (kvůli v té době chybějícímu tokenu). V tomto okamžiku nebyly identifikovány žádné zvláštní problémy kromě monopolního vlastnictví (rezervace pro uživatele). Je jasné, že pro organizaci přístupu pro několik uživatelů (nejméně dva, pro začátek), je nutné jejich přístup časově rozdělit a přinutit je pracovat střídavě.

Otázka zněla: Jak to udělat s co nejmenším množstvím tance, aby vše fungovalo pro všechny...

Část je nemotorná

Možnost XNUMX. Několik zkratek k souborům bat, jmenovitě
a) Připojení přístupového klíče.
b) Záměrné odpojení.

Odstavec "б» kontroverzní, proto bylo rozhodnuto dát čas na práci s klíčem 3 minuty.

Zvláštností klienta usbip je, že po svém spuštění zůstává viset v konzole, bez přerušení relace konzoly můžete uzavřít spojení „zhruba“ ze strany klienta i ze strany serveru.

Zde je to, co pro nás fungovalo dobře:

první: připojení na.bat

usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "

druhá: vypnutí off.bat

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

Bez spoléhání se na vědomí uživatele byly skripty kombinovány do token.bat

on.bat | off.bat

Co se stane: všechny soubory jsou ve stejné složce, spouštěné souborem token.bat, pokud je spojení uzavřeno, uživatel okamžitě obdrží zprávu o nedostupnosti klíče, v jiném případě až po 180 pingech. Výše uvedené řádky kódu mohou být vybaveny „@ECHO OFF“ a směr konzole na „> nul“, aby uživatele příliš nešokovaly, ale není nutné spouštět testování. Počáteční „běh“ na USB disku ukázal, že vše bylo předvídatelné, spolehlivé a jasné. Navíc nejsou vyžadovány žádné manipulace ze strany serveru.

Při přímé práci s tokenem samozřejmě nešlo vše podle očekávání: při fyzickém připojení ve správci zařízení je token registrován jako 2 zařízení (WUDF a čipová karta), při síťovém připojení pouze jako WUDF (i když to stačí k vyžádání PIN kódu).

Ukazuje se také, že brutální „taskkill“ není tak hrozný a uzavření spojení na klientovi je problematické a i když bylo úspěšné, nezaručuje mu to uzavření na serveru.

Po obětování všech konzolí na klientovi získal druhý skript podobu:

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

ačkoli jeho účinnost je nižší než 50 %, protože server tvrdohlavě nadále považoval připojení za otevřené.

Problémy s připojením vedly k úvahám o upgradu na straně serveru.

Serverová část

Co budete potřebovat:

1. Odpojte neaktivní uživatele ze služby.
2. Podívejte se, kdo aktuálně používá (nebo si stále půjčuje) token.
3. Podívejte se, zda je token připojen k samotnému počítači.

Tyto problémy byly vyřešeny pomocí služeb crontab a apache. Diskrétní povaha přepisování stavu výsledků monitorování bodů 2 a 3, která nás zajímá, naznačuje, že souborový systém může být umístěn na ramdrive. Přidán řádek do /etc/fstab

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

V kořenovém adresáři byla vytvořena složka skriptů se skripty: odpojení-připojení tokenu 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áslednou úpravou pro zobrazení uživatelských ID) usbip_client_ip.sh

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

samotný 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/hull)

Takže máme: každých 5 minut se může připojit nový uživatel bez ohledu na to, kdo s tokenem pracoval. Složka /ramdrive je připojena k http serveru pomocí symbolického odkazu, ve kterém jsou uloženy 2 textové soubory zobrazující stav usbip serveru.

Další díl: „Ošklivý v obalu“

Možnost II. Abychom uživatele trochu potěšili alespoň nějakým méně podbízivým rozhraním. Zmatení z toho, že uživatelé mají různé verze Windows s různými frameworky, jinými právy, méně problematický přístup než Lazar Nenašel jsem to (samozřejmě jsem pro C#, ale ne v tomto případě). Soubory bat z rozhraní můžete spouštět na pozadí, minimalizované, ale bez řádného testování, osobně zastávám názor: ke sbírání nespokojenosti uživatelů je třeba jej vizualizovat.

Pomocí rozhraní a softwaru byly vyřešeny následující úlohy:

1. Zobrazuje, zda je token aktuálně zaneprázdněn.
2. Při prvním spuštění počáteční nastavení zahrnuje generování „správných“ souborů bat, které implementují spuštění a přerušení relace s tokenovým serverem. Při následných startech implementace „servisního“ režimu pomocí hesla.
3. Kontrola přítomnosti spojení se serverem, v důsledku čehož se dotazuje, zda je zaneprázdněn, nebo zobrazuje zprávy o problémech. Po obnovení komunikace program automaticky začne pracovat v normálním režimu.

Práce s WEB serverem je realizována pomocí dodatečného modulu snap-in fphttpclient.

zde bude odkaz na aktuální verzi klienta

jsou zde i další úvahy k tématu článku a také částečné počáteční nadšení z produktu VirtualHere s jeho funkcemi...

Zdroj: www.habr.com