การแชร์เครือข่ายของโทเค็นการเข้ารหัสระหว่างผู้ใช้ตาม usbip

ในส่วนที่เกี่ยวข้องกับการเปลี่ยนแปลงกฎหมายเกี่ยวกับบริการความน่าเชื่อถือ (“เกี่ยวกับบริการความน่าเชื่อถือทางอิเล็กทรอนิกส์” ของยูเครน) องค์กรจำเป็นต้องมีแผนกต่างๆ ในการทำงานกับคีย์ที่อยู่บนโทเค็น (ในขณะนี้ คำถามเกี่ยวกับจำนวนคีย์ฮาร์ดแวร์ยังคงเปิดอยู่ ).

เนื่องจากเป็นเครื่องมือที่มีต้นทุนต่ำที่สุด (ฟรี) ทางเลือกจึงตกทันที ยูเอสบี. เซิร์ฟเวอร์บน Ubintu 18.04 เริ่มทำงานได้ด้วยการเผยแพร่ ฝึกฝน USB/IP และทดสอบได้สำเร็จกับแฟลชไดรฟ์หลายตัว (เนื่องจากขาดโทเค็นในขณะนั้น) ไม่พบปัญหาพิเศษอื่นใดนอกจากการผูกขาดการเป็นเจ้าของ (การจองสำหรับผู้ใช้) ในขณะนั้น เป็นที่ชัดเจนว่าในการจัดระเบียบการเข้าถึงสำหรับผู้ใช้หลายคน (อย่างน้อยสองคนในการเริ่มต้น) จำเป็นต้องแบ่งการเข้าถึงให้ตรงเวลาและบังคับให้พวกเขาทำงานตามลำดับ

คำถามคือ: ฉันจะทำอย่างไรโดยให้เต้นน้อยที่สุดเพื่อให้ทุกอย่างได้ผลสำหรับทุกคน...

ส่วนหนึ่งก็เงอะงะ

การแชร์เครือข่ายของโทเค็นการเข้ารหัสระหว่างผู้ใช้ตาม usbip
ตัวเลือกที่ 1. ทางลัดหลายทางไปยังไฟล์ค้างคาว ได้แก่
ก) การเชื่อมต่อคีย์การเข้าถึง
b) จงใจตัดการเชื่อมต่อ

ย่อหน้า "б» ขัดแย้งกัน ดังนั้นจึงตัดสินใจให้ระยะเวลาในการทำงานกับกุญแจอยู่ที่ 3 นาที

ลักษณะเฉพาะของไคลเอนต์ usbip คือหลังจากเปิดตัวแล้ว มันยังคงค้างอยู่ในคอนโซล คุณสามารถปิดการเชื่อมต่อ "โดยประมาณ" จากฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์โดยไม่ขัดจังหวะเซสชันคอนโซล

นี่คือสิ่งที่ใช้ได้ผลดีสำหรับเรา:

ครั้งแรก: การเชื่อมต่อ บน.ค้างคาว

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

ประการที่สอง: การปิดระบบ ปิดค้างคาว

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 แสดงให้เห็นว่าทุกสิ่งสามารถคาดเดาได้ เชื่อถือได้ และชัดเจน นอกจากนี้ ไม่จำเป็นต้องดำเนินการใดๆ จากฝั่งเซิร์ฟเวอร์

การแชร์เครือข่ายของโทเค็นการเข้ารหัสระหว่างผู้ใช้ตาม usbip

โดยปกติแล้ว เมื่อทำงานโดยตรงกับโทเค็น ทุกอย่างไม่เป็นไปตามที่คาดไว้: ด้วยการเชื่อมต่อทางกายภาพในตัวจัดการอุปกรณ์ โทเค็นจะถูกลงทะเบียนเป็นอุปกรณ์ 2 เครื่อง (WUDF และสมาร์ทการ์ด) และด้วยการเชื่อมต่อเครือข่ายเป็น WUDF เท่านั้น (แม้ว่า เพียงขอรหัส PIN ก็เพียงพอแล้ว)

