Перейти к основному содержимому

Если Linux-сервер странно теряет сеть: DNS, маршруты и MTU

··943 слов·5 минут

Суть

По следам трёхдневного ярого совокупления с поломавшимся домашним сервером.

Подробно расписывать уже нет сил, поэтому это будет не академическая статья, а короткий чеклист: куда смотреть, если Linux-сервер ведёт себя странно.

Симптомы примерно такие:

  • сервер то принимает подключения, то не принимает;
  • пинг может идти по 20 секунд;
  • обновление системы зависает на подключении к внешним адресам;
  • одни сайты открываются, другие нет;
  • кажется, что интернет есть, но “какой-то не такой”.

Если всё это знакомо, скорее всего, проблема где-то в сетевой конфигурации.

1. Сначала проверь DNS

Первым делом смотри DNS. Да, банально. Да, всё равно смотри.

Открой файл:

cat /etc/resolv.conf

Если внутри написано, что это заглушка от systemd-resolved, проверяй DNS через:

resolvectl status

Если там обычный список DNS-серверов без предупреждений, прочитай его глазами и проверь доступность серверов имён вручную.

Например:

ping 77.88.8.8

Или другой DNS-сервер, который у тебя указан в конфиге.

В условиях нашей весёлой сетевой реальности лишним это точно не будет.

2. Отдели проблему DNS от проблемы сети

Хороший простой тест:

ping ifconfig.me

А потом:

ping 77.88.8.8

Логика такая:

Что происходитВозможная причина
IP пингуется, домен нетпроблема с DNS
Не пингуется ни домен, ни IPпроблема не только в DNS
Работает через разсмотри DNS, маршруты, MTU и потери

Важно помнить: DNS кэшируется.

После изменений в конфиге проверяй не только тот домен, который уже дёргал раньше, но и что-то новое. Полезно иметь в голове или в заметке небольшой список сайтов для проверки, чтобы не ловить фантомы из кэша.

3. Проверь маршруты

Если DNS не виноват, смотри маршруты:

ip route show

Как минимум должен быть маршрут по умолчанию. Обычно он выглядит примерно так:

default via 192.168.1.1 dev eth0

Точный интерфейс и адрес шлюза, конечно, будут другими.

Главное, чтобы:

  • маршрут default был;
  • шлюз был правильный;
  • интерфейс был тот, через который сервер реально ходит в сеть;
  • до шлюза был доступ.

Проверить шлюз можно так:

ping 192.168.1.1

Если маршрута по умолчанию нет или он странный, смотри, кто управляет сетью:

  • systemd-networkd;
  • ifupdown;
  • NetworkManager;
  • DHCP-клиент;
  • настройки гипервизора или роутера, если сервер виртуальный или домашний.

Иногда помогает перезапуск сетевой службы. Иногда не помогает, но создаёт ощущение, что ты хотя бы что-то сделал.

Логи всё равно читать придётся.

4. Не забудь, что DNS может приехать по DHCP

Если DNS внезапно стал неправильным, это не всегда значит, что ты руками сломал /etc/resolv.conf.

DNS-серверы часто прилетают по DHCP от роутера, провайдера, виртуальной сети или чего-то ещё, что считает себя главным в этой маленькой трагедии.

Поэтому, если DNS постоянно возвращается к неправильному значению, проверяй не только локальные файлы, но и источник сетевой конфигурации.

5. Если всё выглядит нормально — проверь MTU

Если одни пакеты проходят, другие нет, сайты открываются выборочно, SSH вроде работает, но обновления или загрузки зависают, стоит проверить MTU.

Особенно если в схеме есть:

  • PPPoE;
  • VPN;
  • туннели;
  • виртуальные сети;
  • странный роутер;
  • провайдер с фантазией.

Сначала посмотри интерфейсы:

ip link show

или:

ip addr show

Найди основной интерфейс: тот, на котором публичный IP или локальный адрес от роутера.

У интерфейса будет параметр mtu, например:

