Debian homelab – це мінімальна і передбачувана база для домашнього сервера, на якій зручно тримати Docker, reverse proxy, файлові сервіси, VPN і дрібні внутрішні сервіси без зайвого GUI. Нижче – робоча схема: установка, перший вхід, мережа, SSH, оновлення, firewall і перевірка стану системи.
Для homelab Debian беруть не через «красивість», а через спокійну поведінку після оновлень. Якщо сервер має жити місяцями без сюрпризів, це сильний аргумент. Зворотний бік теж є: занадто консервативний стек не завжди зручний для найновішого заліза або свіжих пакетів.
Цей сценарій орієнтований на headless-встановлення. Результат – чистий Debian-сервер з доступом по SSH, статичною або передбачуваною адресацією, базовим захистом і нормальною точкою старту для self-hosted інфраструктури.
Що вибрати під час встановлення Debian для homelab
Для Debian homelab оптимальна схема проста: мінімальна система без desktop environment, окремий звичайний користувач, SSH-сервер і тільки ті пакети, які реально потрібні після першого входу. Чим менше зайвого на старті, тим менше фону, конфліктів і дивних сервісів у пам’яті.
ISO краще брати з офіційного сайту Debian. Для домашнього сервера зазвичай достатньо стандартного інсталятора. Графічне оточення, print server і подібні ролі на цьому етапі не потрібні.
Під час розмітки диска практичний варіант – окремий кореневий розділ і swap, якщо машина проста і без складної схеми з ZFS чи LVM. Для homelab це часто кращий старт, ніж надто розумна розмітка з першого дня. Коли сервер один, а сервісів небагато, простота відновлюється швидше, ніж «гнучкість на майбутнє».
На етапі вибору софту достатньо залишити лише SSH server і standard system utilities. Якщо поставити GUI «про всяк випадок», потім доведеться прибирати зайві залежності, служби логіну, display manager і непотрібні пакети.
Базове налаштування Debian homelab після першого входу
Після інсталяції Debian homelab потрібно довести до передбачуваного стану: оновити пакети, перевірити hostname, час, мережу, SSH і доступ через звичайного користувача. Саме тут закладається нормальна експлуатація, а не під час самої установки.
Спочатку варто зайти локально або через консоль гіпервізора, оновити систему і переконатися, що пакетний менеджер працює без помилок.
apt update apt full-upgrade -y
Далі має бути звичайний користувач із правом виконання адміністративних команд через sudo. Працювати під root по SSH у homelab можна, але це швидкий шлях до зайвих помилок і поганої дисципліни доступу.
apt install sudo -y usermod -aG sudo ім_я_користувача
Корисно одразу перевірити hostname і часовий пояс. Некоректний час ламає журнали, TLS, планувальник задач і діагностику мережевих проблем.
hostnamectl timedatectl
Якщо потрібно змінити hostname:
hostnamectl set-hostname debian-homelab
На невеликому сервері цей блок здається дрібницею. Потім саме дрібниці з hostname і часом заважають шукати причину, чому контейнер стартує, але доступ до нього поводиться дивно.
Як налаштувати мережу на Debian homelab без сюрпризів
Для Debian homelab мережа має бути або статичною, або хоча б передбачуваною через DHCP reservation на маршрутизаторі. Домашній сервер із плаваючою адресою швидко перетворюється на проблему для DNS, reverse proxy, моніторингу і SSH-доступу.
Спочатку треба з’ясувати назву інтерфейсу:
ip a
На Debian конфігурація мережі залежить від способу встановлення і середовища. На простих інсталяціях часто достатньо налаштування через стандартні системні механізми. Якщо адреса керується DHCP на роутері, практичний варіант для homelab – закріпити lease за MAC-адресою, а не тримати статичну адресу лише на самому сервері. Так менше шансів забути, де саме змінювалася адресація.
Після змін треба перевірити не лише наявність IP, а й маршрут за замовчуванням та резолвінг імен.
ip r ping -c 4 1.1.1.1 ping -c 4 debian.org
Якщо пінг до IP працює, а до домену ні, проблема майже завжди в DNS. Для homelab це типовий збій після поспішної ручної правки мережі або зміни локального resolver.
SSH на Debian homelab: що змінити одразу
SSH у Debian homelab має бути доступним, але не розхлябаним. Мінімум – вхід під звичайним користувачем, авторизація ключами і заборона root login, якщо аварійний доступ не зав’язаний саме на нього.
Спочатку встановлюється і вмикається OpenSSH Server, якщо його не вибрали в інсталяторі:
apt install openssh-server -y systemctl enable --now ssh systemctl status ssh
Далі перевіряється конфігурація. Зазвичай потрібні такі зміни: заборонити прямий вхід root і вимкнути парольну автентифікацію після додавання ключів.
nano /etc/ssh/sshd_config
PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes
Після змін конфіг варто перевірити і лише потім перезапускати службу:
sshd -t systemctl restart ssh
Класична помилка – вимкнути парольний вхід до того, як ключі реально перевірені з іншої машини. Якщо сервер без локальної консолі, так легко відрізати собі доступ. Спочатку нова SSH-сесія, потім жорсткіші правила.
Який мінімум безпеки потрібен відразу
Базова безпека Debian homelab не зводиться до firewall. Потрібно закрити зайві шляхи входу, обмежити відкриті сервіси і залишити машину в стані, де будь-який запущений порт з’явився свідомо, а не випадково після встановлення пакета.
Спочатку варто подивитися, що вже слухає мережу:
ss -tulpn
Потім – увімкнути простий firewall. Для невеликого homelab достатньо дозволити SSH і відмовляти всьому іншому вхідному трафіку, поки не з’явиться конкретний сервіс.
apt install ufw -y ufw allow OpenSSH ufw enable ufw status verbose
Ще один корисний крок – автоматичні оновлення безпеки, якщо сервер не потребує ручного контролю кожного пакета. Для критичних self-hosted сервісів іноді краще ставити оновлення вручну, але для базового вузла це зменшує вікно ризику.
apt install unattended-upgrades -y dpkg-reconfigure unattended-upgrades
Нетипова, але регулярна проблема в homelab – відкритий порт після «нешкідливого» встановлення пакета. Наприклад, ставиться інструмент керування, а разом з ним стартує веб-інтерфейс або демон на всіх інтерфейсах. Перевірка через ss після кожного нового сервісу економить більше часу, ніж здається.
Які пакети варто додати на чистий Debian-сервер
Для Debian homelab після інсталяції зазвичай потрібен короткий набір утиліт: редактор, інструменти діагностики мережі, моніторинг процесів, сертифікати і базові пакети для роботи з архівами. Цього вистачає, щоб нормально обслуговувати машину без зайвого баласту.
apt install -y vim curl wget ca-certificates gnupg lsb-release htop btop net-tools dnsutils tmux unzip
Список не є обов’язковим стандартом. Його сенс у тому, щоб не лізти на сервер із напівпорожнім середовищем щоразу, коли треба перевірити DNS, відкрити довгу сесію в tmux або швидко подивитися навантаження.
Для контейнерного вузла наступним кроком часто стає Docker або Podman. Для storage-вузла – Samba, NFS або backup-агент. Краще не ставити це «пакетом на майбутнє». Чистіший базовий вузол простіше оновлювати і переносити.
Як перевірити, що Debian homelab готовий до роботи
Перевірка Debian homelab зводиться до кількох речей: сервер завантажується без помилок, має стабільну мережу, приймає SSH по ключу, отримує оновлення і не слухає зайвих портів. Якщо ці пункти закриті, систему вже можна використовувати як основу під self-hosted сервіси.
- Перевірити ім’я хоста і час.
hostnamectl timedatectl
- Перевірити адресу, маршрут і DNS.
ip a ip r ping -c 4 1.1.1.1 ping -c 4 debian.org
- Перевірити SSH з іншої машини саме по ключу.
ssh ім_я_користувача@IP_СЕРВЕРА
- Перевірити список відкритих портів.
ss -tulpn
- Перевірити стан служб і помилки останнього завантаження.
systemctl --failed journalctl -p 3 -xb
Якщо після ребута пропадає мережа, проблема майже завжди в неправильній прив’язці до інтерфейсу або конфлікті між ручним налаштуванням і тим, як адреса видається в локальній мережі. Якщо після ввімкнення firewall зникає доступ, спочатку дивляться правило для SSH, а не «ламають» firewall повністю.
Де Debian для homelab ламається найчастіше
Найчастіші збої в Debian homelab банальні: неправильний DNS, зарано вимкнений парольний SSH, непотрібний GUI, ручна правка мережі без розуміння поточної схеми і надмірне встановлення пакетів «про запас». Проблема не в Debian, а в тому, що базову систему часто ускладнюють у перший же день.
- Немає доступу по SSH після hardening. Спочатку перевіряється вхід у новій сесії, тільки потім вимикається пароль.
- Сервіси не доступні по імені. Дивляться DNS і hostname, а не сам сервіс у першу чергу.
- Після оновлення щось перестало стартувати. Перевіряються failed units і журнали, а не виконується навмання reinstall.
- Сервер став «важким» без видимої причини. Часто причина в зайвих демонах, які прийшли разом із GUI або супутніми пакетами.
Є ще одна межа застосовності. Якщо Debian homelab використовується як один універсальний вузол для всього – файловий сервер, VPN, reverse proxy, backup, медіасервіс і десятки контейнерів – проблема з часом стає не в дистрибутиві, а в відсутності розділення ролей. До певного масштабу одна машина нормальна. Далі простіше рознести сервіси по ролях або хоча б по віртуальних машинах.
Що робити після базового налаштування
Коли Debian homelab уже в стабільному стані, наступний крок залежить від ролі вузла: контейнерний runtime, reverse proxy, резервне копіювання, файлові сервіси, VPN або моніторинг. Базова система не повинна заважати цим сценаріям, і саме тому її варто тримати простою.
Якщо потрібна максимально спокійна платформа під self-hosted сервіси, Debian закриває задачу добре. Якщо ж сервер постійно потребує нових ядер, свіжих драйверів або дуже нових пакетів, межа цієї моделі швидко стає помітною. У такій точці проблема не в налаштуванні, а в тому, що обрано не той базовий дистрибутив під конкретне залізо або темп змін.
Офіційний сайт проекту: Debian.