Расскажу про то как один параметр в кофиге Wireguard причинил мне опыт по разбору половины сетевых настроек Ubuntu. Один с виду безобидный параметр… IaC блин нужен обязательно. Я просто забыл что и для чего менял, а потом уже поздно было вспоминать.

Симптомы: тишина в эфире и гора dropped пакетов

Всё началось с того, полсе смерти системного диска в моем домашнем сервере, я перестал крутить его 24/7 и набегами по выходным конифгурировал его, пытаясь вернуть привычный набор сервисом. И вот однажды включаю я сервер, а у меня проблема с системным резолвом DNS. Так-то напрямую nslookup ya.ru 8.8.8.8 выдает всё нормально. но система ни в какую не хочет резолвить адреса. Так-то я забыл, что неделей ранее я настраивал Wireguard со своими VPS, и что именно после настройки Wireguard сервер потерял доступ к локальной сети и интернету. начал ковырять, ИИшка подсказала что на Ubuntu надо netplan копать, начал фигачить yamlики, тут время вышло и я еще на неделю забросил комп. И вот вчера, сейчас далеко за полночь, я его включил и опять начал разбираться, естественно забыл не только то что я две недели назад делал, но и то чем неделю назад занимался. И вот картинка, сервер загрузился, подозрительно долго грузился кстати, но по сети недоступен.

Первая диагностика через ip -s link show показала тревожную картину на интерфейсе eno1:

• RX: 53 000+ пакетов принято.
• Dropped: 21 000+ пакетов отброшено.
• TX: Всего 40 пакетов отправлено.

Команда ip route show выводила только маршрут для интерфейса wg0. Маршрута по умолчанию через физический интерфейс не было. Система «не видела» шлюза.

Команда ip a показала, что на всех интерфейсах, кроме loopback, ip-адреса отсутствуют.

Попытки перезапустить службы или применить конфигурацию через sudo netplan apply не давали результата. Интерфейс зависал в состоянии configuring, а адрес не присваивался.

Расследование: кто виноват?

1. Конфликт маршрутизации

Первоначальная гипотеза была в том, что WireGuard перехватывает весь трафик. Однако в конфиге wg0.conf параметр AllowedIPs был ограничен подсетью туннеля (10.8.0.0/24). Он не должен был блокировать локальную сеть.

Проблема оказалась глубже: отсутствие маршрута по умолчанию для eno1 означало, что ядро просто не знало, куда девать исходящие пакеты, кроме как в туннель (если бы он был активен) или в никуда.

2. Почему DHCP молчал?

Ubuntu 24.04 использует стек systemd-networkd для управления сетью на серверных сборках. Конфигурация задается через Netplan (YAML-файлы).

Проверка статуса показала:

1
2

networkctl status eno1
State: routable (configuring)

Статус configuring в сочетании с routable — это классический признак того, что демон ждет завершения какой-то операции. В логах journalctl -u systemd-networkd не было ошибок получения адреса IPv4, зато постоянно терялась аренда IPv6 (DHCPv6 lease lost).

Оказалось, что systemd-networkd по умолчанию пытается настроить и IPv4, и IPv6. Если сервер DHCPv6 не отвечает или есть проблемы с Router Advertisements (RA), демон может зависнуть в ожидании, блокируя переход интерфейса в полностью рабочее состояние для IPv4.

3. Долгая загрузка

При перезагрузке я заметил, что система висит на этапе Job systemd-networkd-wait-online.service. Однако служба wait-online держала систему, пока сеть не поднимется. Поскольку сеть не могла подняться из-за зависшего DHCP-клиента, загрузка затягивалась.

Решение: поэтапный демонтаж проблем

Шаг 1. Отключение ожидания сети

Чтобы система загружалась быстро, даже если сеть сбоит, отключил службу ожидания:

1
2

sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl mask systemd-networkd-wait-online.service

Шаг 2. Отключение IPv6

Возможно проблема долгой загрузки была в ожидании ответов IPv6, а поскольку в моей инфраструктуре он пока не критичен, то я отключил его на уровне ядра. Это сузило площадь ошибок в конфигурации systemd-networkd, я сосредоточился только на IPv4.

