Адресная книга выглядит таким вот образом:
Имена компьютеров и групп произвольные, параметры подключения (кодек, блокировка ввода по-умолчанию, звук, и т.д.) могут быть сохранены как индивидуально для каждого компьютера, так и наследоваться от параметров группы; ID выдаются маршрутизатором - серверной частью, но могут быть сохранены и непосредственно ip - тогда маршрутизатор не нужен
Протокол свой, порты настраиваются
Для подключения без одноразового пароля на каждом клиенте должна быть задана пара логин/пароль; с одной стороны при массовой установке это неудобно, с другой стороны пара может быть задана через json при установке или импорте конфигурации.
shurshur, не знаю, меня более-менее устраивает то положение, в котором винда - для десктопа, серверная винда - для AD, для прочего - никсы. Больше меня не устраивает то, что майкрософт ломает то, что и так работало много лет - с вин11.
shurshur, клиентская винда просто не предназначена вообще в роли роутера существовать, так то; а там, hyper-v нетворк манагер, к примеру, вполне себе реализует уже программные вланы, в том числе с поддержкой транков, но только для проброса в vm.
Akina, ну, не вполне; аппаратная поддержка 802.11q - хорошо, но не обязательно
>на дебиане придётся мастерить два виртуальных интерфейса с адресами из показанных подсетей, привязанных к сетевой карте, и маршрутизировать между этими (и остальными) интерфейсами.
Ну да
>хотя вроде и пробудить может но не точно
Может, хотя автору стоит покопаться в настройках и проверить s power states и как wol с ними взаимодействует в конкретно его случае, в частности пробуждение/включение от pci(e) устройств
Про проводки - это либо что-то совсем старое, либо связано только со включением из холодного состояния (S5), и я просто не в курсе; из остальных режимов pci(e) точно может пробуждать без всяких лишних проводков, если это включено, конечно же
Для автора:
Тут, всё-таки, надо понимать, что у вас есть несколько уровней включения/пробуждения. Магический пакет - это замечательно, но компьютер ещё должен мочь пробуждаться от того устройства, на которое этот магический пакет приходит, а связана эта способность с интерфейсом, через которое это устройство подключается к компьютеру. Кроме того, надо учитывать power states. Обычно это всё очевидно из доступных настроек bios/uefi.
number09, я не знаю вашей ситуации, поэтому смоделирую ситуацию (на самом деле опишу свою), которая могла бы вызывать вашу потребность:
Есть группа файлов, принадлежащая к одному проекту и не подлежащая изменению, или подлежащая крайне редкому изменению после завершения проекта. При этом пользователи могут обращаться к завершённым проектам время от времени и случайно вносить изменения в файлы этого проекта, что крайне нежелательно.
Решение: переносить из плоскости чисто технической в административную - например, делать группу файлов уже завершённого проекта доступной только на чтение, без возможности записи; или делать архивную копию этой конкретной группы файлов после завершения этого конкретного проекта.
Подумайте в административном направлении, если не удаётся решить вашу задачу технически.
number09, ну тот же стандартный майкрософтовский VSS хранит до 512 теневых копий. Да, не совсем тем путём, что вам надо, но это разве мало? А если кто-то на каком-то этапе всё-таки испортит содержимое файла - вы будете вручную отсматривать все его 512 копий? Для предотвращения таких ситуаций обычно делается еженедельная/ежемесячная/ежегодная полная копия, и хранится N недель/месяцев/лет
Ну, начнём с того, что S/N накопителя - это одно (его вообще можно сменить без перепрошивки?), VolumeID - совсем другое, не имеющее никакого отношения к первому. Какая цель действа то?
res2001,
>видимо они передаются при подключении клиента
Конечно, само собой. Открытый ключ клиента точно передается, закрытый может использоваться для подписи челленжа - стандартная история - но конкретику надо смотреть отдельно в этом моменте.
>Пока соединения нет - не знает, но в процессе подключения клиента - уже знает.
А, окей, мы просто друг друга не поняли. Разумеется, я имел в виду в "холодном" состоянии.
res2001, про список отзыва я написал просто в самом начале первым же ответом.
Ты же писал про синхронизацию клиентских ключей - а она просто не нужна, ни в отношении открытых, ни в отношении закрытых.
>но в жизни часто это не так.
Ага, но это только то, что касается наших гос. УЦ - в жизни. В реальной. А в онлайновой, так сказать, все вполне соответствует чаще, чем не соответствует.
res2001, читай внимательно что тебе пишут, а писал я тебе про ovpn-сервер, а не про PKI. Центру сертификации необходимо знать, какие сертификаты им выпущены. Тому, что лишь проверяет подпись центра сертификации - в данном случае это OVPN сервер - этого знать не нужно.
И нет ни малейшего смысла тащить PKI вместе с CA, его закрытым ключом, и списком сертификатов им выпущенных, на второй сервер.
Что касается OSCP - не обязательно. В свойствах сертификата указываются точки распространения списка отзывов (CDP), и разные реализации PKI могут уметь (а могут не уметь) выгружать CRL полностью через них, причем вариации протоколов ограничены только возможностями PKI - хоть самба, хоть http, хоть нфс - что умеет, в общем. А сам OSCP не про списки отзывов как таковые, в общем то.
OVPN-сервер ничего не знает о клиентских ключах, и знать не должен. Знает только PKI. OVPN серверу надо знать только сертификат CA и список отзыва, но не клиентские ключи и сертификаты.
iCpu, лучше к драйверам присмотритесь, в том числе кардридера. Аппаратная неисправность кардридера едва ли может влиять на I/O операции других накопителей, а ошибки драйвера могут, причём не обязательно драйвера кардридера.
Владимир Юрченков,
щито, простите?
Я не знаю какую имплементацию OVPN и PKI вместе с ним вы используете; в стандартизированной терминологии, оторванной от конкретных реализаций - я расписал как что и зачем. Если в используемом вами PKI вместо CRL есть некие index-файлы с некими R метками - мне об этом ничего неизвестно.
В норме CRL должны быть подписаны закрытым ключом CA точно так же, как и выпускаемые этим CA сертификаты. Но может в случае OVPN в той реализации, которую вы используете, будет достаточно простого списка - не знаю.
Во-первых, что ты называешь ждущим режимом?
Во-вторых, включение/отключение монитора обычно не триггерит кхм, "звук". Скорее поверю, что случайным или не очень образом засыпают/просыпаются usb-порты
Имена компьютеров и групп произвольные, параметры подключения (кодек, блокировка ввода по-умолчанию, звук, и т.д.) могут быть сохранены как индивидуально для каждого компьютера, так и наследоваться от параметров группы; ID выдаются маршрутизатором - серверной частью, но могут быть сохранены и непосредственно ip - тогда маршрутизатор не нужен
Протокол свой, порты настраиваются
Для подключения без одноразового пароля на каждом клиенте должна быть задана пара логин/пароль; с одной стороны при массовой установке это неудобно, с другой стороны пара может быть задана через json при установке или импорте конфигурации.