CityCat4

Мыслите бизнесс-процессом, а не админскими категориями. Что, по-Вашему нужно, чтобы сайт работал и работали бесперебойно? То и делайте.

Бэкапы и защиту от взлома конечно стоит настроить. Отказоустойчивость - ну, это очень емкий термин и он может оказаться весьма дорогим, хотя тут надо уточнить, что Вы под этим понимаете :)

Задача как задача, вполне себе. Видимо есть основания скрывать тот факт, что целевой сервер в РФ. Бывает. Есть такие -
"...Где с умилением глядят
На заграничные наклейки...
А сало... русское едят! " (С) Михалков С.В. Две подруги.

К баранам.

Задача сводится к обычному нату, который меняет в пакете пришедшем на порт 3389 IP назначения с локального на некий удаленный - после чего ведро ессно этот пакет отправляет в мир на дефолтный шлюз.

Во-первых - всем и каждому, кто впал в затуп и не знает, как проходит пакет по netfilter - рекомендую эту схему. Распечатать и повесить на рабочем месте.

Сначала зададим допущения.
IP сервера = 212.20.5.1 (много-много лет назад это был IP нашего сервера, он реально российский :) )
IP VPS = 170.70.1.1 (взят с потолка)
Политика по умолчанию для filter - ACCEPT (все, что не запрещено - разрешено. Очень опасная политика, вязта только для демонстрации, в жизни так делать нельзя. Мне просто неохота писать дополнительные правила по пропуску трафика)

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

NAT мы выполняем в цепочке prerouting таблицы nat (она идет до filter). Сюда пакет попадает сразу после mangle prerouting.

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p tcp --dport 3389 -d 170.70.1.1 -j DNAT --to-destination 212.20.5.1

Читается "если поступил пакет по протоколу tcp на порт 3389 на IP 170.70.1.1, то применить действие DNAT, заменив IP назначения на 212.20.5.1. Правило поместить в цепочку prerouting".

Что теперь? А теперь, поскольку мы поменяли IP назначения и он теперь не локальный - ведро считает, что пакет нужно отправить (routing decision на схеме) - в цепочку forward. Сначала mangle forward, потом filter forward (это и есть основная таблица, которую обычно и зовут файрволлом, мы в ней пропускаем все).

Потом mangle postrouting и nat postrouting. В nat postrouting нам нужно сделать небольшой камуфляж. В пакете IP назначения 212.20.5.1 - но IP источника - тот IP, с которого пакет пришел на VPS. Это нам не нужно и потому что задача - его скрыть и потому что при попадании пакета на 212.20.5.1 - он ответит ессно на этот IP. Поэтому выполняем следующее:

-A POSTROUTING -o eth0 -j SNAT --to-source 170.70.1.1

Читаем "если пакет уходит через интерфейс eth0, то применить действие SNAT и заменить IP источника на 170.70.1.1"
Это стандартное правило NAT, оно присутствует всегда, если VPS является NAT хоть для чего-нибудь.

Все. Пакет на 212.20.5.1 уходит от IP 170.70.1.1, тот отвечает по IP источника, VPS видит, что был NAT и отправляет пакет туда, откуда он пришел.

Через стандартный сетевой сервис - FTP/SMB - запросто.

Зависит от того, насколько глубокий анализ нужен будет. В простейшем случае достаточно netflow писать (я когда-то trafd для этого использовал), но там никаких черных и белых списоков конечно же нет.
В более сложном случае - поставить squid, правда нужно помнить, что нынешний тырнет практически весь на https, так что бампинг будет просто насущной необходимостью.
Перетыкать ничего никуда не надо, все делается на логическом уровне.

Причем тут VPN? VPN - это

Virtual (Виртуальная, то есть воображаемая)
Private (Частная)
Network (Сеть)

Она Вам никак не поможет. RDP может быть поможет, но просмотр виедо по RDP - это мазо :)

Рут слетит точно.
twrp скорее всего нет.

За все ТЦ конечно не скажу, да и давненько подключать не приходилось., но кое-что сказать могу:

Обычно ТЦ делятся на два типа - те, в которых несколько провайдеров и те, которые еще при строительстве "продались" какому-то одному (я с этим столкнулся однажды, когда подключал магазин в одном очень крупном городском ТЦ - он продался РТК, а тот работал разумеется... как всегда :) )
Начинается все, как правило с обращения в администрацию ТЦ - вполне может быть, что она все сделает сама.
Если же нет, узнать у нее, какой пров есть в здании и обратиться к нему.
Если пров не устраивает - снова обратиться к администрации с вопросом - пустят ли другого прова - запросто могут отказать.
Если отказали - тут либо хавать, что дают, либо менять ТЦ (что редко бывает возможно)
Правда подключение через другого прова, если его в здании нет может быть существенно дороже