mtu 1500

Частые значения:

MTUГде встречается
1500обычный Ethernet
1492PPPoE
1280минимально допустимое значение для IPv6
другоеVPN, туннели, виртуальные сети, особые случаи

6. Как проверить MTU через ping

Из значения MTU нужно вычесть 28 байт: это размер заголовков IPv4 и ICMP.

Например, для MTU 1500:

1500 - 28 = 1472

Проверяем:

ping -M do -c 4 -s 1472 8.8.8.8

Что здесь происходит:

-c 4

Пинговать не бесконечно, а 4 раза.

-s 1472

Отправить ICMP-пакет с payload размером 1472 байта.

-M do

Поставить флаг Do not fragment, то есть запретить фрагментацию.

Если пакет проходит без фрагментации — хорошо.

Если не проходит — начинаются те самые непредсказуемые приколы, ради которых мы все и любим администрирование.

7. Как найти рабочее значение MTU

Если 1472 не проходит, уменьшаем размер:

ping -M do -c 4 -s 1464 8.8.8.8

Потом ещё:

ping -M do -c 4 -s 1452 8.8.8.8

И так далее, пока не найдёшь максимальный размер, который проходит.

Потом к найденному размеру добавляешь 28.

Например, если проходит 1464:

1464 + 28 = 1492

Значит эффективный MTU — 1492.

У меня, например, из-за PPPoE на роутере максимальный MTU не 1500, как позволяет обычный Ethernet, а 1492, потому что PPPoE забирает 8 байт на свои служебные заголовки.

8. Как временно выставить MTU

Например, если интерфейс называется eth0:

sudo ip link set dev eth0 mtu 1492

Если интерфейс называется иначе, подставь своё имя:

ip link show

После этого снова проверь сеть.

Но важно: это временная настройка. После перезагрузки она, скорее всего, пропадёт.

9. Как сохранить MTU постоянно

А вот тут начинается весёлое.

Способ зависит от того, кто управляет сетью:

  • systemd-networkd;
  • ifupdown;
  • NetworkManager;
  • cloud-init;
  • настройки роутера;
  • настройки гипервизора;
  • что-то ещё, что ты обнаружишь в самый неподходящий момент.

Поэтому универсальной одной команды здесь не будет.

Для начала можно понять, что вообще управляет сетью:

systemctl status systemd-networkd
systemctl status NetworkManager

Также можно посмотреть конфиги:

ls /etc/network/
ls /etc/systemd/network/
ls /etc/NetworkManager/

Разбор различий между systemd-networkd, ifupdown и NetworkManager — это уже тема для отдельной статьи. Возможно, когда-нибудь я её напишу. Заодно и сам ещё раз нормально разберусь.

Короткий чеклист

Если Linux-сервер странно теряет сеть:

  1. Проверь /etc/resolv.conf.
  2. Если используется systemd-resolved, смотри resolvectl status.
  3. Проверь пинг по домену и по IP отдельно.
  4. Помни про DNS-кэш.
  5. Проверь маршруты через ip route show.
  6. Убедись, что есть рабочий default route.
  7. Проверь, не прилетают ли DNS и маршруты по DHCP.
  8. Проверь MTU через ping -M do.
  9. Если нашёл рабочий MTU — временно выставь его через ip link set.
  10. Потом уже разбирайся, как сохранить настройку в твоём сетевом менеджере.

Итог

Странные сетевые проблемы редко чинятся одной магической командой.

Но если идти по порядку — DNS, маршруты, DHCP, MTU — шанс найти проблему становится сильно выше. А шанс три дня разговаривать с сервером на повышенных тонах становится чуть ниже.

Надеюсь, эти торопливые заметки мамкиного сисадмина кому-то помогут.

Кирилл Белоусов
Автор
Кирилл Белоусов
Также известен как cyrmax. Пишу код, тестирую, автоматизирую инфраструктуру и помогаю делать цифровые продукты доступнее.