Ethernet и терминал Linux: настройка сети на сервере”

Debian 12 Server: сеть после установки — статический IP, DNS и проверки

04.02.2026

Зачем трогать сеть сразу

Сервер без предсказуемой сети — это лотерея. Сегодня он “сам как-то” получил адрес, завтра DHCP отдал другой, и ты ищешь машину как потерянный ключ от SSH. Сеть должна быть стабильной, понятной и проверяемой. Ниже — сценарий настройки Debian 12 Server после установки: выясняем, кто управляет сетью, делаем статический IP, приводим DNS к порядку и проверяем доступность так, чтобы потом не гадать.

Правило простое: сначала выясняем “кто главный” (NetworkManager, systemd-networkd или ifupdown), потом меняем конфиг. Иначе получишь два управляющих слоя и странные эффекты.

Диагностика: интерфейсы, адреса и маршрут по умолчанию

Смотрим имена интерфейсов, текущие адреса и default route. Это база, без неё любые правки — пальцем в небо.

ip -br link
ip -br addr
ip route

Проверка: есть один активный интерфейс (обычно enp0sX), есть адрес, есть маршрут по умолчанию через gateway.

Кто управляет сетью в Debian 12

На сервере чаще всего встречаются NetworkManager или systemd-networkd. Иногда остаётся классический ifupdown. Определяем фактом, а не предположением.

systemctl is-active NetworkManager || true
systemctl is-active systemd-networkd || true
dpkg -l | egrep 'network-manager|ifupdown' || true

Devil’s Advocate: если NetworkManager активен, не надо параллельно включать networkd. Два управляющих демона — это не “надёжнее”, это “веселее”.

Вариант A: systemd-networkd (рекомендуется для чистого сервера)

Если хочешь максимально предсказуемую серверную схему — networkd обычно идеален. Он прост, прозрачен и хорошо дружит с systemd.

Если NetworkManager активен и ты хочешь перейти на networkd, сначала выключаем его. Делай это только если у тебя есть консольный доступ, чтобы не отрезать себя.

sudo systemctl disable --now NetworkManager

Включаем networkd и resolved.

sudo systemctl enable --now systemd-networkd
sudo systemctl enable --now systemd-resolved

Создаём конфиг для интерфейса. Имя интерфейса возьми из вывода ip -br link, ниже пример для enp0s3.

sudoedit /etc/systemd/network/10-enp0s3.network
[Match]
Name=enp0s3

[Network]
Address=192.168.1.50/24
Gateway=192.168.1.1
DNS=1.1.1.1
DNS=8.8.8.8

Применяем изменения.

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved

Проверка: адрес на месте, маршрут на месте, DNS работает.

ip -br addr
ip route
resolvectl status | sed -n '1,80p'

Вариант B: NetworkManager (если он уже стоит и тебя устраивает)

Если система уже использует NetworkManager и сервер не “голый”, можно остаться на нём. Главное — не редактировать руками то, чем он управляет, без понимания.

Смотрим подключение и интерфейс.

nmcli device status
nmcli connection show

Дальше задаём статический IP в терминах NM. Название подключения возьми из nmcli connection show, ниже пример для Wired connection 1.

sudo nmcli con mod "Wired connection 1" ipv4.method manual
sudo nmcli con mod "Wired connection 1" ipv4.addresses 192.168.1.50/24
sudo nmcli con mod "Wired connection 1" ipv4.gateway 192.168.1.1
sudo nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
sudo nmcli con up "Wired connection 1"

Проверка: адрес, маршрут, DNS.

ip -br addr
ip route
cat /etc/resolv.conf

Devil’s Advocate: /etc/resolv.conf может быть симлинком и управляться resolved/NM. Это нормально. Плохо — когда ты его “прибил гвоздями” и забыл, что сделал.

Hostname и локальное имя

Хостнейм нужен не ради красоты. Он потом всплывает в логах, мониторинге, TLS и банальном “к кому я сейчас подключился?”.

hostnamectl
sudo hostnamectl set-hostname srv-debian12

Проверка: имя применилось.

hostnamectl | sed -n '1,10p'
hostname

NTP: корректное время — это часть сети

Если время скачет, у тебя “ломаются” сертификаты, логи и диагностика. В Debian 12 чаще всего достаточно systemd-timesyncd.

timedatectl
timedatectl timesync-status || true

Если синхронизация выключена, включаем.

sudo timedatectl set-ntp true
timedatectl timesync-status || true

Контрольные тесты: сеть должна доказывать, что она работает

Три уровня: линк/маршрут, DNS, HTTP/HTTPS. Без этого ты не знаешь, что именно сломалось.

Проверяем gateway и внешний мир.

ping -c 3 192.168.1.1
ping -c 3 1.1.1.1

Проверяем DNS.

getent hosts debian.org
resolvectl query debian.org || true

Проверяем HTTPS (если curl установлен).

curl -I https://debian.org | sed -n '1,12p'

Типовые ошибки

Самая частая — настроить networkd, когда NetworkManager всё ещё активен, и потом ловить “адреса-призраки”. Вторая — перепутать имя интерфейса (enp0s3 vs ens18) и думать, что конфиг “не работает”. Третья — забыть про DNS и диагностировать интернет по ping’у на 1.1.1.1, когда проблема именно в резолвинге.

Итог

После этих шагов сеть на Debian 12 Server становится предсказуемой: статический IP, понятный DNS, корректный hostname и время, плюс тесты, которые однозначно показывают, где именно проблема — линк, маршрут, DNS или прикладной уровень.

Важно

Если сервер удалённый и у тебя нет консоли провайдера, любые изменения сети делай крайне аккуратно. Проверяй, что текущая SSH-сессия жива, и держи вторую сессию для проверки. Самый надёжный способ “защитить сервер” — случайно отрезать от него доступ, так тоже умеют.