การแชร์เครือข่ายของโทเค็นการเข้ารหัสระหว่างผู้ใช้ตาม usbip

ปรากฎว่า "ทาสก์คิล" ที่โหดร้ายนั้นไม่ได้รุนแรงนัก และการปิดการเชื่อมต่อบนไคลเอนต์นั้นเป็นปัญหา และแม้ว่าจะสำเร็จ แต่ก็ไม่รับประกันว่าจะปิดการเชื่อมต่อบนเซิร์ฟเวอร์ให้เขา

หลังจากเสียสละคอนโซลทั้งหมดบนไคลเอนต์แล้ว สคริปต์ตัวที่สองจึงอยู่ในรูปแบบ:

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 ที่ใช้งานอยู่ (พร้อมการแก้ไขในภายหลังเพื่อแสดง ID ผู้ใช้) 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 โดยใช้ symlink ซึ่งบันทึกไฟล์ข้อความ 2 ไฟล์ไว้ ซึ่งแสดงสถานะของเซิร์ฟเวอร์ usbip

ตอนถัดไป: “น่าเกลียดในกระดาษห่อ”

ตัวเลือกที่สอง เพื่อให้ผู้ใช้พอใจเล็กน้อยด้วยอินเทอร์เฟซที่น่ากลัวน้อยลง งงกับความจริงที่ว่าผู้ใช้มี Windows เวอร์ชันต่างกันซึ่งมีเฟรมเวิร์กต่างกัน สิทธิ์ต่างกัน แนวทางที่มีปัญหาน้อยกว่า ลาซารัส ฉันไม่พบมัน (แน่นอนว่าฉันเป็น C# แต่ไม่ใช่ในกรณีนี้) คุณสามารถเปิดไฟล์ bat จากอินเทอร์เฟซในพื้นหลังได้ โดยย่อให้เล็กสุด แต่ไม่มีการทดสอบที่เหมาะสม โดยส่วนตัวแล้วฉันมีความเห็น: คุณต้องเห็นภาพมันเพื่อรวบรวมความไม่พอใจของผู้ใช้

การแชร์เครือข่ายของโทเค็นการเข้ารหัสระหว่างผู้ใช้ตาม usbip

งานต่อไปนี้ได้รับการแก้ไขโดยอินเทอร์เฟซและซอฟต์แวร์:

  1. แสดงว่าโทเค็นไม่ว่างในขณะนี้หรือไม่
  2. ในการเปิดตัวครั้งแรก การตั้งค่าเริ่มต้นเกี่ยวข้องกับการสร้างไฟล์ค้างคาวที่ "ถูกต้อง" ซึ่งใช้การเปิดใช้งานและการหยุดชะงักของเซสชันกับเซิร์ฟเวอร์โทเค็น เมื่อเริ่มต้นครั้งต่อๆ ไป การใช้งานโหมด "บริการ" โดยใช้รหัสผ่าน
  3. การตรวจสอบการเชื่อมต่อกับเซิร์ฟเวอร์ซึ่งเป็นผลมาจากการสำรวจว่าเซิร์ฟเวอร์ไม่ว่างหรือแสดงข้อความเกี่ยวกับปัญหา เมื่อการสื่อสารกลับมาทำงานอีกครั้ง โปรแกรมจะเริ่มทำงานในโหมดปกติโดยอัตโนมัติ

การทำงานกับเซิร์ฟเวอร์เว็บถูกนำมาใช้โดยใช้สแนปอิน fphttpclient เพิ่มเติม


ที่นี่จะเป็นลิงค์ไปยังไคลเอนต์เวอร์ชันปัจจุบัน

นอกจากนี้ยังมีการพิจารณาเพิ่มเติมเกี่ยวกับหัวข้อของบทความ รวมถึงความกระตือรือร้นเบื้องต้นบางส่วนสำหรับผลิตภัณฑ์ VirtualHere ด้วยคุณสมบัติของมัน...

ที่มา: will.com

เพิ่มความคิดเห็น