Ping, tracert, nslookup: один и тот же порядок, чтобы не лечить вслепую

Короткий ответ

Три инструмента отвечают на три вопроса: nslookup — какое имя в какой IP и с какого сервера; ping — отвечает ли ICMP этот IP (и с каким RTT/loss); tracert/traceroute — по каким hop и где обрыв для ICMP TTL. Порядок: адрес клиента и DNS NIC → nslookup на 10.0.10.2 и без него → ping шлюза 10.0.10.1 → ping целевого IP → traceroute на IP → TCP отдельно (Test-NetConnection). Не начинайте с ping ya.ru.

Сохраняйте вывод в заявку. Повторяемость важнее «у меня заработало».

Симптомы и как отличить

Статья не про одну поломку. Если уже ясно, что APIPA — 169.254. Если имя vs TCP — пинг vs сайт. Здесь — как не смешать слои.

Возможные причины

1. Ping по имени: скрытый DNS.
2. Traceroute режется ICMP, TCP жив.
3. Разные ПК, разный DNS.
4. Нет -d / -n, ждут PTR минутами.
5. Сравнивают ping 4 пакета с «потерей 25%» как приговор.

Диагностика

Фиксируйте время, hostname, интерфейс.

0. Кто вы в сети

hostname
Get-NetIPConfiguration
ipconfig /all
Get-NetRoute -DestinationPrefix '0.0.0.0/0'

hostname
ip -br addr
ip route
resolvectl status

Ожидание: 10.0.10.x/24, gw 10.0.10.1, DNS 10.0.10.2. Иначе сначала L3/DHCP, не сайт.

1. nslookup — только DNS

Всегда указывайте сервер и тип:

nslookup www.contoso.example 10.0.10.2
nslookup www.contoso.example
nslookup 10.0.10.10 10.0.10.2

nslookup www.contoso.example 10.0.10.2
dig www.contoso.example @10.0.10.2 +norecurse
resolvectl query www.contoso.example

Запишите: Server, IP (A/AAAA), код. Расхождение «без сервера» vs @10.0.10.2 — клиентский резолвер/кэш. См. нестабильный DNS.

2. ping — только ICMP до IP

Сначала шлюз и DNS по IP, потом цель по IP из nslookup, и только потом по имени (контроль).

ping -n 4 10.0.10.1
ping -n 4 10.0.10.2
ping -n 20 10.0.10.1
ping -n 4 93.184.216.34

ping -c 4 10.0.10.1
ping -c 20 10.0.10.1
ping -c 4 93.184.216.34

Интерпретация: 100% loss до 10.0.10.1 — LAN. До шлюза 0%, до цели loss — дальше. Destination host unreachable от своего адреса — ARP/маршрут (таблица). Timeout — тишина.

Для MTU: ping -f -l / -M do, не в этом же «первом прогоне».

3. tracert/traceroute — hop ICMP

tracert -d -h 15 10.0.10.1
tracert -d -h 15 93.184.216.34
Test-NetConnection 10.0.10.2 -TraceRoute

traceroute -n 10.0.10.1
traceroute -n 93.184.216.34

-d/-n обязательны в заявке: без PTR. * * * на hop при живых последующих — часто ICMP limit. Смотрите последний осмысленный хоп и loss на цели ping.

4. TCP, который ping не видит

Test-NetConnection 10.0.10.2 -Port 53
Test-NetConnection www.contoso.example -Port 443

nc -vz 10.0.10.2 53
nc -vz 93.184.216.34 443

Заполните матрицу:

5. Когда трёх инструментов мало

Потери — больше пакетов, статья loss. Соседи — arp -a / Get-NetNeighbor. Это уже четвёртый слой, не вместо трёх.

Решение

Методика сама не чинит. По матрице выберите статью:

• нет адреса / APIPA → DHCP;
• нет ICMP до gw → L2/VLAN/кабель;
• DNS врёт → DNS-статьи;
• ICMP цели есть, 443 нет → фильтр/прокси/MTU;
• обрыв на hop N → этот hop/канал.

Не меняйте два места сразу. После фикса — повторите ту же матрицу.

Windows пример сохранения:

$d = 'C:\Temp\net-diag'
New-Item -ItemType Directory -Force $d | Out-Null
Get-NetIPConfiguration | Out-File $d\ip.txt
nslookup www.contoso.example 10.0.10.2 | Out-File $d\ns.txt
ping -n 20 10.0.10.1 | Out-File $d\ping-gw.txt
tracert -d -h 15 10.0.10.2 | Out-File $d\tr.txt

6. Что писать в заявку, чтобы диагностику можно было повторить

Минимум в тексте тикета, не в устном «пинг не идёт»: hostname, время, Get-NetIPConfiguration / ip -br addr + ip route, полный nslookup FQDN 10.0.10.2, ping 20 пакетов до 10.0.10.1 и до IP цели, tracert -d / traceroute -n, Test-NetConnection или nc на 443. Не прикладывайте скрин с обрезанным «Request timed out» без адреса. Не пингуйте имя, пока не зафиксирован A. Если traceroute полный звёздочек, а TCP/443 True — напишите это явно, чтобы никто не «чинил hop». Ubuntu укажите, ICMP или UDP traceroute. Повторите матрицу после фикса теми же командами. arp -a / Get-NetNeighbor добавляйте, когда ICMP unreachable от себя. DNS- suffling: два nslookup через 10 секунд, если подозреваете флап. Эта методика не заменяет tcpdump, но отсекает 80% «перезагрузите свитч». Для WAN якорь 1.1.1.1 используйте только если политика позволяет ICMP/TCP туда; иначе корпоративный IP мониторинга.

Скрипт сохранения вывода (Windows) уже выше; на Ubuntu:

mkdir -p /tmp/net-diag
ip -br addr > /tmp/net-diag/addr.txt
ip route > /tmp/net-diag/route.txt
resolvectl status > /tmp/net-diag/dns.txt
ping -c 20 10.0.10.1 > /tmp/net-diag/ping-gw.txt
nslookup www.contoso.example 10.0.10.2 > /tmp/net-diag/ns.txt
traceroute -n 10.0.10.2 > /tmp/net-diag/tr.txt

Не запускайте это на проде с ip route flush «для чистоты». Только чтение.

Как проверить, что проблема устранена

Повторите матрицу: все ячейки «факт» совпадают с ожиданием плюс пользовательский сценарий (браузер). Сохраните «после» рядом с «до».

Если не помогло

• Нужен tcpdump, ARP, NAT conntrack — вышли за три утилиты, это нормально.
• PowerShell Test-NetConnection медленный — не замена ping для loss.
• Ubuntu traceroute UDP vs ICMP (-I) — разные ACL, укажите в заявке ключ.

Профилактика

• Чек-лист в wiki тикета: матрица выше.
• Запрет «пинганули имя и перезагрузили свитч».
• Мониторинг якорей 10.0.10.1 и 10.0.10.2 отдельно от «сайта компании».

FAQ

ping по имени быстрее же?

Он прячет DNS. Для методики — сначала IP.

Сколько пакетов ping?

Для «живости» 4. Для loss — 50–200. Не делайте вывод по одному timeout.

tracert пугает звёздочками. Чинить hop?

Не если следующие hop отвечают и TCP цели жив. Звёздочка ≠ drop транзита.

nslookup vs Resolve-DnsName vs dig?

Для заявки достаточно nslookup+сервер. dig точнее (TTL, флаги). Windows часто без dig.

Нужен ли pathping?

Опционально для Windows (RTT+loss по hop). Не заменяет ping к якорям. На Ubuntu — mtr.