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

Простая аналогия:

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

Для чего нужны setuid биты?

Основные случаи использования:

1. Смена пароля (/usr/bin/passwd)

   1 2	ls -la /usr/bin/passwd -rwsr-xr-x 1 root root 68208 апр 8 10:15 /usr/bin/passwd

   • Обычный пользователь должен менять свой пароль
   • Пароли хранятся в защищенном файле /etc/shadow, доступном только root
   • Setuid позволяет passwd временно получить права root для записи в /etc/shadow

2. Команда sudo (/usr/bin/sudo)

   1 2	ls -la /usr/bin/sudo -rwsr-xr-x 1 root root 232416 фев 9 2024 /usr/bin/sudo

   • Позволяет выполнять команды от имени root
   • Без setuid sudo не сможет повысить привилегии

3. Другие примеры:

   • ping — требует root для создания сетевых сокетов
   • su — переключение на другого пользователя
   • mount/umount — монтирование файловых систем

Как распознать setuid биты?

Визуальное обозначение:

1
2
3
4
5
6
7
8

# Обычный файл
-rwxr-xr-x  # нет setuid

# Файл с setuid (s вместо x в позиции владельца)
-rwsr-xr-x  # есть setuid

# Файл с setgid (s вместо x в позиции группы)
-rwxr-sr-x  # есть setgid

Буква s в позиции execute (x) означает, что установлен setuid/setgid бит.

Как просмотреть все файлы с setuid:

1. Поиск по всей системе:

   1	sudo find / -type f -perm -4000 -ls 2>/dev/null

2. Только в стандартных директориях:

   1	sudo find /usr/bin /usr/sbin /bin /sbin -type f -perm -4000 -ls

3. С подробной информацией:

   1 2 3 4 5

   # С владельцем и правами sudo find /usr -type f -perm -4000 -exec ls -la {} \; 2>/dev/null # Или более компактно sudo find /usr/bin -type f -perm -4000 | xargs ls -la

4. Числовое представление:

   1	stat /usr/bin/sudo | grep Access

   Setuid бит = 4000 в восьмеричной системе (4 = setuid, 2 = setgid, 1 = sticky bit)

Как установить/убрать setuid бит:

Символический способ:

1
2
3
4
5

# Установить setuid
sudo chmod u+s /path/to/file

# Убрать setuid
sudo chmod u-s /path/to/file

Числовой способ:

1
2
3
4
5

# Установить (4755 = setuid + 755 права)
sudo chmod 4755 /path/to/file

# Убрать (755 = обычные права)
sudo chmod 755 /path/to/file

Почему это важно для безопасности?

Риски:

1. Вредоносные программы могут использовать setuid для получения root-доступа
2. Ошибки в setuid-программах — частая причина взломов
3. Лишние setuid биты расширяют поверхность атаки

Аудит безопасности:

1
2
3
4
5

# Найти все setuid файлы для проверки
sudo find / -type f -perm -4000 -ls 2>/dev/null | sort

# Сравнить с "чистой" системой
# Неожиданные setuid файлы должны настораживать

Практический пример из моей практики:

Я где-то ошибся и сделал своего пользвоателя владельцем /usr/, слом судо и пока пытался починить выполнил find /usr -type d -exec chmod 755 {} \;, это не затронуло файлы. Но когда следом сделал:

1

sudo find /usr -type f -exec chmod 644 {} \;

Эта команда сбросила setuid биты на всех файлах, включая sudo, passwd и другие. Поэтому sudo опять перестал работать.

Правильно было бы:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Сначала сохранить список setuid файлов
sudo find /usr -type f -perm -4000 > /tmp/setuid_backup.txt

# Потом менять права
sudo find /usr -type f -exec chmod 644 {} \;

# И восстановить setuid биты из сохраненного списка
while read file; do
  sudo chmod 4755 "$file"
done < /tmp/setuid_backup.txt