Максим Гришин

Как вариант, ошибки в реализации VPN на роутерах, или ошибки в работе VPN traversal на зухеле. Больше всего шансов на проблемы в работе TP-Link'a, который является VPN-сервером (вплоть до перегрева, кстати, что может запороть математику криптовычислений в его процессоре и ошибки установки соединения, пока перегрев не пропадет).

Членство в группах отрабатывается на этапе входа пользователя в домен. Нужно перелогиниться каждому пользователю, чтобы права на папку у него появились через группу.

Три гипервизора в кластере, хоть и с локальным хранилищем (Storage Spaces Direct - но дорогой как собака), или с общим iSCSI-хранилищем. Как вариант - рассмотреть Nutanix Community Edition из-за бесплатности, но по железу просит больше раза в полтора, чем совокупное требование ВМ, и в три по хранилищу, плюс просит обязательные SSD для метаданных. Тоже три хоста (максимум 4), но в отличие от S2D, на гигабите тоже живут, пусть и медленно. Администрируются, кстати, инженером любой подготовки, которые умеют рулить любым гипервизором, но подводных камней большая куча, в основном касательно обязательных обновлений и использования NVMe.

Нет AS - только DNS-записями рулить. Если бы у вас был AS, можно было бы подтянуть BGP и маршруты на третьем уровне для такого резервирования. Правда, договориться с провайдерами придется.

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

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

1) Нельзя. VMware умеет один диск назначить только одной ВМ. Golden Image - это всего лишь шаблон ВМ с установленными обновлениями, ПО и последующей очисткой временных файлов, из которого клонируются ВМ для нормальной работы (VDI как вариант, там ВМ временная и удаляется после завершения работы с ней пользователя). Возможно, удастся сэкономить место на хранилище, если включить на нем дедупликацию для дисков с операционной системой, но это не гарантировано, плюс будут проблемы по производительности в случае обновления ВМ без дополнительного диска avhd (т.е. без снапшота) - в этом случае постоянно будут кластеры, которые будут выходить из дедуплицированного состояния, и место на хранилище начнет заполняться, на это в общем случае хранилище будет реагировать медленнее, чем в ситуации без дедупликации.
2) Thin provision диски будут расти как обычно, thick provision не потеряют в производительности, но они сразу занимают максимальный размер, ещё при создании.
3) Неприменимо. Если разговор о Golden Image, он обновляется как обычная отдельная ВМ с последующим экспортом обратно в шаблон.
4) Неприменимо - придется сравнивать диски от разных ВМ, а у них первичный образ диска будет не один. То есть будет доступна только конфигурация с 10 отдельными дисками.
5) Туда же.

Данные по VMware ESXi 6.0 и моему опыту работы с ним. Если 6.5 что-то изменил, буду рад узнать.

после перезагрузки сервера (аварийно или контролируемо при проведении работ) он "забывает" права пользователей на папки.

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

Как вариант - в сервере села батарейка RTC, в результате он запускается с некорректным локальным временем, оттого и керберос не работает.

iptables -t nat -A POSTROUTING -s vlan1net/24 -d resource -j SNAT --to-source=router-ip

Где: vlan1net - подсеть, которой нужен доступ до того ресурса; resource - его айпишник (серый!); router-ip - айпишник, с которого ресурс доступен.
Само собой, правило должно отрабатывать раньше правила общего ната для подсети vlan1net.

Разворачиваете PKI, если ещё нет, поднимаете ВМ под каждый клиент-банк, разрешаете платежникам ходить на эти ВМ под доменными логинами, вешаете на них драконовские политики безопасности, но так, чтобы работал и RDP (шифрованный, кстати, будет, так что СБ будет довольна - по локалу никто не перехватит ключи) и клиент-банк(и), вывешиваете RDP-файлы от подключений к ним в папку, куда у платежников есть доступ только на чтение, и показываете всем заинтересованным сторонам. Платежникам - работать с клиент-банками вот так, синхронизировать доступ вот так (если только вы ещё и RDSH-лицензирование не настроите для этой структуры, тогда пользователи смогут работать параллельно на одной ВМ, но это дороже и нужно будет настраивать таймауты, чтобы юзера не забывали о сессиях, и т.п.), СБ - защищено это всё полноценным TLSv1.2 на каналах связи между ВМ и РМ пользователей.

МОЖНО.

И пусть параноит, может, какой толк будет из этого user'a.

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

Сложно ли - да, требуется голова помимо дампов, желательно ещё и опыт управления 2012м в реальных условиях.
Легко ли достать дампы - довольно легко (было), но на одни дампы полагаться нельзя.
Стоит ли сдавать - в 2014м стоило, правда 411й не осилил, потому что NAP нигде не было в досягаемости. Сейчас возможно стоит посмотреть в сторону таких же экзаменов, но про 2016й сервер.

Забыли правило на фильтре для доступа извне. Нечто вроде iptables -A FORWARD -d 10.61.255.1 -p tcp --dport 3389 -j ACCEPT (можно ещё -m conntrack --ctstate NEW добавить, если охота). Ну либо у сервера нет маршрута в интернет, и он не знает, куда ему слать SYN/ACK с приходящим айпи типа 1.2.3.4.

Похоже, что в UFW просто не разрешен входящий SSH. Разрешите, и будет вам счастье.

нужно RAID 0 под каждый диск пробовать сделать

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