Віддалений офіс на 19 робочих місць
Офісу на 19 робочих місць потрібен був новий термінальний сервер. Я приблизно за тиждень, повністю дистанційно, його підняв. 19 людей працюють в обліковій програмі через власний VPN, з інтернету сервер не видно, а щоночі робиться копія, відновлення з якої я перевірив на практиці.
Що хотів клієнт
- В офісі тонкі клієнти, решта підключається з дому через VPN.
- Усі сидять в одній обліковій програмі на SQL-базі.
- Рахунки на A4 і чеки в іншому офісі друкуються на принтери працівників.
- Дослівно: «щоб вірус не зніс усе». Збій чи зараження не мають дістати до копій.
- Архівні копії, з яких можна швидко піднятись.
- Ліцензії RDS помісячно, а не наперед.
- І окремо: нічого не робити без запиту. Спершу питаю, потім роблю.
Рішення
Уся робота людей живе у віртуальній машині. Фізичний сервер тільки керує нею і зберігає її копії.
- RDS · 19 сесій одночасно
- Облікова програма + SQL
- Тіньові копії 3 рази на день
- AppLocker · контроль запусків
Чому саме так:
- Якщо вірус і проб’ється, то у віртуалку. Хост і нічні копії лишаться цілими, а повернутись до вчорашнього стану можна за 2 хвилини.
- VPN два, і вони окремі. Працівник через свій потрапляє тільки на робочий стіл, до керування сервером йому дороги немає.
- Друк іде через сам RDP. Принтер удома чи в офісі працює, а на сервері не стоїть жодного драйвера.
Історія розробки
Нижче все в тому порядку, як відбувалось. Кожну зміну я робив скриптом PowerShell: перед нею знімав копію стану, і на кожну був окремий скрипт відкату.
Новий сервер і фундамент
Взяли в оренду фізичний сервер у дата-центрі в Нідерландах, ліцензії теж помісячно. Диски зібрав у дзеркало RAID-1 і синхронізував завантажувальний розділ: помре один диск, сервер усе одно стартує. На залізі тільки Hyper-V, уся робота людей у віртуальній машині.
Адреса, яка вже була чиєю
Віртуальний сервер не виходив у мережу з адреси, яку видав провайдер. Покопався і з’ясував, що цю IP уже зайняв сервер іншого клієнта. Зібрав докази скриптом, відправив у підтримку, отримав нову адресу й переїхав на неї.
Windows сам відчинив двері
Після встановлення Hyper-V система взяла й відкрила служби керування на весь інтернет. Правила для віддаленого робочого стола і ліцензування теж стояли «дозволено звідусіль».
Закрив. Керування тепер тільки через адмінський VPN, робочий стіл тільки через VPN працівників. Поверх цього аварійні блокувальні правила, на випадок якщо хтось колись помилково відкриє порт. Зовнішнє сканування показало нуль відкритих портів.
Сторож і стан сервера в один клік
Не хотілось, щоб наступного разу все залежало від везіння. Поставив на хост і на віртуалку сторожа, який щогодини звіряє з еталоном адміністраторів, служби, задачі, правила брандмауера і входи. В адміна на робочому столі ярлик «SRV status»: диски, бекапи, VPN, тривоги й чужі входи на одному екрані.
Друк без драйверів
Принтер працівника прокидається на сервер через сам віддалений робочий стіл і поводиться як локальний. На сервері жодного драйвера. Чековий принтер в іншому офісі працює точно так само.
Резервні копії, які справді відновлюються
Щоночі експортується вся віртуальна машина. Тримаю 7 копій, перевіряю цілісність дисків і стежу, щоб копії не забили диск. Усередині сервера тричі на день тіньові копії файлів, щоб видалений документ можна було витягти за хвилину. AppLocker поки в режимі аудиту: спершу збираю картину, що взагалі запускається, і тільки потім блокую.
Зробити копію мало, з неї треба вміти піднятись. Перше ж тестове відновлення показало проблему: експорт зберігає стан пам’яті машини, а друга копія в пам’ять хоста вже не влазить. Підібрав процедуру, і тепер відновлення займає 2 хвилини.
Масштаб, рамка і друк рахунків
На ноутбуках із масштабом 125–150% рахунки друкувались дрібно. Перший фікс просто ставив усім 100%. Друк виправився, але вилізли дві нові проблеми: сервер відкривався у вікні зі смугами прокрутки, а люди з поганим зором не могли збільшити картинку.
Тоді я перестав лікувати всіх і полікував одну програму: для облікової системи на сервері ввімкнув режим сумісності DPI. Ярлики повернув до масштабу ПК. Сервер знову на весь екран, у кожного свій масштаб, а друк лишився точним. Перевіряв порівнянням PDF до і після, бо принтера під рукою не було.
Аудит після чужих налаштувань
Замовник сам доналаштував базу, і сторож видав десятки змін. Три з них були реально небезпечні: працівник із правами адміністратора; копії всієї бази, відкриті всім 19 людям; папка системної служби, куди будь-хто міг підкласти файл і стати адміном. А правила брандмауера програми стояли «звідусіль».
Спершу провів аудит, нічого не чіпаючи. Потім кожен пункт погодив із замовником. Закрив усе одним скриптом із бекапом прав і відкатом, і одразу перевірив, що програма й друк працюють.
Що я виніс для себе
Головне з цього проєкту: перевіряти треба кінець ланцюжка, а не зелену галочку.
- Відновлення треба перевірити, а не припустити. Перший же тест знайшов проблему, яка під час справжньої аварії з’їла б години.
- Налаштуванням за замовчуванням не довіряю. Windows сам відкрив керування на весь інтернет, тож після змін завжди дивлюсь на сервер ззовні.
- Лікую конкретну проблему, а не всіх одразу. Масштаб 100% для всіх зламав зручність, а режим сумісності для однієї програми все вирішив.
- Не роблю того, про що не просили. Пропоную, але вирішує клієнт, і саме на цьому тримається довіра.
Результат
Офіс працює на новому сервері. 19 людей заходять одним значком з дому чи з офісу, принтери друкують, а ззовні сервер не видно.
Копії є на трьох рівнях: весь сервер щоночі, файли тричі на день, база щодня в хмару. Стан усього адмін бачить в один клік, а про будь-які несподівані зміни повідомляє сторож.