athacker

Шо это за трэш вообще? :-) Условие задачи явно неполно. Либо вы не полностью сформулировали условие, либо опустили бОльшую часть контекста. Что сделать-то нужно? Что означает "разместить IP-адрес"?

Никаких других вариантов, кроме блокировки консоли (упомянутой выше Win+L) тут нет. Но в зависимости от версии винды, можно держать залогиненными две пользовательских сессии. И когда одна сессия заблокирована, другой пользователь может пользоваться своей сессией. Но это возможно, по-моему, только начиная с Professional-версий винды, на Home Basic всяких такого нет. Минимальная версия винды, где это есть -- Win 7 Home Premium.

Не рекомендовал бы ставить на сервера какую-то постороннюю хрень, которая постоянно отгружает какие-то данные за пределы конторской сети... Поставьте куда-нибудь Zabbix, и настройте в нём мониторинг своих серверов/оборудования.

Поддерживаю оратора выше, предложившего VPN по интернету. На каждой точке заводим интернет от двух разных провайдеров и строим автоматическую схему переключения канала на резерв.

Камрады выше правильное замечание сделали -- сильно будет зависеть от драйвера. А драйвер, в свою очередь, будет сильно зависеть от операционки ;-)

Нарисуйте лучше схему, что как подключено, и какие IP-адреса на интерфейсах. Откуда подключается клиент -- из интернета, или из той же локалки, куда он должен получить доступ? :-)

NAS4FREE по дефолту всё на ZFS делает. У ZFS есть квоты на датасет.

Там подробности какие-нибудь в ошибке есть? Обычно есть.

СХД, как и многие другие вещи -- это дело такое... Если у вас возникает вопрос "а зачем нужны СХД", то значит, вам она точно не нужна :-)

В чём профит СХД -- это многократно зарезервированная система. У неё от двух до N контроллеров, каждая дисковая полка подключена минимум двумя путями, каждый диск подключен двумя путями (SAS-диск, конечно же), и на дисках используются механизмы типа T10-PI, гарантирующие целостность данных. Диски имеют пропатченные прошивки, логика работы этой прошивки такова: "лучше мы ложно зафейлим диск, чем случится реальный сбой, а мы его прошлёпаем и потеряем данные".

Также есть всякие функциональные штуки типа моментальных снапшотов, механизмов репликации (когда у вас два географически разнесённых тома имеют полностью одинаковое содержимое и синхронизируется практически в прямом эфире). СХД умеет tiered storage, когда система реализует кэш наиболее горячих данных на базе SSD-дисков или в RAM.

Но надо понимать, что сама СХД и расходники для неё будут стоить как крыло от F-35, и СХД нужно брать ТОЛЬКО с соответствующими сервисными контрактами. Без сервисного контракта -- любой сбой будет вам обходиться в копеечку, а время ремонта может исчисляться месяцами. С другой стороны, СХД довольно надёжны, и количество сбоев у них не очень велико. С третьей стороны, вендоры очень любят брать деньги за воздух. Например, у IBM есть такая практика -- если у вас истёк сервисный контракт, а вы его не продлили, а потом у вас случился сбой и вы решили купить сервисный контракт обратно, то вам в стоимость добавят стоимость годичного сервисного контракта в виде штрафа. Т. е. если вы решите спустя N лет приобрести сервисный контракт на 2 года, то по факту заплатите как за 3 года -- "1 год условно" вам выставят в виде штрафа. Этим грешит не только IBM, но и ещё ряд вендоров.

СХД нужна только для случаев, когда у вас критичные бизнес-процессы, и любая их остановка -- это настолько крупные потери, что стоимость этих потерь превышает стоимость СХД и сервисных контрактов на неё. В остальных случаях я бы рекомендовал самосборные хранилища и организацию процесса работы с ними так, чтобы минимизировать риски и последствия возможных сбоев.

Для чисто файловых хранилищ подойдёт, например, Windows Storage Spaces в конфигурации с двумя серверами и одной двух-контроллерной корзинкой DAS, подключенной к обоим серверам. Это гораздо дешевле СХД, а многие вещи такая конфигурация умеет -- нет единой точки отказа, умеет RAID на дисках, умеет условно tiered storage и умеет снапшоты средствами VSS на винде.

На фре тоже сейчас активно пилят High Availability в ctld. Полагаю, включат в 11.0, и можно будет строить отказоустойчивые iSCSI-хранилки на основе FreeBSD+ZVOL+ctld -- отличный вариант под хранение виртуалок. Причём ZFS тоже умеет снапшоты, вот если бы Veeam научился с ними работать, была б ваще чума... :-)

Шлюз по умолчанию в VPN-соединение при таком сценарии вы засунуть не сможете. Точнее, сможете, но только если через этот белый IP на эту виртуалку ходят только с фиксированного набора IP-адресов в интернете. Тогда можно на эти IP-адреса прописать выделенно шлюз.

Обычно задача решается в виде наоборот -- для сетей, которые проходят через VPN задаются статические маршруты, а вот шлюз по умолчанию остаётся на месте без изменений.

