Не гадать, а проверять: от кабеля до приложения
Жалоба «не работает сайт» описывает симптом, а не причину. Причину ищут, проверяя уровни по порядку: каждый следующий опирается на предыдущий, и первая непройденная проверка указывает место поломки.
| Шаг | Проверка | Команда | Если не прошла |
|---|---|---|---|
| 1. Интерфейс | Есть линк | ip -br link | Кабель, порт коммутатора, драйвер, Wi-Fi |
| 2. Адрес | Есть правильный адрес и маска | ip -br addr | DHCP (169.254 — нет ответа), статическая настройка |
| 3. Шлюз | Шлюз задан и отвечает | ip route, ping шлюза, ip neigh | Неверный шлюз, VLAN, маршрутизатор |
| 4. Внешний адрес | Отвечает адрес в интернете | ping 77.88.8.8, mtr | NAT, провайдер, межсетевой экран |
| 5. Имена | Имя разрешается | dig имя, getent hosts имя | DNS-сервер, /etc/resolv.conf, /etc/hosts |
| 6. Порт | Порт службы открыт | nc -zv хост порт | Служба не запущена, экран на сервере |
| 7. Приложение | Служба отвечает правильно | curl -v | Сертификат, код 5xx, настройки приложения |
Важно проверять с того же узла, где проблема, и сравнивать с узлом, где всё работает. Разница между ними — лучшая подсказка.
traceroute отправляет пакеты с TTL = 1, 2, 3… Каждый маршрутизатор, на котором TTL обнулился, возвращает сообщение ICMP «время истекло» и тем самым называет себя. Так по шагам строится путь до цели.
$ traceroute -n -q1 -w1 77.88.8.8
traceroute to 77.88.8.8 (77.88.8.8), 12 hops max, 60 byte packets
1 192.168.116.1 0.138 ms
2 198.18.23.193 0.419 ms
3 92.204.249.104 0.279 ms
4 92.204.249.72 0.497 ms
5 *
6 62.115.195.218 3.504 ms
7 *
...
Первый шаг — свой шлюз, дальше — сеть провайдера. * значит, что маршрутизатор не ответил за отведённое время. Это не обязательно потеря: многие маршрутизаторы не отвечают на такие запросы или отвечают с низким приоритетом. Тревожно, когда после звёздочек цель так и не достигнута, а у соседей по сети с другим маршрутом всё работает.
mtr (пакет mtr-tiny) объединяет traceroute и ping: многократно опрашивает каждый узел пути и считает потери и задержки.
$ mtr -n -r -c 3 -m 8 77.88.8.8
HOST: debian Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.116.1 0.0% 3 0.2 0.4 0.2 0.6 0.2
2.|-- 198.18.23.193 0.0% 3 0.6 0.6 0.5 0.6 0.1
3.|-- 92.204.249.104 0.0% 3 0.5 1.7 0.5 4.1 2.0
4.|-- 92.204.249.72 0.0% 3 0.5 0.6 0.5 0.7 0.1
5.|-- 62.115.201.202 33.3% 3 350.5 362.3 350.5 374.2 16.7
6.|-- 62.115.195.218 0.0% 3 3.7 3.7 3.6 3.7 0.0
7.|-- 10.32.44.1 0.0% 3 43.6 43.7 43.6 43.7 0.1
8.|-- 10.1.4.1 0.0% 3 43.5 43.5 43.4 43.5 0.1
Учимся читать. На шаге 5 — 33% потерь и 350 мс, но на шагах 6–8 потерь нет и задержка снова 3–43 мс. Значит, проблемы на пути нет: маршрутизатор 5 просто неохотно отвечает на диагностические запросы, а транзитный трафик пропускает нормально. Настоящая потеря видна, когда она начинается на каком-то узле и сохраняется на всех следующих. Скачок задержки с 3,7 до 43 мс на шаге 7 — переход в другой город: это физика расстояния, а не неисправность.
mtr -rwc 100 адрес — 100 замеров с полными именами узлов, в обе стороны, если возможно. Это стандартный формат, с которым работают службы поддержки.Классическая история: по VPN открывается приглашение SSH и маленькие страницы, но большие страницы, загрузка файлов и git clone «зависают». Ping проходит. Причина — на пути участок с MTU меньше 1500 (туннель добавил свои заголовки), а сообщения ICMP «нужна фрагментация» где-то отфильтрованы. Маленькие пакеты проходят, большие исчезают без следа.
$ ping -c 1 -M do -s 1472 10.50.0.10 # 1500 байт — не проходит
1 packets transmitted, 0 received, 100% packet loss
$ ping -c 1 -M do -s 1372 10.50.0.10 # 1400 — проходит
1 packets transmitted, 1 received, 0% packet loss
Найдя наибольший проходящий размер, уменьшают MTU интерфейса туннеля (ip link set wg0 mtu 1400) или включают на маршрутизаторе подстройку TCP MSS. В выводе tracepath адрес MTU пути показывается автоматически.
Когда команды не дают ответа, смотрят сами пакеты. На сервере без графики трафик записывают tcpdump в файл, переносят на свой компьютер (scp) и открывают в Wireshark:
$ sudo tcpdump -i ens18 -nn -w /tmp/web.pcap 'host 188.120.235.218 and tcp port 443'
# воспроизвести проблему, затем Ctrl+C
$ scp lab:/tmp/web.pcap .
| Фильтр отображения Wireshark | Что покажет |
|---|---|
tcp.flags.syn == 1 && tcp.flags.ack == 0 | Попытки соединений |
tcp.flags.reset == 1 | Сбросы — отказы и обрывы |
tcp.analysis.retransmission | Повторные отправки — признак потерь |
dns, dns.flags.rcode != 0 | DNS-запросы, ответы с ошибкой |
http.response.code >= 400 | Ошибки HTTP (для незашифрованного трафика) |
tls.handshake.type == 1 | Начало TLS: имя сайта в поле SNI видно даже в HTTPS |
В Wireshark каждый пакет раскрывается по уровням — Ethernet, IP, TCP, приложение, — ровно как в модели из модуля 01. Меню «Статистика → Диаграмма потоков» рисует обмен двух узлов во времени: рукопожатие, данные, повторы и сбросы видны сразу.
| Симптом | Что проверить | Частая причина |
|---|---|---|
| Адрес 169.254.x.x | Журнал DHCP-клиента, линк | DHCP-сервер недоступен, другой VLAN |
| Соседи по сети пингуются, интернет — нет | ip route, ping шлюза, mtr | Нет маршрута по умолчанию, неверный шлюз, NAT |
| По IP работает, по имени — нет | dig, /etc/resolv.conf | DNS-сервер недоступен или отвечает SERVFAIL |
| У одних пользователей открывается, у других нет | Их адреса, резолверы, маршруты | Разные DNS (старый кэш после смены записи), разные VLAN |
Connection refused | ss -tlnp на сервере | Служба не запущена или слушает 127.0.0.1 |
| Тайм-аут соединения | Экран на сервере и по пути, tcpdump на сервере | Порт закрыт межсетевым экраном, асимметричный маршрут |
| Маленькое работает, большое зависает | ping -M do -s, tracepath | MTU на туннеле |
| Ошибка сертификата | curl -v, дата на клиенте, цепочка | Просрочен, другое имя, неизвестный корень |
| Сеть работает, но медленно | mtr, ethtool, ss -ti | Потери, порт на 100 Мбит/с, перегруженный канал |
Диагностика заканчивается не исправлением, а записью: что было, что проверено, что найдено, что сделано, как убедились. Такой отчёт экономит время при повторении проблемы и нужен для обращения к провайдеру или разработчикам.
Симптом: с 10:40 у бухгалтерии (VLAN 10) не открывается nalog.gov.ru, у остальных — открывается.
Проверено: адреса и шлюз — в норме; ping 77.88.8.8 — проходит; dig www.nalog.gov.ru
— SERVFAIL от 192.168.10.1, NOERROR от 77.88.8.8.
Причина: DNS-кэш на маршрутизаторе VLAN 10 перестал отвечать после обновления.
Сделано: перезапущена служба DNS на маршрутизаторе в 11:05.
Проверка: dig от 192.168.10.1 — NOERROR, сайт открывается у трёх пользователей.
Дальше: добавить второй DNS-сервер в настройки DHCP для VLAN 10.
traceroute показывает путь; * — ещё не потеряmtr настоящая потеря начинается на узле и сохраняется до конца путиping -M do -stcpdump -w на сервере, разбор в Wireshark