Проблема
Пропала сеть. Это одна из самых частых и стрессовых ситуаций в работе администратора. В этот момент легко поддаться панике и начать хаотично перезагружать всё подряд. Серверы, коммутаторы, роутеры. Но такой подход не только неэффективен, но и может усугубить проблему, стерев важные улики из логов.
Ключ к быстрому решению это системный подход. Используя эталонную модель OSI, мы будем подниматься от самого нижнего, физического уровня, к верхнему, прикладному. Нужно начать с проверки кабеля и сетевой карты, и только если там всё в порядке, переходить к IP адресам, маршрутизации и DNS. В этой методичке мы разберём каждый шаг. Какие команды использовать, что искать и как интерпретировать результаты.
Пошаговая инструкция
Мы пройдём пять ключевых уровней, начиная с того, где проблема возникает чаще всего.
Уровень 1. Физический (Physical Layer)
На этом уровне мы проверяем всё, что можно потрогать руками. Кабели, порты на коммутаторах и сетевые карты сервера. Если индикатор активности на сетевой карте не горит, проблема, скорее всего, здесь.
Проверяем статус интерфейса. Команда ip link show покажет список всех интерфейсов. Нас интересует флаг UP. Если интерфейс выключен, его нужно поднять.
text
sudo ip link set eth0 up
Смотрим детальную информацию. ethtool eth0 это наша главная утилита для диагностики физического уровня. В её выводе ищем строку Link detected: yes. Это гарантирует, что кабель подключён и есть физический контакт. Также проверяем Speed и Duplex. Они должны совпадать с настройками на коммутаторе. Несовпадение может указывать на неисправный кабель или неправильные настройки автосогласования. Можно запустить и встроенный тест карты.
text
sudo ethtool -t eth0
Уровень 2. Канальный (Data Link Layer)
На этом уровне мы проверяем настройки VLAN, агрегацию каналов (bonding) и таблицу MAC адресов. Здесь же кроется одна из самых частых причин проблем на виртуальных машинах.
Проверяем MAC адрес. Команда ip link show eth0 покажет аппаратный адрес интерфейса. Важно убедиться, что он не нулевой (всё из нулей) и не конфликтует с другими устройствами в сети.
Диагностируем VLAN и мосты. Если вы используете VLAN, проверьте, что тег правильно настроен.
text
ip -d link show eth0
Для проверки мостов используйте следующие команды.
text
bridge vlan show
bridge fdb show
Исправляем ошибку «Device or resource busy». Эта ошибка при запуске контейнера или виртуальной машины почти всегда означает проблему с MAC адресом внутри программного моста (bridge). Простое решение перезапустить сетевые службы Docker.
text
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). Для проверки гипотезы можно временно отключить файрвол.
text
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.
Перехватить весь трафик с интерфейса.
text
sudo tcpdump -i eth0
Поймать только HTTP трафик (порт 80).
text
sudo tcpdump -i eth0 port 80
Поймать трафик к конкретному IP.
text
sudo tcpdump -i eth0 host 192.168.1.100
Сохранить трафик в файл для анализа в Wireshark.
text
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.1ping работает, но 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), вы сможете находить и устранять неисправности в разы быстрее и эффективнее.