Суть
По следам трёхдневного ярого совокупления с поломавшимся домашним сервером.
Подробно расписывать уже нет сил, поэтому это будет не академическая статья, а короткий чеклист: куда смотреть, если 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 |
1492 | PPPoE |
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-networkdsystemctl status NetworkManagerТакже можно посмотреть конфиги:
ls /etc/network/ls /etc/systemd/network/ls /etc/NetworkManager/Разбор различий между systemd-networkd, ifupdown и NetworkManager — это уже тема для отдельной статьи. Возможно, когда-нибудь я её напишу. Заодно и сам ещё раз нормально разберусь.
Короткий чеклист
Если Linux-сервер странно теряет сеть:
- Проверь
/etc/resolv.conf. - Если используется
systemd-resolved, смотриresolvectl status. - Проверь пинг по домену и по IP отдельно.
- Помни про DNS-кэш.
- Проверь маршруты через
ip route show. - Убедись, что есть рабочий
defaultroute. - Проверь, не прилетают ли DNS и маршруты по DHCP.
- Проверь MTU через
ping -M do. - Если нашёл рабочий MTU — временно выставь его через
ip link set. - Потом уже разбирайся, как сохранить настройку в твоём сетевом менеджере.
Итог
Странные сетевые проблемы редко чинятся одной магической командой.
Но если идти по порядку — DNS, маршруты, DHCP, MTU — шанс найти проблему становится сильно выше. А шанс три дня разговаривать с сервером на повышенных тонах становится чуть ниже.
Надеюсь, эти торопливые заметки мамкиного сисадмина кому-то помогут.