Сегодня быстрым ростом количества устройств сети Интернет и интернета вещей уже никого не удивишь. Существует множество различных протоколов и технологий, на которых основана обработка и обмен информацией между устройствами и, собственно, сама связь этих устройств.
Некоторые технологии являются своеобразными канонами: используются уже не один десяток лет и постоянно совершенствуются. А есть и такие, которые либо уже вымерли, либо родились, но так и не попали в массы ввиду своего несовершенства, низкой релевантности в отношении требований рынка и прочего.
В этой статье речь пойдет о технологии, не относящейся ни к одной, ни к другой группе — USB over IP. Без нее компьютерные сети существовали бы без особых проблем, но она способна значительно упростить работу и снизить затраты на эксплуатацию у крупных предприятий, небольших организаций и даже обычных пользователей. К примеру, с помощью нее можно пробросить аппаратный USB-ключ защиты ПО внутрь облачной платформы или облака на базе VMware и использовать его так, словно он установлен на локальной машине. Но обо всем по порядку.
История появления технологии USB over IP
Сложно сказать, когда именно появилась технология проброса USB-девайсов через сеть в том виде, в каком ее используют сейчас. Вероятнее всего, с развитием возможностей программных компонентов Linux, ростом потребностей рынка и изобретательности энтузиастов.
В наши дни существуют два популярных инструмента для трассировки USB-устройств: usbip и usbip-win. Оба нацелены на совместное использование USB-устройств через IP-сеть за счет обработки USB I/O сообщений, их инкапсуляции в TCP/IP и последующей передачи между устройствами сети типа «клиент-сервер». В такой схеме устройства подключаются к серверу, и на нем же запускается необходимый демон.
На машине клиента, как правило, запускается любое приложение, которое не умеет работать с сетью, зато прекрасно справляется с USB-девайсами. Технология проброса как раз позволяет эмулировать локальное подключение USB-устройств на клиентской машине.
- usbip был разработан проектом «USB/IP» еще в 2009 году. Технология была успешной: ее добавили в сборки Linux-ветки операционных систем, и она все еще развивается. Поддержка же Windows клиента была остановлена в 2013 году на выпущенной двоичной цифровой подписи драйвера.
- usbip-win является аналогичным проектом, умеющим работать с Windows 10. Более того, он позволяет поднимать на Windows 10 не только клиентскую, но и серверную часть. Также он совместим с Linux-версией.
Кому это интересно и где применяется
Преимущества сетевого проброса USB-устройств:
- Безопасность. Возможность изолированного размещения USB-девайсов от их конечного пользователя, шифрование и контроль доступа к устройствам, защита от человеческого фактора (кражи или утраты устройства).
- Мониторинг. Использование протокола SMTP и сценариев SNTP для отслеживания состояния устройств.
- Доступность и мультитенантность. USB-устройства доступны для неограниченного числа пользователей (с возможностью создавать групповые политики и уровни доступа) без необходимости физического переключения из любой точки мира.
- Централизованное администрирование. Удобство в управлении каждым USB-устройством, подключенным в концентратор.
Недостатки:
- Работоспособность полностью зависит от стабильной работы сети.
- Высокая стоимость аппаратных решений (управляемых USB-хабов с большим количеством портов).
- Не все USB-устройства могут работать через сеть штатно по причине увеличенного времени отклика.
Используемые технологии и оборудование
Способ обмена информацией у локальных и удаленных устройств отличается лишь тем, что для удаленных девайсов будет использоваться виртуальный драйвер шины: набор инструкций и данных, осуществляющий преобразование логической информации или данных в физические сигналы.
Когда приложения отправляют запрос на конечное устройство, USB PDD (USB Personal Device Driver) преобразует запросы ввода-вывода в серию команд понятных для USB, а затем отправляет их через драйвер шины (связующее звено между драйвером устройства и конечным устройством) в виде блоков USB-запросов на конечное устройство.
Способы проброса аппаратных ключей
Персональный драйвер устройства (PDD), как ни странно, отвечает за управление отдельными USB-устройствами. PDD отправляет запросы в виде специальных блоков запросов URB (USB Request Block), которыми он обменивается данными с ядром USB (USB Core) — отдельной подсистемой внутри ОС, выполняющей роль поддержки USB-устройств и контроллеров.
Для реализации проброса протокола USB через IP-сеть была разработана сущность, называемая виртуальным интерфейсом хост-контроллера, или Virtual Host Controller Interface (VHCI). VHCI относится к виртуальному контроллеру и способен экспортировать виртуальные USB-устройства, не поддерживаемые физическими устройствами. В Linux контроллеры VHCI используются для доступа к USB-устройствам с удаленных машин, подключенных по уже известному нам протоколу USBIP.
VHCI является эквивалентом драйвера хост-контроллера (HCD) и отвечает за обработку URB-запросов. И VHCI, и HCD отвечают за обработку URB-запросов, полученных от ядра, и делят их на более простые запросы, именуемые Transfer Descriptions (дескрипторы передачи TD) для их дальнейшей передачи на хост-контроллер интерфейса, он же USB-контроллер (Host Controller Interface HCI). Данный интерфейс работает на уровне физических регистровых передач и обеспечивает коммуникацию с периферийными устройствами, подключенными к USB.
Теперь о том, как USB попадает в сеть. Блок запросов URB преобразуется в блок запроса USB / IP драйвером VHCI и отправляется на удаленный компьютер. Драйвер заглушки также добавлен как новый тип USB PDD. Драйвер-заглушка отвечает за декодирование входящих USB / IP-пакетов с удаленных машин, извлечение URB и последующую отправку их на локальные USB-устройства.
Модуль ядра vhci-hcd — это только виртуальный хост-контроллер, к которому вы можете подключить виртуальные устройства.
Как это устроено в Selectel
Рассмотрим работу с USB-концентратором на примере устройства DistKontrolUSB-16. Для того, чтобы пробросить USB-устройство с порта концентратора, необходимо:
- Создать USB-устройство, указав его Vendor/ProductID (VID/PID) и серийный номер. Именно по нему концентратор будет проводить отбор подключенных устройств:
- Указать внешний IP-адрес клиента, который будет подключаться к USB-концентратору и указать разрешенные для подключения порты:
- В клиентском приложении найти необходимое устройство и отправить команду на его использование. После этого девайс будет доступен словно физически подключенное устройство.
Заключение
Описанная технология способна обеспечить необходимую масштабируемость и гибкость в современной, постоянно изменяющейся среде. Проброс USB-устройств через сеть также обеспечивает надежность за счет ограничения физического доступа к устройствам.
Отсутствует необходимость перемещать оборудование, а безопасность сети повышается за счет возможности использования алгоритмов шифрования и настройки прав доступа. Доступна планировка сценариев для каждого отдельно взятого устройства.
Снижение рисков и затрат на обслуживание, удобство совместного использования ресурсов между рабочими станциями — все это делает технологию usbip конкурентоспособной в отношении безопасной авторизации и передачи данных (с TOTP/HOTP, OCRA) и применимой для решения широкого спектра задач IT.
Комментарии (85)
TrickyBestia
05.11.2021 21:52+4Так и не понял зачем это нужно. Я думал насчёт HID-устройств (мышь, клавиатура...), устройств хранения данных, веб-камер. В случае с этими устройствами USB over IP является бесполезной технологией. Могли бы вы привести примеры устройств, использование USB over IP с которыми даёт какие-то реальные преимущества? В моём понимании USB-устройства - это про портативность, а вы предлагаете "пихать что-то в какой-то концентратор", и указываете централизованность как один из плюсов. Хотя, возможно, что это я чего-то очевидного не вижу.
Darksa
05.11.2021 21:53+10Аппаратные ключи для программного обеспечения. Таким образом можно пробросить USB-ключ, к примеру, внутрь облака. ЭЦП те же самые не хранить у сотрудников или в офисе, а держать в ЦОДе.
gudvinr
05.11.2021 22:29+26Но ведь… USB-ключи тем и хороши, что без физического обладания им, невозможно ничего сделать, где он требуется.
nApoBo3
05.11.2021 23:41+37Тссссс, это древняя война, один придумали usb токены, а другие их передают друг другу, имеют один на всю бухгалтерию и ещё бэкап у айтишников. Вот такая вот информационная безопасность.
aborouhin
06.11.2021 04:54+6Тут как бы дело в том, что при использовании ЭЦП не получается реализовать обычные сценарии делегирования полномочий, как в случае с бумажными доверенностями. Получил ЭЦП юрлица - всё, у тебя по факту полномочия генерального директора, неважно для какой конкретно задачи тебе она понадобилась. И отследить, для чего эта ЭЦП на флэшке была получившим её товарищем применена и сколько раз, никак. А лично руководитель, даже в не очень большой компании, всё и всегда подписывать не может.
Поэтому разграничивать полномочия на использование ЭЦП на другом уровне, например, контролируя доступ к такому вот устройству, куда они централизованно воткнуты, - вполне себе повышает безопасность. Можно дать одноразовый доступ, доступ с подтверждением и т.п. Если, конечно, именно разграничивать, мониторить и т.п., а не тупо расшарить на всю контору :)
hbr1222
06.11.2021 06:15+5И отследить, для чего эта ЭЦП на флэшке была получившим её товарищем применена и сколько раз, никак. А лично руководитель, даже в не очень большой компании, всё и всегда подписывать не может.
Да, а как до ЭЦП все работали?
"ЭЦП юрлица" это что-то странное. ЭЦП это аналог физической подписи. Физическую подпись ставит конкретный человек. У каждого человека своя ЭЦП (и может быть не одна).
По правильному, разграничение должно делаться на уровне полномочий доверенностями. А ЭЦП тут нипричем.
tmin10
06.11.2021 11:11+1У юрлица вроде есть своя печать, может быть это её аналог?
aborouhin
06.11.2021 12:37+1Только необходимость ставить и вообще иметь печать для юр. лиц несколько лет назад из законодательства успешно выпилили, а ЭЦП юр. лица живее всех живых.
Хотя, казалось бы, у государства есть ЕГРЮЛ, из данных которого однозначно следует, какое физ. лицо в конкретный момент времени уполномочено без доверенности представлять какое юр. лицо. А для остальных ничто не мешает доверенности подписывать той же ЭЦП... но нет.
aborouhin
06.11.2021 12:35+1"ЭЦП юрлица" это что-то странное.
Так да. ЭЦП - это "аналог собственноручной подписи". Но собственноручная подпись есть только у директора, а ЭЦП ещё и у условного ООО.
И условному менеджеру Васе, который на условной площадке эл. торгов подаёт по десять заявок в день, надо авторизоваться на этой площадке именно с ЭЦП ООО, а не со своей личной. Отсюда и весь этот сюр с флэшками.
Иногда работает по-другому. Например, юрист может документы в суд подписать своей личной ЭЦП, приложив скан доверенности, и подать через my.arbitr.ru. Но в основном не так.
tmin10
06.11.2021 13:51В идеале иметь доверенности, подписанный этой ЭП юрлица, а дальше уже все своими личными подписывают.
SerjV
06.11.2021 17:03"ЭЦП юрлица" это что-то странное. ЭЦП это аналог физической подписи. Физическую подпись ставит конкретный человек. У каждого человека своя ЭЦП (и может быть не одна).
Насколько я помню, по закону об электроподписи, юрлицу не может быть выдала квалифицированная электрическая подпись.
Но зато может быть выдана на физлицо-руководителя, позволяющая подписывать от имени организации (руководитель же лицо, имеющее право действовать от имени организации без доверенности) и в какой-то области применения ("для бухотчётности", "для торгов" (причём разная цена в зависимости от числа площадок), "для документооборота" и т.п.).
После чего обычно геморроиться с доверенностями и платой за подписи на других лиц в СМБ влом (крупняки и ГОСы с бюджетниками разве что - потому что одних заставляет СБ, а других Казначейство), и подпись руководителя используют как "подпись организации".
perlestius
10.11.2021 08:19+1Знаю случай, когда бухгалтер долгое время подписывала бумажные документы за генерального директора его подписью (по его же просьбе, т.к. лично он физически не успевал).
Однажды он пришел в банк, чтобы подписать какой-то важный договор, где нужно было личное присутствие, а ему сказали, что не примут подписанные им документы, т.к. его подпись совсем не похожа на ту, которой он обычно им всё подписывал
zuek
12.11.2021 14:38Это не единичный случай - в моём прошлом личный секретарь руководителя подписывала за него почти все документы, при чём подпись в её исполнении (практически?) полностью совпадала с подписью в паспорте, а вот когда пришлось лично в банке какие-то документы получать, тот самый руководитель изрядно намучался, чтобы воспроизвести свою же подпись.
Что уж там - даже моя подпись в 10 случаях из 10 будет разной... но парадоксально совпадать с подписью одного из моих начальников далёкого прошлого. Году так, в 98-м довелось расписываться в зарплатной ведомости... а подпись уже стоит! Ну, думаю, сейчас буду бучу поднимать - ан, нет, у шефа, который за 2 человека передо мной стоял в очереди, пусто в графе... пришлось его звать в кассу, чтобы он и за себя расписался.
vikarti
06.11.2021 09:05+1Интересно, планы по машиночитаемым доверенностям
( https://www.nalog.gov.ru/rn77/related_activities/el_doc/use_electronic_sign/#t4 например) что-то изменят? (там идея что подпись юрлица ладно уж — на директора можно а все остальные должные подпись физика + доверенность)aborouhin
06.11.2021 12:39+1На самом деле, даже сейчас формально ничто не мешает подписать доверку ЭЦП директора / юр. лица, а собственно документы - ЭЦП доверенного лица. Только что доверенность будет не машиночитаемая и наличие полномочий придётся проверять вручную - но это другая проблема.
И в ряде случаев (см. мой коммент выше по ветке про суды) это так и работает. Но в основном таки требуется ЭЦП юр. лица на любой чих.
Moskus
05.11.2021 23:49Если оставить в стороне иронию, то вы путаете обладание ключом и, например, необходимость того, что он воткнут в порт конкретной рабочей станции. Удаленный доступ к ключу не означает автоматически возможность совместного использования ключа одновременно - это все еще может быть эксклюзивное использование, просто ключ и рабочая станция могут быть разнесены в пространстве, не более.
unsignedchar
06.11.2021 00:34Удаленный доступ к ключу не означает автоматически возможность совместного использования ключа одновременно
А если не автоматически? ;) Есть принципиальная невозможность совместного использования?Moskus
06.11.2021 00:46+1До какой степени "принципиальная"? Это зависит от того, как устроен обмен между ключом и остальными элементами защиты. Например, если используется аналог сессионного ключа.
Более верный вопрос должен звучать так: "Есть ли виды аппаратных ключей, которые становятся значительно более уязвимы благодаря этой технологии, и если есть, то какие". Ответ, очевидно, что такие виды есть - например, тупой ID. Частный случай - всякие DS1990A.
impexp
06.11.2021 09:12Несмотря на заверения минцифры ещё несколько лет назад, что вот-вот будет возможно использовать сертификаты, выпущенные различными УЦ, в различных цифровых системах, до сих пор это по факту не осуществилось (к справедливости, зато и нет единого корневого сертификата для всех УЦ, контролируемого ФСБ). В ЭДО, "Честном знаке" и системах бухгалтерской и налоговой отчётности ситуация немного лучше, что реализовано благодаря более-менее универсальному набору полномочий выпускаемых сертификатов (к примеру: сертификат выдан УЦ "СКБ Контур", пользователь работает в системе "Астрал").
А вот система делегирования полномочий реализуется на уровне системы, но не типовых наборов прав сертификата, поэтому неудобства зависят, как правило, от выбора системы. Нет единого набора прав и полномочий, например, в системе ФС РАР: нельзя просто делегировать выпущенному сертификату дополнительный набор полномочий сертификата, а необходимо выпускать новый. По этой причине когда-то я сам, на заре первых внедрений РАР, использовал программный usb-over-ip для токена, чтобы можно было использовать токен JaCarta с неэкспортируемым сертификатом на разных рабочих местах.
Плюс ко всему, персональный сертификат для каждого сотрудника – это накладно, хотя даже у малого бизнеса есть потребность в делегировании полномочий: часто оказывается так, что токен с необходимым сертификатом, с которым в теории можно хоть закрыть предприятие, хоть взять кредит, "где-то у бухгалтера лежит", а чаще всего путешествует с бухгалтером и порой даже теряется.
А пока не сделали полноценное делегирование, иногда приходится делегировать временные полные права как раз через usb-over-ip.
iliar
07.11.2021 13:13Тут вот какой нюанс. Аппаратные ключи специально проектируются таким образом, чтобы их невозможно было скопировать. То есть предполагается, что ключом может воспользоваться только тот, у кого есть к нему физический доступ.
В случае использования USB over IP ключом может воспользоваться кто угодно, кто сможет подключиться. То есть "физическое обладание ключом" заменяется на "задача контроля доступа". И тут весь вопрос в том, как это будет реализовано. Можно конечно удариться в аниме и соединить сервер с физическим ключом и клиент отдельной витой парой по типу точка-точка с авторизацией по физическому ключу... В теории так сделать можно, и это будет супер надёжно и безопасно, но мы же понимаем, что ни кто так делать не будет. А как только мы упрощаем способ подключения, то мы автоматом понижаем безопасность решения. То есть грубо говоря если у нас авторизация просто по паролю, а доступ есть не только из локальной сети, а через интернет, то это конечно удобно для пользователей, но считай, что никакого ЭЦП у тебя нет, а есть только пароль. Так как любой кто знает пароль может воспользоваться твоей ЭЦП. Если проводить аналогию, это всё равно, что поставить дорогую железную дверь, но ключ хранить под ковриком.
И обрати внимание. Я не говорю, что это априори плохо. Как ни странно формальное снижение безопасности по факту может даже увеличивать безопасность. Приведу что имеется в виду. Предположим у нас есть дверь на склад. Огромная сейфовая дверь, способная выдержать прямое попадание из РПГ. С электронным замком с биометрией и одноразовыми паролями подписанными лично ЭЦП директора. Круто? Круто! Но через неделю в двери будет лежать деревянный брусочек чтобы дверь не закрывалась. И внезапно оказывается, что китайская картонная дверь с авторизацией по обычным NFC меткам безопасней, так как люди не будут лениться её закрывать.
Так, что я не говорю, что USB over IP это однозначно плохо. Просто его использование снижает безопасность и поэтому теперь уже ты должен придумать как организовать контроль доступа так, чтобы компенсировать это снижение безопасности.
Moskus
07.11.2021 18:43Я не знаю, зачем вы мне решили читать лекцию по основам безопасности, будучи только поверхностно знакомым с вопросом и приводя неуместные аналогии.
Для архитектуры безопасности аппаратных ключей доступ к ним через USB вообще - это уже работа через неподконтрольный канал, который с точки зрения осуществления атаки типа mitm (частным случаем которой является добавление произвольного числа участников диалога с ключом) только чуть сложнее, чем USB over IP.
Потому безопасный с этой точки зрения ключ должен иметь средства, которые позволяют удостовериться, что диалог ведётся с одним и тем же приложением (или с несколькими, но с известным ограниченным числом).
Если же вы представляете себе архитектуру безопасного ключа, как тупой идентификатор и проверку наличия устройства, его содержащего, на шине USB - я вас поздравляю, вы отстали где-то на сорок лет от того, как это делается сейчас.
nitro80
06.11.2021 04:20Пример из жизни: изъяли сервер + usb-ключ.
Стоимость нового ключа около 90000 рублей.
Если бы ключи были в другом офисе\дома у директора\на другом континенте - компания продолжила бы работу практически без перерыва, со "вчерашнего" бекапа. А так пришлось заказывать экстренно новый ключ и ждать несколько дней доставку.
fougasse
06.11.2021 11:44+1Вы пытаетесь реши административную проблему изъятия сервера техническими средствами. А если дома у директора устроят маски-шоу, то лучше бы ключ был в сервере.
ibrin
06.11.2021 11:56+1лучше, если ключи и все остальные чувствительные данные будут замурованы в автомобиль, находящийся в соседнем с офисом гаражном помещении.
Yacudza
29.11.2021 12:37-1Если у Вас изъяли usb-ключ, то его формально можно считать скомпрометированным и это нужно фиксировать документально с отзывом сертификата или приостановкой его действия... Используя бэкап изъятого ключа потом будет сложно доказать кто реально пользовался вашим сертификатом, Вы или не честные сотрудники которые изъяли usb-ключ
Poo-ool
06.11.2021 13:09Вот вам пример. Есть купленная за 3000000 система с USB-ключом. Позволяет развернуть один инстанс. На вопрос: "как для отказоустрйчивости развернуть дублирующую ноду во втором цоде" предложили купить ща 3ляма еще один инстанс. Естественно обошлись одним ключом с выносом в отдельный сервис. Осталась проблема в том что ключ физически только в одном цоде - нет защиты от разрушения но с этим уже можно жить.
tmin10
06.11.2021 13:52Ещё если в ЦОДе с ключём пропадёт связь или будет пожар, резервирование тоже не выйдет, нужно физически переткнуть ключи.
Moskus
05.11.2021 23:54+1Это очень узкая задача, хотя она и нужна многим. На самом же деле, есть множество legacy и просто специальных устройств, у которых есть только USB, как сравнительно быстрый интерфейс, выбранный разработчиками. Добавление аппаратной поддержки сети до сравнительно недавнего времени было не то чтобы легкой задачей, на самом деле. Вот например: https://www.winradio.com/home/receivers.htm - только серия G6x имеет сетевой интерфейс.
Ndochp
06.11.2021 04:58пробросить USB-ключ, к примеру, внутрь облака
Да даже один ключ в 2 облака!
ЭЦП те же самые не хранить у сотрудников
а подписывать за сотрудников все самим
gameplayer55055
06.11.2021 08:44Какие ЭЦП и зачем?
А от какие-то донглы можно хранить. Но дешевле их эмулировать
acin
05.11.2021 22:48Один из возможных сценариев это физическое хранение HASP ключей с лицензиями на софт в отдельном месте.
Например на моей прошлой работе у нас был ЦОД в одном городе и офисы с небольшими серверными в других городах. В ЦОДе крутились все виртуальные и не очень сервера, всяческие там К+, 1С и т.п. Договора заключались в разных городах и почему-то было принято решение HASP ключи к ним хранить в них же. Т.е. USB ключ был установлен в одном городе, а сервера с соответствующим софтом были в другом.
AquariusStar
05.11.2021 23:13+2Подключение программатора и удалённая отладка устройства. У меня несколько случаев было, когда нужен USBIP (вот как, оказывается, называется такая технология). Неудобно каждый раз взбираться и протягивать кабель с программатором к устройству, которому ещё и ограничили движения из-за кабеля.
SerjV
05.11.2021 23:29+2Так и не понял зачем это нужно. Я думал насчёт HID-устройств (мышь, клавиатура...), устройств хранения данных, веб-камер. В случае с этими устройствами USB over IP является бесполезной технологией. Могли бы вы привести примеры устройств, использование USB over IP с которыми даёт какие-то реальные преимущества?
Да те же камеры уже давно со встроенным IP умеют делать...
А вот когда надо в облаке или в онпремиз виртуализации запустить в виртуалке софт с ключом защиты... Порой вариантов, отличных от USB over IP просто нет.
desertkun
06.11.2021 00:05В моем случае, я отлаживал устройство с GPS, которое нормально работает только за окном. Чтобы не тянуть 10 метров usb кабеля, просто кинул на подоконник ноутбук, а уже отладку вел в уютном кресле, используя VirtualHere.
SerjV
06.11.2021 00:10но можно было бы и активный USB-удлинитель применить....
Хотя ноут проще кинуть, если он есть, а удлинителя - нет :)
gwathedhel
06.11.2021 09:31+2Практическая задача, можно сказать боль. Нужно прокинуть в виртуалки hasp ключи для специфического софта. Втыкаешь напрямую флешки, дело то. А потом, когда нужно мигрировать витуалку - начинаются танцы и бег в серверную перетыкать флешку из одного сервера в другой. Сабж помог бы избавиться от этого ручного труда и необходимости физического присутствия в серверной при vMotion таких виртуалок.
SerjV
06.11.2021 17:08+1В Hyper-V научились USB-устройства пробрасывать в виртуалки с хоста?
Так что такой приём еще не во всякой системе виртуализации сработает, плюс если кластер - то при миграции ВМ на вторую ноду и выключения первой, - воткнутые в первую ноду ключи будут недоступны после миграции ВМ.
gwathedhel
06.11.2021 17:20+1Hyper-V не пользуюсь) зачем, если есть vmware?
При выключении первой ноды с ключами, прокинутыми на вторую - да, ключи отвалятся. Потому и говорю, что нужно физически переткнуть ключ во вторую после миграции.
SerjV
06.11.2021 18:16Hyper-V не пользуюсь) зачем, если есть vmware?
Если у вас всё равно винда - то кластер "из коробки" доступен без дополнительно платы, и бэкап можно делать. Хотя если у вас "всё равно платный вариант vmware" - то да, разницы нет.
При выключении первой ноды с ключами, прокинутыми на вторую - да, ключи отвалятся. Потому и говорю, что нужно физически переткнуть ключ во вторую после миграции.
Ну а в случае железяки для ключей USB-over-IP - не отвалится ничто, а вероятность отключения этой железки ниже, чем сервера.
Вот как-бы так и живут...
gwathedhel
06.11.2021 19:09Вы, видимо, меня спутали с другим комментатором. Я как раз понимаю ценность usb-to-ip железок.
SerjV
06.11.2021 21:14Это было к вопросу про vmware :) В халявном варианте там не все фишки доступны.
gwathedhel
06.11.2021 22:50+1Конечно не в халявном) хотя зачем мне компания, которая не может позволить себе лицензию на vmware? Не те деньги, чтобы экономить на удобном кластерном решении для виртуализации.
vikarti
06.11.2021 09:50Токены доступа всякие не таскать с собой.
Либо иметь возможность иметь на хостинге в том же Selectel виртуалку с виндой внутри которой надо использовать VPN с токеном.Ну и если надо пробрасывать с рабочего места куда то еще / нет желания покупать железку но все равно есть комп с кучей портов — есть программные решения — USB Network gate и VirtualHere
nev3rfail
06.11.2021 10:09+2Лет тринадцать назад знакомый сломал прошивку на своём Sony Ericsson. Самостоятельно без спецсофта было невосстановимо, но на форумах нашли какого-то чувака, который какой-то магический тулзой прокинул USB с мастера в слейв через пол земного шара и с помощью специальной сервисной тулы от Соней потрогал правильные регистры и дал залить нормальную прошивку. Маловероятно, что это имеет что-то общее с usbip, потому что там всё было насквозь проприетарное и пропитанное серостью, но как рабочий кейс вполне себе. Есть девайс, есть необходимость сделать с ним __что-то__, специалист по этому девайсу находится за тристатыщмиллионов километров. Что делать? usbip!
TimsTims
06.11.2021 18:01и дал залить нормальную прошивку
Раз он подключался к вашему компу, почему бы он просто не установил на ваш комп сначала remote admin, а потом тулзу для локального дебага по usb, и через неё же и залил необходимую прошивку? Так гораздно надежнее было бы, чем ставить usbip
zxosa
06.11.2021 11:30я сейчас тестирую для удаленного контроля usb-rs232(uart) устройств, конкретно контроллеры gsm doorhan и домовой ip (в нашем городе 2g gsm сети на передачу данных не работают практически, как оказалось)
musonius
06.11.2021 13:13+3у меня есть несколько клиентов которые заняты в одной сфере бизнеса - бухаутсорс. их 1 клиент=1-2 (редко 3) ключа. итого у тебя есть десятки ключей, которые нужны разным бухам работающим локально и удаленно на терминалке, где установлено все то, что они подписывают этими ключами. и часто в течение дня нужны около десятка ключей, а во время отчетного периода нужны больше половины, а во время годового отчета нужны все ключи.
сбросить все подписи на 1 ключ невозможно принципиально ибо 1 разработчик крипты предусматривает такую возможность только во время генерации серта, 2 ключ не твоя собственность, ты не можешь ей распоряжаться как тебе вздумается, если клиент уйдет ты обязан ему вернуть ключ в рабочем состоянии с рабочим сертом, чтобы он воткнул это к себе в комп, с помощью тп установил и настроил ПО и у него все работало, 3 банки слегка против такой мешанины)
железка позволяет прокинуть ключ в облако, где у клиента установлена 1с, которая в свою очередь для отправки некоторых данных требует сначала их подписать этим самым сертом.
итого стоит в сети вот такая железка на 64 порта, в ней стоят одновременно все ключи всех клиентов. админ не дурит себе голову регулярными зависаниями ПО которое умеет пробрасывать ключи и его чисткой, порты в пк/ноутах не раздалбываются перевтыканием ключей, бухи не дурят себе голову поисками нужного, потому что в среднем на одного буха 10 ключей, а портов в локальном пк/ноуте далеко не столько, директор не дурит себе голову организационными вопросами как забрать ключи у удаленного работника в другом городе, если он заболел, в отпуске и тд. ВСЕ ключи находятся только в офисе, после появления железки это стало законом. клиент когда приезжает за ключом для генерации нового серта, то секретарь тупо достает из железки ключ согласно распечатки об их расположении и туда же возвращает потом, а только потом сообщает админу об этом, чтобы он установил новый серт.
стоит ли это 2к денег? однозначно.
modsamara
10.11.2021 16:26На серваке куда подключается бух в пользователя копируется ключ с токена и никакого гимора и путаницы нет
musonius
10.11.2021 17:20https://habr.com/ru/company/selectel/blog/587522/comments/#comment_23674854
чтобы не повторяться. вы - яркий пример из первого предложения.
цитирую разработчиков "скопировать запись о сертификате НЕВОЗМОЖНО, она попадает туда только в момент генерации запроса на сертификат и может быть только удалена. под это даже не разрабатывались инструменты"
если есть желание я дам комплект софта и прокину ключ к вам на пк через интернет. скопируете с него запись о серте на другой ТАКОЙ ЖЕ ключ - с меня ящик пива. а на серваке криптопровайдер не умеет искать в принципе.
доступно?
Alexsey
06.11.2021 17:04У меня был кейс - есть маленькая, но важная софтина, которая взаимодействует с GSM модемом. Так как софтина маленькая - крутится она в виртуалке внутри весьма большого кластера, жирновато под нее отдельный физический сервер иметь. Единственный способ надежно прокинуть в нее модем - USB over IP. Я правда софтварные методы использовал и модем был воткнут в какую-то дешевую железку где был поднят линукс с нужной софтиной для прокидывая USB.
teakettle
08.11.2021 14:16Например, сервер 1с держать в виртуалке на HA-кластере. Без сабжа (технология, не железка) он не может уехать на другую ноду, поскольку привязан к той, в которую физически воткнут юэсбический ключ.
vashu1
05.11.2021 23:57+1Если идет интенсивная двусторонная коммуникация, то latency даже в несколько миллисекунд делает эту штуку бесполезной.
Я как-то раз писал кастомный протокол, чтобы быстро прокручивать цикл запрос/ответ, без отправки данных через интернет. А в usbip такую фичу можно реализовать?
vikarti
07.11.2021 08:35+1Существуют железки с поддержкой USB3.0, гигабитного ethernet и изохронного режима USB — например https://3dnews.ru/969181 (там еще и тесты есть, диск тестировали)
402d
06.11.2021 11:02Как всегда в рекламе все хорошо.
На практике головная боль.
Половину того, что должны делать драйвера USBoverIP возможно Вы знаете как JetDirect . Висит демон, слушает 910n порт, пришедшие данные пересылает на устройство, ответ от него в сеть.
Казалось бы с другой стороны нужно только это оформить как виртуальное устройство .
Но тут возникают проблемы маршрутизации и детекта обрыва. Нужно периодически гонят пинги (по другому обрыв не поймать).
В общем часть описанную выше писать и отлаживать самому (собирать из опенсорса) то еще удовольствие, ну а платные решения можете поискать сами и глянуть на порядок цен.
Из универсальных решений можно глянуть в сторону построенных на https://ru.wikipedia.org/wiki/MQTT
А так чаще реализуют частные решения . Как пример то, что напридумывали для ККМ (облачные кассы).
musonius
06.11.2021 14:25+1По поводу железки
Для проброса лицензий она хороша. Но весьма странно что за столько лет авторы не додумались до иных сценариев (потому что основной их сценарий это один ключ подключается к одному клиенту на одном пк) и не сделали нормальную работу в терминальном режиме, когда все ключи подключаются к одному пк, но видимы только конкретным юзерам. Про интеграцию с АД вообще молчу - учетки считывает, на их основе создает свои локальные, которые в терминалке та-дааам, не работают, потому что ты или подключаешь все ключи под одним логин-пасом или идешь лесом, т.е. в терминалке тупо невозможно подключить 10 ключей под разными логинами и привязать подключение ключа логон-скриптом к юзеру, чтобы все ключи были по умолчанию отключены, а подключался 1 нужный только когда юзер залогинился, а потом отключался.
Эта схема, наверное, только сверхразумам доступна для прогнозирования. Это же так трудно предположить, что сисадмин захочет иметь доменную авторизацию в железке и привязку к юзеру.
В итоге, изза того что криптопровайдер не расчитан разрабами для работы с десятками ключей одновременно, приходится задачами в планировщике периодически перезапускать порты, чтобы отвалившиеся в крипте ключи снова вернулись. Но, как описал выше в другом коменте схему работы, плюсы все таки перевешивают отсутствие нормальной работы с терминалкой и доменом
SerjV
06.11.2021 17:13Если речь идёт об электроподписях, то их можно пробрасывать в терминальном режиме как правило. А если о ключах защиты - то терминал не поможет. Или брать другую схему лицензирования - ради одного рабочего места не всегда целесообразно...
musonius
06.11.2021 17:31+3бич айтишников и сисадминов из рф, что в соцсетях, что на хабре - они думают что все используют криптопро, рутокен и прочие подобные продукт и делают соответствующие выводы, что их опыт такой же как у других.
я из беларуси, о чем в профиле специально указано. криптопровайдер у нас единственный, "терминальные" ключи ввели только относительно недавно, пара лет гдето, +за замену с обычного на такой надо платить (попробуйте объяснить вашему новому клиенту, почему он должен своими деньгами и временем оплачивать ваши локальные хотелки, до которых он ни каким боком). и ключ при этом вставляется именно в комп с которого производится подключение, только так и никак иначе - он определяется как смарткарта. т.е. появляется проблема, которую я озвучил немного выше - удаленный сотрудник должен иметь набор ключей у себя локально. а если учесть что они работают по схеме домашний пк-впн-виртуалка в офисе-терминалка то ключ чисто теоретически уже не пробросится в терминалку.
про лицензирование согласен, сам всегда ною клиентам про прогнозирование развития и выбор схемы исходя из этого, а не из текущих потребностей.
ПС иногда доводится работать с клиентами, которые являются филиалом российских фирм. так вот московские админы частенько не горят желанием разбираться в нашей кухне. им проще заплатить денег мне, чтобы я сделал как надо, что собственно и происходит. притом что я самостоятельно при нужде разобрался и с российскими наборами по и ключей, а одно время потрогал и грузинскую.
SerjV
07.11.2021 20:09я из беларуси, о чем в профиле специально указано. криптопровайдер у нас единственный
не совсем понял, в чём у вас проблема - токен "обычный" не прикидывается смарт-картой, и потому его нельзя пробросить в терминал, нужно брать относительно недавно появившийся "новый" тип токена, который смарт-картой умеет прикидываться?
они работают по схеме домашний пк-впн-виртуалка в офисе-терминалка
то есть у них двойной терминал получается - первый с домашнего компа на виртуалку в офисе, а второй - с этой виртуалки на терминальный сервер?
musonius
07.11.2021 23:04да, именно так.
обычный самый распространенный токен работает только локально или с пробросом софтом или железом по айпи. терминальный токен определяется как смарткарта и пробрасывается именно рдп соединением, а не сам по себе или криптопровайдером (на него ставится свой драйвер, если в настройках рдп не будет галочки о пробросе смарткарт, то он не пробросится. не помню нужно ли чтобы драйвер стоял с двух сторон. имею такой ключ только на двух небольших серверах, давно последний раз его настраивал для работы, в прошлом году как минимум). само собой что по умолчанию тебе выдают обычный токен, а терминальный по отдельному запросу и само собой любой из них не бесплатно. т.е. я не могу взять пачку терминальных токенов, напихать их в пк с полусотней портов и чтобы они были доступны на терминалке, тупо потому что они этого не умеют. а с ПО или железкой из статьи могу это сделать с обычными токенами.
да, у них двойной терминал по сути. в офисе у каждого настроено его собственное рабочее место (есть только удаленные сотрудники, есть только офисные, есть переменные) либо на железе, либо на виртуалке. все виртуалки крутятся на рабочих пк по схеме 1+1 - один сотрудник за пк и 1 на виртуалке на этом же пк. если в офис приезжает тот, кто работает на виртуалке, то он садится за любой пк, подключается к своей виртуалке и работает. такая схема дешевле чем полноценный терминальный сервер на серверной платформе+виртуалка в любой момент может быть поднята на любом доступном железе из шаблона, а настройки профиля раздаются политиками (что опять же проще и быстрее чем сетевой профиль), благо их там немного: закладки, ярлыки, сетевая шара. если офисный сотрудник захотел домой на пару дней то он точно также подключается к своему рабочему пк - все равно за ним скорее всего никто не работает. все посещения отмечаются в общем яндекс-календаре всеми сотрудниками. чаще всего в офисе 1 человек или вообще никого, только пк работают, т.е. конечная цель почти достигнута) рабочие процессы ведутся централизованно в трелло через расшаренные доски.
схема такая потому, что моя задача по подключению заключается в том, чтобы выслать сотруднику инструкцию по настройке впн и все. а где он работает, с какого пк или ноута, из какого города и тд меня уже мало волнует (есть такие которые ездят по рб по родне или на дачу или еще куда и работают при этом. директор опять же не против). и также я не дурю себе голову переносимыми профилями. и еще одна немаловажная причина - все подключения рдп, внутренние и внешние забиты у каждого сотрудника на его пк в рдп менеджер, с сохранением паролей. а я не хочу подключать на непонятный мне комп сетевую шару, ставить менеджер с полным списком клиентов и тд. поэтому все подключения к терминалке только с локальных компов (собственно это и настроено в АД), без вариантов.
все довольны, все понимают в какой ситуации что им делать, где что взять для подключения куда надо, схема легко масштабируется на любое количество работников и клиентов. мои задачи это завести нового юзера под клиента или работника, доустановить то, что не делается политиками при первом входе, ну и пара мелких задач типа не печатает или установить новый серт. ну и бэкапы проверять само собой, хотя вим с его surebackup-ом тоже оставляет немного работы)
SerjV
08.11.2021 04:43да, у них двойной терминал по сути.
Ну, с двойным терминалом, когда USB-устройство нужно на дальнем, а не ближайшем, терминале - уже да, нетривиально. Так-то в ближайшую виндовую машину с некоторыми извращениями в некоторых случаях теоретически можно пробросить usb-устройство через RemoteFX...
alex-khv
06.11.2021 16:00+1Внедрял такое в 2010-2011. И Linux usbip и платные windows и аппаратные девайсы.
Со всеми была одна проблема. Иногда высокий latency tcp/ip стека нарушал взаимодействие клиента и сервера. Примерно раз в месяц приходилось хотя бы один ключ вытаскивать/вставлять из разъема (их было много разных).
Как сейчас с этим ?
Renatk
06.11.2021 20:35-2В статье не указана проблема, что даже реальное USB может не работать, в компьютере, если в него залогиниться по RDP сессии. Только физический доступ в компьютер. Так что USB в облаке, а компьютер...
Nichls
07.11.2021 22:25Большое спасибо за статью.
Есть где на практике применить, ибо как заметили выше, прикидывать USB в ESXi можно, но не совсем удобно в случае миграции и т.д.Описанный в статье способ видимо должен помочь.
post_ed
07.11.2021 22:25Можно ли один usb-ключ прокидывать каждые N секунд на виртуалки поочереди? И таким образом вместо одной машины получить несколько машин с ПО защищённым usb-ключом.
musonius
08.11.2021 00:07можно попробовать.
в теории на виртуалке надо написать скрипт, который подключится к железке, подключит устройство к себе, подождет эн секунд, отключит его. далее по таймауту такой же скрипт запускается на другой виртуалке. при такой схеме критично стабильно работающий сервер времени.
http://distkontrol.ru/upload/RukovodstvoUSBoverIPv4.pdf 89-91стр
другой вопрос как на это будет реагировать ПО. 1с например проверяет ключ только при запуске платформы/конфиги. во время работы он не требуется. но вариантов работы другого ПО множество. т.е. надо экспериментировать.
dimkinkot
07.11.2021 22:26+1Не совсем понял как в ПО Selectel прослеживается VirtualHere, она там и есть?
JayK
09.11.2021 10:30-2Это идеальный, сферический костыль в вакууме. Ни для чего кроме этих самых ключей оно по хорошему неприменимо. А сама концепция ключа физического в физическом контроле над оным, а не овер айпи...
Wesha
...всего за каких-то несчастных $900!
dvrpd
В OpenWRT бесплатно.
vikarti
А сколько можно USB-устройств подключить к девайсу с OpenWRT? Ну в смысле на реальных роутерах с OpenWRT, и без хабов.
Как я понимаю смысл всяких DistKontrol — 16+ устройств + готовый интерфейс управления.
eigrad
А есть какой-то смысл в "без хабов"? Иначе уж 16 то устройств типа указанных в статье любой современный роутер потянет. Интерфейс для конечного пользователя все равно ведь нужно будет допиливать?
vikarti
Бытовые хабы вполне могут глючить и виснуть (особенно если на них начнут что-то жрущее вешать, не токен а допустим камеру или диск а питания недостаточно). И по питанию порты они дергать не умеют.
Если именно подбирать 100% рабочее и по сути делать "свой DistKontrol" — это другая история совсем.