W związku ze zmianami w ustawodawstwie dotyczącymi usług zaufania ("O usługach zaufania w formie elektronicznej" Ukraina), w firmie pojawiła się konieczność, aby kilka działów pracowało z kluczami umieszczonymi na tokenach (na ten moment, kwestia liczby kluczy sprzętowych jest jeszcze otwarta).

Jako narzędzie o najniższych kosztach (bezpłatne) od razu wybór padł na usbip. Serwer na Ubintu 18.04 uruchomił się dzięki publikacji Uspokajamy USB/IP i został pomyślnie przetestowany na kilku pamięciach flash (z braku tokena w danym momencie). Nie zidentyfikowano żadnych szczególnych problemów, poza monopolizacją (rezerwacją na użytkownika) w tamtym czasie. Jasne jest, że aby zorganizować dostęp dla kilku użytkowników (przynajmniej dla dwóch na początek), konieczne jest podzielenie im dostępu w czasie i zmuszenie ich do pracy na zmianę.

Pojawiło się pytanie: Jak przy minimalnym wysiłku sprawić, aby wszystkim wszystko działało…

Opcja niewygodna

I wariant. Kilka skrótów do plików bat, a mianowicie
a) Podłączenie klucza dostępu.
b) Świadome odłączenie.

Punkt "b" jest sporny, dlatego postanowiono przyznać czas na pracę z kluczem na 3 minuty.

Cechą klienta usbip jest to, że po jego uruchomieniu pozostaje on otwarty w konsoli, bez przerywania sesji konsolowej, można zakończyć połączenie "brutalnie" ze strony klienta i także ze strony serwera.

Oto co u nas działa poprawnie:

pierwszy: połączenie on.bat

usbip -a 172.16.12.26 4-1
msg * "Klucz/token niedostępny lub zajęty "

drugi: odłączenie off.bat

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

nie licząc na świadomość użytkownika, skrypty zostały połączone w token.bat

on.bat | off.bat

Co wychodzi: wszystkie pliki znajdują się w jednym folderze, uruchomienie plikiem token.bat, jeśli połączenie zostanie zamknięte przez użytkownika, natychmiastowe powiadomienie o niedostępności klucza, w przeciwnym razie, tylko po 180 pingach. Przedstawione linie kodu można wzbogacić o "@ECHO OFF" i skierowanie konsoli w "> nul", aby nie zszokować użytkownika, ale do uruchomienia w testach nie jest to konieczne. Początkowy "przegląd" na pamięci USB pokazał, że wszystko działa przewidywalnie, niezawodnie i dokładnie. Ponadto ze strony serwera nie są wymagane żadne manipulacje.

Oczywiście, przy pracy bezpośrednio z tokenem wszystko poszło inaczej, niż oczekiwano: przy fizycznym podłączeniu w menedżerze urządzeń, token rejestruje się jako 2 urządzenia (WUDF i karta inteligentna), a przy połączeniu sieciowym tylko jako WUDF (chociaż do żądania kodu PIN to wystarczy).

Okazało się również, że brutalne polecenie «taskkill» nie jest tak surowe, a zamykanie połączenia po stronie klienta jest problematyczne i nawet jeśli się to uda, to nie gwarantuje zamknięcia go na serwerze.

Po poświęceniu wszystkich konsol po stronie klienta drugi skrypt przybrał formę:

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

choć jego skuteczność wynosiła mniej niż 50%, ponieważ serwer uporczywie nadal traktował połączenie jako otwarte.

Problemy z połączeniem skłoniły do myślenia o modernizacji części serwerowej.

Część serwerowa

Co jest potrzebne:

Odłączać nieaktywnych użytkowników od usługi.
Widzieć kto obecnie używa (lub nadal zajmuje) token.
Widzieć, czy token jest podłączony do samego komputera.

Rozwiązanie tych zadań postanowiono zrealizować przy pomocy usług crontab i apache. Dyskretność zapisywania stanu wyników monitorowania interesujących nas punktów 2 i 3 wskazuje, że system plików można umieścić na ramdrive. W /etc/fstab dodano linię

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

W katalogu głównym utworzono folder script ze skryptami: odmontowywanie-montowanie 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

uzyskanie listy aktywnych urządzeń 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

uzyskanie listy aktywnych IP (z późniejszym przetwarzaniem wyświetlającym identyfikatory użytkowników) usbip_client_ip.sh

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

sam crontab wygląda tak:

* /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 więc mamy: co 5 minut nowy użytkownik może się połączyć, niezależnie od tego, kto pracował z tokenem. Do serwera http za pomocą symlink podłączono folder /ramdrive, w którym zapisano 2 pliki tekstowe, pokazujące stan serwera usbip.

Część następna: „Niekorzystnie opakowane”

II wariant. Nieco ułatwić użytkownikom korzystanie z mniej przerażającego interfejsu. Zastanawiając się nad różnymi wersjami Windows u użytkowników, różnymi frameworkami i różnymi uprawnieniami, mniej problematycznym podejściem niż Lazarus nie znalazłem (oczywiście jestem za C#, ale nie w tym przypadku). Można uruchamiać pliki bat z interfejsu, nawet w tle, zminimalizowane, ale bez odpowiedniego przetestowania, osobiście uważam, że należy zrealizować wizualizację dla zbierania niezadowolenia użytkowników.

Interfejs oraz część programowa rozwiązały następujące zadania:

Wyświetlanie, czy token jest aktualnie zajęty.
Przy pierwszym uruchomieniu wstępna konfiguracja z generowaniem "poprawnych" plików bat uruchamiających i przerywających sesję pracy z serwerem tokena. Przy kolejnych uruchomieniach realizacja trybu "serwisowego" po haśle.
Sprawdzanie dostępności połączenia z serwerem, na podstawie którego przeprowadza się jego zapytanie o zajętość lub wyświetla komunikaty o problemach. Przy wznowieniu połączenia program automatycznie przechodzi w normalny tryb działania.

Obsługa serwera WWW została zrealizowana za pomocą dodatkowego komponentu fphttpclient.