Я решила использовать мини‑ПК DEXP Compact M008 как учебный сервер: для экспериментов с Linux, сетями, Docker и удалённым доступом. Казалось бы — стандартная задача. На практике всё пошло по классическому сценарию: «вчера работало, сегодня нет».

Ниже - реальный опыт установки Ubuntu Server, базовой настройки и диагностики сетевых проблем, которые сначала выглядели мистикой, а потом оказались вполне объяснимыми.

Установка Ubuntu Server

Система — Ubuntu Server 24.04 LTS, образ с официального сайта Ubuntu.
Загрузочная флешка, загрузка с неё (в моём случае — F11), стандартный инсталлятор.

На этапе установки:

  • разметку диска оставила дефолтной - для учебного сервера этого достаточно;

  • создала пользователя;

  • после завершения установки перезагрузилась и вошла в систему.

Никаких сюрпризов. Пока.

Первичная настройка

Обновление системы

Начала с очевидного:

sudo apt update
sudo apt upgrade -y

SSH-доступ

SSH по умолчанию не оказался установлен, поэтому проверила статус:

sudo systemctl status ssh

Установила и включила сервис:

sudo apt install openssh-server -y
sudo systemctl enable ssh
sudo systemctl start ssh

Проверила, что сервис активен, и узнала IP-адрес сервера:

ip a

На этом этапе всё работало: я могла подключаться по SSH из локальной сети.

Wi-Fi: решение, которое выглядело разумным (и оказалось ошибкой)

Ethernet-портов на роутере не хватало, поэтому я решила подключить сервер по Wi-Fi. Для учебного проекта - «ну сойдёт», подумала я.

Скрытый текст

Спойлер: нет.

Для управления сетью установила NetworkManager:

sudo apt install network-manager -y
sudo systemctl enable NetworkManager
sudo systemctl start NetworkManager

Подключение выполнила через nmtui. Wi-Fi подключился, SSH работал, сервер выглядел живым и довольным. Ровно до следующего дня.

Когда SSH просто перестал работать

На следующий день SSH перестал подключаться. Клиент стабильно выдавал timeout.

Началась диагностика:

  • переподключения (вдруг повезёт);

  • подключение монитора к мини-ПК;

  • проверка IP-адреса, состояния SSH и сетевых интерфейсов.

Система была жива:

  • IP есть;

  • SSH запущен;

  • интерфейс активен.

Но по сети сервер был недоступен.

Настоящая причина: энергосбережение Wi-Fi

Проблема оказалась не в SSH и не в firewall, а в Wi-Fi-адаптере, который уходил в режим энергосбережения. Для серверной системы - это почти гарантированный источник нестабильности.

Проверка состояния Wi-Fi

sudo iw dev wlp1s0 link

Соединение выглядело подозрительно нестабильным.
Проверка режима энергосбережения дала ответ:

sudo iw dev wlp1s0 get power_save

Результат:

Power save: on

Адаптер периодически «засыпал», и вместе с ним засыпал весь сервер. После отключения режима энергосбережения SSH снова стал стабильно доступен.

Однако на этом этапе стало очевидно главное:
даже с отключённым энергосбережением Wi-Fi остаётся нестабильным решением для сервера. Поэтому, не дожидаясь новых сюрпризов, я подключила мини-ПК по Ethernet через сплиттер. С этого момента локальная сеть стала полностью стабильной, а Wi-Fi был окончательно исключён из схемы.

Доступ к домашнему серверу извне: что пошло не так с ZeroTier

Параллельно я пробовала ZeroTier как простой способ удалённого доступа. Формально всё выглядело хорошо:

  • интерфейс поднимался;

  • статус ONLINE;

  • авторизация прошла.

Но ping то появлялся, то пропадал. Сначала я подумала, что проблема в Wi-Fi, но после перехода на проводное подключение Ethernet работал стабильно, локальная сеть была в порядке, SSH по LAN работал без проблем. При этом ZeroTier продолжал вести себя нестабильно ping появлялся и пропадал, соединение могло «отваливаться» без изменений на стороне сервера, поведение было непредсказуемым.

Иными словами, проблема была в самом ZeroTier, а не в базовой сети.

Формально ZeroTier выглядел как удобное решение:

  • минимум настройки;

  • быстрый старт;

  • работает поверх NAT.

Но на практике для моей задачи он оказался неподходящим решением.

Итоговое решение: VPN через VPS

В результате я выбрала классическую и надёжную схему:

  • VPS с белым IP - центральный узел;

  • мини-ПК и клиентские устройства - подключаются к нему;

  • VPN на базе WireGuard.

Это решение оказалось:

  • стабильным;

  • прозрачным в диагностике;

  • независимым от домашнего провайдера и NAT.

Выводы

  1. Wi-Fi можно починить, но это не делает его серверным решением.
    Даже с отключённым энергосбережением он остаётся потенциальной точкой отказа.

  2. Ethernet — обязательная база для сервера.
    Пусть даже через сплиттер — это всё равно лучше, чем Wi‑Fi.

  3. ZeroTier — не панацея.
    При всей простоте он может работать нестабильно даже при идеальной базовой сети.

  4. VPS + WireGuard — скучно, зато предсказуемо.
    А предсказуемость — главное качество серверной инфраструктуры.