--- date: '2026-05-03T01:26:20+03:00' lastmod: '2026-05-03T01:26:20+03:00' draft: false title: 'Факап с конфиге WG привел к потере 6 часов жизни' slug: '20260503-dns-routing' description: '' categories: - 'linux' - 'devops' tags: - 'linux' - 'wireguard' - 'netplan' keywords: - 'wireguard' - 'dns' - 'systemd-networkd' - 'netplan' cover: image: "hero.svg" alt: "Факап с конфиге WG привел к потере 6 часов жизни" relative: true --- Расскажу про то как один параметр в кофиге 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-файлы). Проверка статуса показала: ```bash 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. Отключение ожидания сети Чтобы система загружалась быстро, даже если сеть сбоит, отключил службу ожидания: ```bash 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` добавил: ```ini 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`: ```ini [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/`, чтобы избежать двойного применения настроек, и перезапустил службу: ```bash 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` я закомментировал всего лишь одну строку, как потом выяснилось добавленной в конфиг по рекомендаци такой же ИИшечки: ```ini # DNS = 1.1.1.1 ``` Переподнял туннель: ```bash 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]