В топике набег линуксоидов :-) ХЗ, те, кто жалуется на какие-то проблемы на фре -- просто не умеют её готовить. Банально, да? :-) На трёх моих последних местах работы фря использовалась по полной. И на текущем месте работы выносим с линукса всё, что можно, и оставляем только то, что нельзя -- как правило, сильно специфичный софт, разработанный только под линукс. Всё остальное -- PPPoE-сервера, веб, почта, мониторинг, вспомогательные сервера, файловые сервера -- всё крутится на фре. Никаких проблем, что характерно, при этом мы не испытываем.

Я не знаю, какие там технологии используют ораторы выше, которые они не могут использовать на фре, но никаких принципиальных ограничений именно FreeBSD как платформы, я не встречал.

Есть проблемы конкретных продуктов на фре -- это да. Про битрикс не скажу, но производительность самбы на линуксе выше, чем на фре. Но это проблема не системы, а скорее самой самбы, разработчики которой не захотели разбираться с проблемами самбы на фре.

В целом фря -- достаточно хорошая система, и гораздо более логично устроенная внутри, нежели многие дистрибутивы линукса. Есть сценарии, которые линукс может реализовать, а фря -- нет. Но также есть и обратные сценарии. Так что нет тут нет универсального рецепта.

Любые "универсальные" сервисы на фре работают нормально. Про проблемы с пакетными менеджерами -- это трэш, линуксоиды всё врут :-) Они сильно отстали от жизни, особых проблем с пакетными менеджерами давно уже нет. Отдельно доставили сказки про то, что если ты собираешь софт из портов, то потом с пакетами у тебя будут проблемы :-)

ZFS на линуксе сильно отстаёт по функционалу от ZFS на фре. В ZFS-on-linux только в прошлом релизе был добавлен алгоритм сжатия lz4, что на фре есть уже больше двух лет. Недавно была добавлена поддержка ACL, что опять-таки, фря умеет уже давно.

Короче, примеров можно привести миллион, но вывод довольно простой -- не надо верить заявлениям, что "инструмент XXX -- это фу-фу-фу, а инструмент YYY -- это ого-го". У любого из них есть свои плюсы и минусы, просто нужно их знать, и использовать подходящий инструмент. Если вы планируете настраивать сервера "в корпорации" или для задач провайдера связи, или просто свой сайтик в интернет выложить -- и фря, и линукс эти задачи решит отлично. Если будете делать какую-то хранилку, под виртуализацию, например -- я бы использовал фрю. Если же у вас план делать крупный высоконагруженный web-проект -- возможно, тут линукс подойдёт лучше.

Я, как бывший корпоративный админ, а ныне админ интернет- и сервис-провайдера, никаких проблем с фрёй в своей работе не испытываю.

Для винды самое фэншуёвое -- это RDP. Для убунту... А у вас чо, Убунта с графикой используется? 8-[ ]

На Win10 только один вариант -- поставить какую-нибудь хрень, которая умеет делать NAT и порт-маппинг. Типа Kerio Winroute, или как оно там называется сейчас. И настроить на нём маппинг соответствующих портов между белым IP на физическом интерфейсе и серым IP в виртуальной сети.

Хотя я не очень понимаю, что вам мешает на каком-нибудь авито купить домашний роутер за 300 рублей, и настроить порт-маппинг на нём. Винду с белым IP-шником вам сломают из интернета в первые же часы, инфа 146%.

Если по-простому, то можно сделать так: отключить все порты коммутаторов, которые не используются. На коммутаторе настроить port security -- чтобы каждый порт был с привязкой по MAC. Если будет воткнутно устройство с другим MAC-ом, то сеть у него не поднимется. Соответственно, для того, чтобы воткнуть ноут или что-либо другое -- придётся сначала из включенного порта выткнуть то, что туда уже было подключено, и настроить на "нелегальной" железке такой же MAC, как и на легальной.

Либо таки да -- 802.1x. Но для этого нужно и соответствующее оборудование, и поддержка со стороны клиентов (рабочих станций, или чо там ещё у вас в сети).

А на FreeBSD эта задача никак не решается. Можно контролировать доступ в интернет, допустим, через прокси с авторизацией. Но не подключение/отключение устройств в сети, этим в любом случае коммутаторы заведуют. Ну, хотя если решитесь на 802.1x, тогда на фре можно RADIUS-сервер поднять :-)

Самба на фре всегда страдала проблемами с производительностью. Насколько мне известно, это не лечится никак. Были у сообщества одно время попытки аппелировать к команде Самбы на эту тему, но они закончились после ответа от Samba team в духе: "Идите лесом, у нас на линухе всё работает ровно". Так что если от Самбы реально нужен гигабит -- ставьте её на линух.

Вытаскивание батарейки может не сбросить BIOS. Вытащите батарейку и замкните перемычку, которой сбрасываются настройки CMOS.

Подобным образом проявлял себя руткит TDSS: sysadmins.ru/post12865581.html#12865581

А огласите результат команд zfs list и zfs get all data/data

Возможно, FreeNAS выставляет квоту сразу, чтобы файловой системе не было мучительно больно, если места на датасете останется меньше определённого лимита. ZFS в таких случаях испытывает затруднения.