# Віддалений офіс на 19 робочих місць

Орендували фізичний сервер у дата-центрі в Нідерландах з помісячною орендою ліцензій. Диски зібрали в дзеркало RAID-1 і синхронізували завантажувальний розділ, щоб сервер стартував навіть після смерті одного диска. На залізі працює лише Hyper-V, а вся робота людей живе у віртуальній машині.

Що сталось: віртуальний сервер не виходив у мережу з виданої провайдером адреси. Виявилось, що цю IP уже займав сервер іншого клієнта.

Як вирішили: зібрали докази скриптом, написали в підтримку, отримали нову адресу і перенесли на неї сервер.

Що сталось: після встановлення Hyper-V система відкрила служби керування для всього інтернету. Правила віддаленого робочого стола і ліцензування теж стояли «дозволено звідусіль».

Як вирішили: адмін-доступ — тільки через окремий VPN, робочий стіл — тільки через VPN працівників. Зверху — аварійні блокуючі правила на випадок, якщо хтось помилково відкриє порт. Зовнішнє сканування: жодного відкритого порту.

Що сталось: через кілька днів на фізичному сервері з’явились дві програми віддаленого доступу, встановлені без погодження. Це були двері в обхід усього VPN.

Як вирішили: зберегли журнали, з’ясували, хто і навіщо їх ставив, видалили до останнього файлу. Пояснили простими словами, чому на хості не має бути нічого, крім віртуалізації.

Щоб наступний такий випадок не залежав від везіння, поставив щогодинного сторожа на хост і віртуалку. Він звіряє з еталоном адміністраторів, служби, задачі, правила брандмауера і входи. На робочому столі адміна — ярлик «SRV status»: диски, бекапи, VPN, тривоги і чужі входи на одному екрані.

Рішення: генератор одним запуском створює користувача і пакує йому архів: VPN-ключ, інсталятор в один клік, ярлик та інструкція. Людина розпаковує, запускає і працює.

Підводний камінь: свіже оновлення Windows почало лякати попередженням про «невідоме віддалене підключення» і за замовчуванням вимикати буфер обміну та принтери. Замість того щоб вимикати цей захист, я підписав ярлики власним сертифікатом, а інсталятор додає йому довіру. У працівників — жодного попередження.

Принтер працівника прокидається на сервер через сам віддалений робочий стіл і працює як локальний. На сервер не ставиться жодного драйвера, і чековий принтер в іншому офісі друкує так само.

Рішення: щоночі — експорт цілої віртуальної машини: 7 копій, перевірка цілісності дисків, захист від переповнення диска. Усередині сервера — тіньові копії файлів тричі на день, щоб витягти видалений документ за хвилину. AppLocker запущений у режимі аудиту, щоб зібрати картину запусків перед блокуванням.

Підводний камінь: копію мало зробити — її треба відновити. Тестове відновлення показало, що експорт зберігає стан пам’яті машини, а друга копія не вміщається в пам’ять хоста. Підібрали процедуру, і відновлення тепер займає 2 хвилини.

Що сталось: працівники не бачили базу, яку створив менеджер, або отримували «сервер уже працює». Причина: серверна частина програми запускалась від імені того, хто зайшов першим, і кожен сеанс бачив свій окремий екземпляр.

Як вирішили: окремий службовий обліковий запис для сервера програми і правильні дозволи на запуск. Механіку пояснили менеджеру клієнта простими словами, і він застосував її сам.

Що сталось: нові працівники отримували помилку при старті програми. Виявилось, що файл налаштувань першим створив інший користувач, і решта не могла в нього писати.

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

Що сталось: на ноутбуках із масштабом 125–150% рахунки друкувались дрібно. Перша версія фіксу примусово ставила 100%, і друк став нормальним. Але вилізли два нові болі: сервер відкривався вікном зі смугами прокрутки, а люди з поганим зором не могли збільшити картинку.

Як вирішили: перестали лікувати всіх і вилікували одну програму: для облікової системи на сервері увімкнено режим сумісності DPI. Ярлики повернули до масштабу ПК: сервер відкривається на весь екран, кожен бачить свій масштаб, а друк лишився точним. Перевірка — порівнянням PDF до і після, без жодного принтера під рукою.

Що сталось: коли замовник доналаштував базу, сторож видав десятки змін. Серед них три небезпечні: працівник з правами адміністратора; копії всієї бази, доступні всім 19 людям; папка системної служби, куди будь-хто міг підкласти файл і стати адміном. Правила брандмауера програми стояли «звідусіль».

Як вирішили: спершу аудит без жодних змін, потім погодження із замовником по кожному пункту. Усе закрили одним скриптом з бекапом прав і відкатом, а відразу після — перевірили, що програма і друк працюють.

Що сталось: скрипт замовника для копії бази в хмару формально працював, а сервіс моніторингу показував зелене. Насправді задача запускалась лише тоді, коли адмін сидів на сервері. Шлях до хмарного клієнта був хибним, а на вхід у хмару скрипт чекав 15 секунд замість 2–3 хвилин. Ще й хмарний клієнт захоплював файл логу, і наступний бекап впав би.

Як вирішили: задача працює в режимі без входу користувача і без збереженого пароля. Хмарний клієнт стартує окремо, а скрипт чекає входу до 4 хвилин. Скрипт замовника правився точково, з копією оригіналу. Тест: архів створено, синхронізація йде, моніторинг зелений уже не дарма.