Пропала сеть одна из самых частых и стрессовых ситуаций в работе администратора. В этот момент легко поддаться панике и начать хаотично перезагружать всё подряд: серверы, коммутаторы, роутеры. Но такой подход не только неэффективен, но и может усугубить проблему, стерев важные улики из логов.
Ключ к быстрому решению системный подход. Используя эталонную модель OSI, мы будем подниматься от самого нижнего, физического уровня, к верхнему, прикладному. Нужно начать с проверки кабеля и сетевой карты, и только если там всё в порядке, переходить к IP-адресам, маршрутизации и DNS. В этой методичке мы разберём каждый шаг: какие команды использовать, что искать и как интерпретировать результаты.
Пошаговая инструкция
Мы пройдём пять ключевых уровней, начиная с того, где проблема возникает чаще всего.
Уровень 1: Физический (Physical Layer)
На этом уровне мы проверяем всё, что можно потрогать руками: кабели, порты на коммутаторах и сетевые карты сервера. Если индикатор активности на сетевой карте не горит, проблема, скорее всего, здесь.
-
Проверяем статус интерфейса. Команда
ip link showпокажет список всех интерфейсов. Нас интересует флагUP. Если интерфейс выключен, его нужно поднять:sudo ip link set eth0 up. -
Смотрим детальную информацию.
ethtool eth0это наша главная утилита для диагностики физического уровня. В её выводе ищем строкуLink detected: yes. Это гарантирует, что кабель подключён и есть физический контакт. Также проверяемSpeedиDuplex: они должны совпадать с настройками на коммутаторе. Несовпадение может указывать на неисправный кабель или неправильные настройки автосогласования. Можно запустить и встроенный тест карты:sudo ethtool -t eth0.
Уровень 2: Канальный (Data Link Layer)
На этом уровне мы проверяем настройки VLAN, агрегацию каналов (bonding) и таблицу MAC-адресов. Здесь же кроется одна из самых частых причин проблем на виртуальных машинах.
-
Проверяем MAC-адрес. Команда
ip link show eth0покажет аппаратный адрес интерфейса. Важно убедиться, что он не нулевой (всё из нулей) и не конфликтует с другими устройствами в сети. -
Диагностируем VLAN и мосты. Если вы используете VLAN, проверьте, что тег правильно настроен:
ip -d link show eth0. Для проверки мостов используйтеbridge vlan showиbridge fdb show(таблица MAC-адресов). -
Исправляем ошибку «Device or resource busy». Эта ошибка при запуске контейнера или виртуальной машины почти всегда означает проблему с MAC-адресом внутри программного моста (bridge). Простое решение перезапустить сетевые службы Docker:
sudo systemctl restart docker. Также может помочь удаление и повторное создание проблемного сетевого интерфейса или моста черезip link delete.
Уровень 3: Сетевой (Network Layer)
Переходим к IP-адресации и маршрутизации. Если кабели в порядке, но пакеты не идут, проблема здесь.
-
Проверяем IP-адрес.
ip addr show eth0покажет, назначен ли интерфейсу корректный IP-адрес. Если адреса нет, а DHCP-сервер должен его выдать, переходим к его диагностике. Если адрес есть, убедитесь, что он не конфликтует с другими устройствами. -
Смотрим таблицу маршрутизации. Команда
ip route showвыводит список всех известных маршрутов. Убедитесь, что существует маршрут по умолчанию (default gateway). Его отсутствие одна из главных причин отсутствия доступа в интернет. -
Диагностируем связность. Начните с
pingдо вашего шлюза по умолчанию. Если пинг не идёт, проверьте ARP-таблицу командойip neigh show. Запись о шлюзе должна иметь статусREACHABLEилиSTALE. Если статусFAILEDили записи нет, значит, проблема на канальном уровне (L2) или с конфигурацией шлюза. -
Проверяем ARP. Утилита
arp -nпокажет, соответствует ли MAC-адрес шлюза его IP. Несовпадение признак ARP-spoofing или проблемы с коммутатором.
Уровень 4: Транспортный (Transport Layer)
Здесь мы проверяем, слушает ли сервер нужные порты и не блокирует ли трафик файрвол.
-
Смотрим, какие порты слушает сервер. Используйте современную утилиту
ss -tulpn. Она покажет все слушающие (LISTEN) порты с указанием процесса. Убедитесь, что порт вашего приложения (например, 80 для веб-сервера) открыт и слушает на всех интерфейсах (0.0.0.0) или на нужном IP. -
Проверяем доступность порта удалённо. С любой машины в сети выполните
telnet <IP-адрес> <порт>. Если соединение устанавливается, значит, порт доступен. Если нет — проблема может быть в фаерволе или в самом приложении. -
Временно отключаем файрвол для теста. На сервере выполните
sudo ufw status(илиsudo iptables -L). Для проверки гипотезы можно временно отключить файрвол:sudo ufw disable.
Уровни 5–7: Сеансовый, Представления и Прикладной (Session, Presentation, Application)
Верхние уровни проверяются в последнюю очередь. Здесь мы убеждаемся, что конкретные сервисы (DNS, HTTP, API) работают корректно.
-
Проверяем разрешение DNS. Команды
dig google.comиnslookup google.comпокажут, может ли сервер преобразовать доменное имя в IP-адрес. Если они не работают, проблема в настройках DNS-резолвера (файл/etc/resolv.conf). -
Тестируем работу приложений. Используйте
curl -v http://localhost:80для проверки локального веб-сервера. Опция-v(verbose) выведет детальный лог подключения, включая TLS-рукопожатие. -
Проверяем время (если всё работает, но медленно). Если сайты открываются, но очень долго, часто проблема в синхронизации времени. Команда
timedatectlпокажет статус NTP. Сертификаты безопасности могут отвергаться из-за расхождения времени между сервером и клиентом.
Продвинутая диагностика: анализ трафика
Если описанные шаги не помогли, пора переходить к тяжёлой артиллерии — анализу трафика. tcpdump и Wireshark позволяют увидеть, что на самом деле происходит в сети.
Примеры использования tcpdump:
-
Перехватить весь трафик с интерфейса:
sudo tcpdump -i eth0. -
Поймать только HTTP-трафик (порт 80):
sudo tcpdump -i eth0 port 80. -
Поймать трафик к конкретному IP:
sudo tcpdump -i eth0 host 192.168.1.100. -
Сохранить трафик в файл для анализа в Wireshark:
sudo tcpdump -i eth0 -w capture.pcap.
Анализируя захваченный трафик, вы увидите, идут ли пакеты вообще, нет ли постоянных переспросов (ARP, TCP retransmissions) и на каком именно этапе обрывается соединение.
Устранение распространённых проблем
| Проблема | Вероятная причина | Решение |
|---|---|---|
Network is unreachable при ping | Отсутствует маршрут по умолчанию или интерфейс не поднят. | Проверьте ip route show и добавьте маршрут: ip route add default via 192.168.1.1 |
ping работает, но curl не открывает сайт | Проблема с DNS или порт заблокирован | Проверьте DNS через dig. Проверьте порт через telnet <IP> 80 |
| Есть IP, но нет связи со шлюзом | ARP-таблица не заполнена | Проверьте ip neigh show. Попробуйте добавить запись вручную: arp -s 192.168.1.1 xx:xx:xx:xx:xx:xx |
| Медленная работа или периодические обрывы | Не совпадают настройки дуплекса/скорости | Проверьте ethtool eth0. Настройте скорость вручную: ethtool -s eth0 speed 1000 duplex full autoneg off |
| Всё работает, но очень медленно | Проблема с синхронизацией времени | Проверьте timedatectl. Настройте NTP-клиент: sudo timedatectl set-ntp true |
Ошибка Device or resource busy | Проблема с сетевым мостом и MAC-адресом | Перезапустите Docker: sudo systemctl restart docker. При необходимости удалите bridge: sudo ip link delete docker0 |
Пропавшая сеть это не повод для паники, а повод применить системный подход. Диагностика сети алгоритм, построенный на модели OSI, позволяет методично, шаг за шагом, исключать целые пласты потенциальных проблем: от банально отвалившегося кабеля до сбоя в сложной конфигурации VLAN. В этой статье мы создали алгоритм, который проведёт вас через все этапы от проверки лампочки на сетевой карте до анализа трафика и проверки DNS. Вооружившись этим чек-листом и знанием ключевых команд (ip, ethtool, ping, ss, tcpdump), вы сможете находить и устранять неисправности в разы быстрее и эффективнее.
