156 lines
12 KiB
Markdown
156 lines
12 KiB
Markdown
---
|
||
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] |