Урок 7. Диагностика сети: ping, tracert, nslookup и ipconfig

«Интернет не работает» — это не диагноз. Обрыв может быть в Wi‑Fi, в роутере, у провайдера, в DNS или в самом сайте, и лечится каждый случай по-своему. В этом уроке — порядок проверки и команды, которые есть в любой системе.

Порядок проверки

Идите от ближнего к дальнему — так сразу видно, на каком участке обрыв:

1. Есть ли подключение: значок сети, кабель, индикаторы на роутере.
2. Есть ли у компьютера адрес: ipconfig или ip -br -4 addr.
3. Отвечает ли роутер: ping адреса шлюза.
4. Есть ли интернет по адресу: ping 1.1.1.1 (адрес публичного DNS-сервера, отвечает на ping).
5. Работает ли DNS: nslookup glif.by.
6. Открывается ли нужный сайт или порт.

Адрес и шлюз

В Windows:

ipconfig

У активного подключения найдите «IPv4-адрес» и «Основной шлюз». Полные сведения, вместе с DNS-серверами, — ipconfig /all.

В Linux:

ip -br -4 addr
ip route show default

Первая команда показывает адреса интерфейсов, вторая — шлюз (адрес после via).

Что видно на этом шаге:

• адреса нет совсем или он вида 169.254.x.x — компьютер не получил адрес от роутера: проверьте Wi‑Fi или кабель, перезагрузите роутер; в Windows можно запросить адрес заново — ipconfig /release, затем ipconfig /renew;
• нет шлюза — интернета не будет, даже если адрес есть.

ping: есть ли связь

ping отправляет короткие запросы и ждёт ответа. Windows по умолчанию отправляет четыре запроса и останавливается. Linux и macOS шлют без остановки, пока не нажмёте Ctrl+C, поэтому там указывают число запросов ключом -c:

$ ping -c 4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.521 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.487 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.502 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.493 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3062ms
rtt min/avg/max/mdev = 0.487/0.501/0.521/0.013 ms

• time= — время ответа в миллисекундах. До роутера по кабелю — меньше миллисекунды, по Wi‑Fi — обычно единицы миллисекунд, до сайтов — десятки.
• packet loss — доля потерянных запросов. Потери до своего роутера — почти всегда беда с Wi‑Fi: далеко, стены, помехи.

В русской Windows ответы выглядят так: «Ответ от 192.168.1.1: число байт=32 время=2мс TTL=64», а в конце — итог «Пакетов: отправлено = 4, получено = 4, потеряно = 0». Сообщения об ошибках:

• «Превышен интервал ожидания для запроса» — ответ не пришёл вовремя;
• «Заданный узел недоступен» — маршрута к адресу нет, часто это сообщает сам компьютер или роутер;
• «При проверке связи не удалось обнаружить узел» — имя не превратилось в адрес: проблема в DNS или в имени.

Чтобы следить за связью долго (например, ловить обрывы Wi‑Fi), в Windows есть ключ -t — ping -t 192.168.1.1, останавливается он тоже Ctrl+C.

tracert и traceroute: где обрывается путь

Команда показывает, через какие маршрутизаторы идут пакеты до цели. В Windows:

tracert glif.by
tracert -d glif.by

Ключ -d не превращает адреса узлов в имена — так быстрее. В Linux команда называется traceroute (в Ubuntu — пакет traceroute); если её нет, похожий путь покажет tracepath. Пример вывода — адреса в нём условные:

$ traceroute -n 203.0.113.50
traceroute to 203.0.113.50 (203.0.113.50), 30 hops max, 60 byte packets
 1  192.168.1.1  0.512 ms  0.488 ms  0.470 ms
 2  10.20.0.1  2.913 ms  2.887 ms  2.861 ms
 3  * * *
 4  198.51.100.9  4.204 ms  4.188 ms  4.170 ms
 5  203.0.113.50  4.950 ms  4.921 ms  4.899 ms

Каждая строка — один узел на пути и три замера времени. Первый узел — ваш роутер, следующие — сеть провайдера и дальше. Звёздочки * * * значат, что узел не ответил на служебный запрос. Если дальше узлы отвечают, как в строке 4, всё в порядке: этот маршрутизатор просто не тратит время на такие ответы. Если звёздочки идут от какого-то узла и до конца — связь теряется где-то после последнего ответившего.

Windows и Linux проверяют путь разными пакетами, поэтому их результаты для одной цели могут немного различаться.

Подробнее о потерях на каждом узле расскажут pathping в Windows и mtr в Linux (пакет mtr): они долго шлют запросы каждому узлу и считают долю потерь. pathping работает несколько минут — дождитесь итога.

nslookup: работает ли DNS

nslookup glif.by
nslookup glif.by 1.1.1.1

Первая команда спрашивает свой DNS-сервер, вторая — публичный 1.1.1.1. Если отвечает только вторая, сломан ваш DNS-сервер. Что это значит и как исправить — в уроке DNS и справке DNS-сервер не отвечает.

Проверка порта

Когда сайт или сервер отвечает на ping, но нужная программа не подключается, проверьте сам порт:

Test-NetConnection glif.by -Port 443

Это PowerShell в Windows; в Linux то же делает nc -zv glif.by 443. Как понимать ответ — в уроке Порты и протоколы.

Что значит результат

Самое частое лекарство — перезагрузить роутер: выключить из розетки на 10–20 секунд и включить. Если связи нет и после этого, а шлюз отвечает — звоните провайдеру и называйте, что уже проверили.

Коротко

• Проверяйте по шагам: адрес → шлюз → адрес в интернете → DNS → сайт.
• ipconfig и ip -br -4 addr — свой адрес, «Основной шлюз» и ip route — роутер.
• ping — есть ли связь и сколько она занимает; в Linux — с ключом -c 4.
• tracert и traceroute — путь пакетов; звёздочки посередине пути — не всегда беда.
• nslookup имя и nslookup имя 1.1.1.1 — свой DNS-сервер или чужой; порт — Test-NetConnection и nc -zv.

Проверьте себя