В /etc/sysctl.conf добавил:

1
2
3

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.lo.disable_ipv6=1

И применил изменения: sudo sysctl -p.

Шаг 3. Переход на прямую конфигурацию systemd-networkd

Файлы Netplan (/etc/netplan/*.yaml) генерируют конфиги для бэкенда. У меня их было два, и они могли конфликтовать или содержать избыточные параметры, тем более я уже и не помнил как и почему я их именно так писал. Изолировал прослойку Netplan, создав файл-заглушку /etc/systemd/network/10-eno1.network с настройками для systemd-networkd:

1
2
3
4
5
6
7
8

[Match]
Name=eno1

[Network]
DHCP=ipv4
IPv6AcceptRA=no
DNS=1.1.1.1
DNS=8.8.8.8

Ключевой момент здесь — DHCP=ipv4. Тут явно говорим демону: «Используй только IPv4, игнорируй IPv6». Параметр IPv6AcceptRA=no дополнительно страхует от ожидания сообщений роутера.

Удалил старые файлы из /etc/netplan/, чтобы избежать двойного применения настроек, и перезапустил службу:

1

sudo systemctl restart systemd-networkd

Интерфейс сразу получил адрес 192.168.1.3 и перешел в статус routable (configured). Системный резолв DNS заработал.

Шаг 4. Финальный босс: DNS и WireGuard

Пинги пошли, но nslookup ya.ru выдавал таймауты на 127.0.0.53 (локальный stub-resolver systemd-resolved). Вот про эту штуку я не знал, поэтому теперь знаю что не нужно поднимать на каждом сервер unbound, в systemd все есть из коробки.

Проверка resolvectl status показала странность:

• Link 2 (eno1): DNS Servers: 1.1.1.1, 8.8.8.8
• Link 5 (wg0): DNS Domain: ~.

Правда я её не заметил сперва, но консультации с ИИ не всегда являются потерей времени. Символ ~. означает «глобальный поиск». WireGuard, увидев в своем конфиге строку DNS = 1.1.1.1, автоматически сообщил системе, что этот DNS-сервер должен обрабатывать все запросы, перекрывая настройки физического интерфейса. Но так как туннель до собственных серверов и маршрутов до внешних DNS в нём нет, разрешения имен не работали.

Решение: В файле /etc/wireguard/wg0.conf я закомментировал всего лишь одну строку, как потом выяснилось добавленной в конфиг по рекомендаци такой же ИИшечки:

1

# DNS = 1.1.1.1

Переподнял туннель:

1
2

sudo wg-quick down wg0
sudo wg-quick up wg0

Теперь wg0 имеетв выводк networkctl status eno1 Current Scopes: none, а все DNS-запросы идут через основной интерфейс eno1 на публичные серверы Cloudflare и Google.

Итоги и выводы

1. WireGuard и DNS: Параметр DNS в конфиге WireGuard — это не просто рекомендация, а команда для системы изменить глобальные настройки резолвинга. Если ты не хочешь, чтобы туннель перехватывал все DNS-запросы, не указывай этот параметр в конфиге клиента, либо используйте более тонкие настройки Domains (если клиент поддерживает).
2. Ubuntu 24.04 и IPv6: По умолчанию включенный IPv6 может вызывать задержки при получении адреса IPv4, если инфраструктура не готова к v6. В домашних лабораториях его часто проще отключить, чем дебажить RA и DHCPv6.
3. Netplan vs systemd-networkd: Netplan удобен, но иногда прямая конфигурация systemd-networkd дает больше прозрачности и контроля, особенно при отладке сложных случаев с DHCP.
4. systemd-networkd-wait-online: На серверах, где сеть может падать или долго подниматься, эту службу лучше маскировать, иначе она будет тормозить загрузку всей ОС.

Эта ошибка в конфиге WG стоила мне нескольких часов, но теперь моя домашняя лаборатория работает стабильно, а конфиги приведены к минимальному и понятному виду, а я узнал еще что-то новенькое про любимый Линукс.

(Ссылка на диалог с Qwen)[https://chat.qwen.ai/s/0cfbc11b-dae3-4dba-bfaf-b0788172d07c?fev=0.2.45]