Расскажу про то как один параметр в кофиге 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]

Сейчас я занимаюсь построением инфраструктуры для своей домашней лаборатории. В планах задействовать три сервера: один локальный машину дома и два VPS от разных провайдеров. Соответственно мне нужно организовать между ними защищенный канал связи для взаимодействия без лишних открытых наружу портов. Открыть порты сервисов наружу не хочется, поэтому лучшим решением стала виртуальная частная сеть на базе WireGuard.

Я пробовал разные варианты, но пришел к выводу, что лучше всего ставить WireGuard нативно прямо на хост-систему Ubuntu. Вариант с Docker тоже возможен, но он добавляет лишнюю сложность с пробросом портов и правами доступа. Нативная установка работает быстрее, управляется через стандартный systemd и проще интегрируется с фаерволом.

Начнем с установки. Это нужно сделать на всех машинах, которые будут участвовать в сети. В терминале выполняем обновление пакетов и установку утилит:

1
2

sudo apt update
sudo apt install wireguard wireguard-tools -y

После установки проверим, что модуль ядра загружен командой wg. Если увидели справку или пустой список интерфейсов, значит все прошло успешно.

1

wg

Следующий шаг - генерация ключей. Это нужно делать локально на каждом сервере. Приватный ключ никогда не должен покидать машину, а публичный мы будем передавать партнерам по сети.

1
2
3

cd /etc/wireguard
umask 077
wg genkey | tee privatekey | wg pubkey > publickey

Сохраните содержимое файлов privatekey и publickey в надежное место. Для примера в статье я буду использовать заглушки вида PRIVATE_KEY_HERE и PUBLIC_KEY_HERE.

Теперь создадим конфигурацию. Допустим, мы выделили под нашу сеть подсеть 10.8.0.0/24. Серверу с белым IP адресом назначим 10.8.0.1, а клиентам адреса вроде 10.8.0.2 и 10.8.0.3.

На сервере с белым IP создаем файл /etc/wireguard/wg0.conf. В секции Interface указываем его приватный ключ и слушаемый порт. В секции Peer добавляем публичные ключи клиентов.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[Interface]
PrivateKey = SERVER_PRIVATE_KEY_HERE
Address = 10.8.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT

[Peer]
PublicKey = CLIENT1_PUBLIC_KEY_HERE
AllowedIPs = 10.8.0.2/32

[Peer]
PublicKey = CLIENT2_PUBLIC_KEY_HERE
AllowedIPs = 10.8.0.3/32

Обратите внимание на строки PostUp и PostDown. Они нужны для того, чтобы при подъеме интерфейса автоматически применялись правила фаервола, разрешающие пересылку пакетов.

На клиенте, который находится за NAT (например, домашний сервер), конфигурация будет проще. Ему нужно знать публичный ключ сервера и его белый IP адрес.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Interface]
PrivateKey = CLIENT1_PRIVATE_KEY_HERE
Address = 10.8.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY_HERE
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.8.0.0/24
PersistentKeepalive = 25

Параметр PersistentKeepalive важен для клиентов за натом. Он отправляет служебные пакеты каждые 25 секунд, чтобы роутер не забывал об открытом соединении.

Прежде чем запускать туннель, нужно подготовить сеть. На сервере обязательно включаем пересылку пакетов (IP Forwarding), иначе трафик не будет ходить между интерфейсами.

1
2

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Также нужно настроить фаервол. Если у вас активен UFW, откройте порт UDP 51820 и разрешите маршрутизацию для интерфейса wg0.

1
2
3
4

sudo ufw allow 51820/udp
sudo ufw route allow in on wg0 out on wg0
sudo ufw route allow in on wg0 out on eth0
sudo ufw route allow in on eth0 out on wg0

В командах выше замените eth0 на имя вашего основного сетевого интерфейса.

Теперь самый важный момент, на котором я лично споткнулся. После любого изменения файла конфигурации wg0.conf необходимо перезапускать сервис интерфейса. Правила PostUp выполняются только в момент создания интерфейса. Если вы просто отредактировали файл и забыли перезапустить службу, новые правила фаервола не применятся, и соединения не будет.

Правильный порядок действий после правки конфига выглядит так:

1
2

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

Или через системную службу:

1

sudo systemctl restart wg-quick@wg0

Не пренебрегайте этим шагом. Именно отсутствие перезагрузки часто приводит к тому, что интерфейс поднят, ключи верны, но пакеты теряются по пути.

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

1

sudo systemctl enable wg-quick@wg0

Для диагностики состояния туннеля используйте команду wg show. Запустите ее в режиме мониторинга, чтобы видеть изменения в реальном времени:

1

watch -n 1 wg show

Смотрите на поле latest handshake. Если время там постоянно обновляется (например, 5 seconds ago, 10 seconds ago), значит соединение активно и пакеты ходят. Если время застыло или указано none, значит пакеты не доходят. Проверьте фаерволы и убедитесь, что порт открыт у провайдера VPS.

Также проверяйте счетчики трафика transfer. Если при пинге счетчик received растет, значит пакеты доходят до интерфейса WireGuard. Если пинга нет, но трафик есть, проблема скорее всего в маршрутизации внутри системы или блокировке ICMP фаерволом.

В итоге вы получите безопасную сеть, где серверы видят друг друга по внутренним IP адресам. Сервисы вроде баз данных можно слушать только на интерфейсе туннеля, и они будут недоступны из внешнего интернета.

Удачи в построении вашей лаборатории!