На Win7/8/10 - никак. Потому что это десктоп, а не сервер и в нем ровно одно удаленное соединение.

Для домашнего сервера нет понятия "выгодно" - его ради денег не держат, если пытаться на нем заработать - это дохлый номер от слова совсем. Домашний сервер держат:
- люди, не доверяющие хранение почты и файлового архива "облакам"
- люди, держащие игровые, файловые и прочие сервера "для своих"
- ИТ-шники для самых разнообразных целей

Бизнес-затраты на содержание уже готового сервера копеечные - утюг/чайник сьедает электричества больше. Правда, если это настоящий сервер, а не псевдо-"сервер из десктопа", то придется смириться с тем, что он:
- жужжит (даже специально подобранная модель, даже в самом тихом режиме гудела заметно, а летом взвывала периодически)
- занимает весьма неудобное место - это большая плоская хреновина

"Сервер-из-десктопа" таких недостатков обычно лишен, правда если питание часто дергают, лучше при нем иметь "руки", чтобы можно было что-то сделать.

Никак :) BIOS (EFI) должен знать, что эти два диска - RAID, для чего нужно соответствующим образом настроить его или поставить RAID-контроллер. Чисто программный RAID, который строит винда - он BIOS неизвестен.

Есть набор корпоративных инструментов, в которых у пользователей должны быть личные аккаунты : Dropbox, Airtable, Zoom, Slack и тд

Чи-во?

В энтерпрайзе у пользователей нет личных аккаунтов. Все выдается админами и все контролируется админами (саппортом, если компания достаточно крупна, чтобы разделить админов и саппорт - при этом учетка все же заводится админами, но настройкой ее займется саппорт).

Routerboard.com - это микротик.

Они точно были со стороны локальной сети, а не со стороны внешнего IP? Со стороны внешнего IP Вас будут постоянно сканировать и постоянно искать, чем поживиться :)

Это называется "метод полного погружения" и обычно рекомендуется как самый свирепый но самый эффективный метод изучения иностранного языка :)

Если Вы не знаете линуха, Вам будет очень тяжело. Потому что микротик - это линух, просто на него натянута слегка благородящая его морда (но понимания всей сетевой части линуха это не отменяет). В нем нет никаких визардов, которые не дали бы Вам выстрелить себе в ногу и даже quick setup сделает некую "усредненную" конфигурацию, вовсе не факт, что подходящую Вам.

rb2011 - неплохая модель, хоть и довольно старая уже, но зато с wifi. В ней пять гигабитных и пять 100Мб портов. Ну или можете представлять его как компьютер с десятью сетевыми картами :)

Качаете winbox и ставите его (можно с телефона, в маркете есть конфигуратор, он очень похож на winbox), quick setup обычно wifi подымает.
Идете в гугл и зарываетесь в него, руководств по настройке микротика полно.
Сначала надо добиться провайдерского подключения - если оно на dhcp - настроить dhcp-клиент на нужном порту, если на статике - научиться самому ее прописывать.
Потом настроить локалку (хотя quick setup может ее настроить, но научиться не мешает)
Потом разобраться с безопасностью настроек wifi и файрволлом.

Микротик - мощная штука... в умелых руках :)

Где найти местоположение файла CONFIG.SYS в windows 8?

Чо???

Его уже в win7 не было, и даже в winXP он присутствовал в виде эфемерного файла размером 0 байт. Это древнючий артефакт времен начала 90-х, входивший в состав ядра системы msdos (autoexec.bat, config.sys, io.sys и msdos.sys).

Никак, потому что эту штуку и придумали специально против умников, пытающихся втихушку подсунуть хрень типа кейлоггера на бухгалтерский комп :)

В логах винды все должно быть. Правда не знаю, причем тут RTSP - потоковый протокол реального времени, по которому обычно голос идет в IP-телефонии :)

Я бы посоветовал что-то, но боюсь автор может последовать моему совету буквально...

На месте Вашего директора я бы заплатил вымогателю (если там есть контакт, потому что многие шифровальщики сделаны школотой и там даже мыла нет) - а потом удерживал бы эту сумму из Вашей зарплаты :)

Привязка к аппаратному сертификату. Ну или хотя бы к программному сертификату. Если это конечно возможно.

НО:

если стоит задача дать возможность открывать файл одним, но не давать это делать другим, чтобы исключить утечку данных, то Вы решаете ее не теми средствами, если ценностью являются именно данные, а не организация их в книге (то есть - если ценностью являются числа, приведенные в книге - Вы ошибаетесь, если ценностью является порядок сортировки, среднее, диаграммы etc - что можно поменять в книге в нужном тебе порядке - то еще пойдет).

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

Конечно возможно. Такое было возможно еще в 70-е :)

man write (написать кому-то конкретному)
man wall (написать всем, кто залогинен)