Диагностика сети Windows Server: ping, tracert, pathping, WinMTR, iperf3 и потери пакетов
Когда сайт на вашем Windows-сервере медленно открывается из некоторых мест, удалённый рабочий стол постоянно отключается или игра либо приложение показывает высокую задержку, причина обычно кроется где-то на сетевом пути, а не на самом сервере. В Windows есть хорошие средства диагностики, а несколько бесплатных утилит восполняют пробелы. В статье: как пользоваться ping, tracert, pathping, Test-NetConnection, WinMTR и iperf3, как читать результаты и не делать ложных выводов и что указать при обращении в поддержку.
Шаг 1: Доступность и задержка — ping
# 50 pings to the server; watch the average time and the "Lost" count
ping -n 50 203.0.113.10
# Continuous ping (Ctrl+C to stop) while you reproduce the problem
ping -t 203.0.113.10
# IPv6 or a hostname
ping -6 -n 20 example.comСтабильное время ответа и 0% потерь означают, что в данный момент путь в порядке. Потери в несколько процентов или скачки времени на сотни миллисекунд указывают на перегрузку. Учтите, что некоторые серверы и файрволы блокируют ping, поэтому отсутствие ответа не всегда означает, что сервер недоступен; проверьте также порт, как описано в шаге 3.
Шаг 2: Маршрут — tracert и pathping
# Hop-by-hop route without DNS lookups (faster)
tracert -d 203.0.113.10
# tracert + loss statistics for every hop (100 probes per hop, takes a few minutes)
pathping -n -q 100 203.0.113.10Читайте результаты внимательно: многие маршрутизаторы намеренно отвечают на адресованные им пакеты с низким приоритетом. Потери или высокая задержка на промежуточном узле, которые не сохраняются на следующих узлах и на конечном адресе, проблемой не являются. Только потери, которые начинаются на одном узле и тянутся до самого конца, показывают, где начинается проблема.
Шаг 3: Проверка конкретного порта — Test-NetConnection
Ping подтверждает, что доступен сервер; проверка порта подтверждает, что доступна служба. Это самый быстрый способ отличить сетевую проблему от проблемы с брандмауэром или приложением.
# Is Remote Desktop / a website / SSH reachable?
Test-NetConnection 203.0.113.10 -Port 3389
Test-NetConnection example.com -Port 443 -InformationLevel Detailed
# Built-in traceroute
Test-NetConnection 203.0.113.10 -TraceRoute
# On the server: is the service actually listening?
Get-NetTCPConnection -State Listen | Where-Object LocalPort -in 80,443,3389 | Select-Object LocalAddress, LocalPort, OwningProcessTcpTestSucceeded : True означает, что порт доступен на всём пути. Если ping проходит, а проверка порта — нет, проверьте брандмауэр Windows (см. статью об открытии портов в брандмауэре Windows) и запущена ли служба.
Шаг 4: Непрерывный мониторинг маршрута в WinMTR
MTR объединяет ping и traceroute и непрерывно измеряет каждый узел — это лучший способ поймать периодически возникающие проблемы. В Windows используйте WinMTR (бесплатная программа с открытым исходным кодом): введите IP сервера, нажмите Start, дайте ей поработать не менее 2–3 минут (в идеале — в момент проблемы) и сохраните результат кнопкой Copy text to clipboard. Читайте его так же, как вывод pathping: важны только потери, которые сохраняются до последнего узла. Если под рукой есть Linux-машина, см. статью о mtr, traceroute и iperf3 в Linux.
Шаг 5: Измерение пропускной способности — iperf3
Тесты задержки не показывают пропускную способность. iperf3 измеряет реальную скорость между двумя машинами. Скачайте сборку iperf3 для Windows, распакуйте её и на сервере временно откройте порт в брандмауэре:
# On the server: allow the test port, then start the iperf3 server
New-NetFirewallRule -DisplayName "iperf3 test" -Direction Inbound -Protocol TCP -LocalPort 5201 -Action Allow
.\iperf3.exe -s
# On the client: upload test, then download test (-R), 4 parallel streams, 20 seconds
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20
.\iperf3.exe -c 203.0.113.10 -P 4 -t 20 -R
# Afterwards, remove the temporary rule
Remove-NetFirewallRule -DisplayName "iperf3 test"Один поток на большом расстоянии из-за задержки часто работает медленнее скорости порта; прежде чем делать вывод об ограничении канала, сравните результаты с -P 4 или -P 8.
Шаг 6: Проверка DNS, маршрутов и MTU
# DNS: compare your resolver with a public one, and clear the local cache
Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
ipconfig /flushdns
# IP configuration and routing table on the server
ipconfig /all
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 10
# MTU: the largest packet that passes without fragmentation (1472 + 28 = 1500)
ping -f -l 1472 203.0.113.10
ping -f -l 1400 203.0.113.10Если пакет размером 1472 не проходит с ошибкой «Packet needs to be fragmented but DF set», а пакеты меньшего размера проходят, значит, на пути есть участок с меньшим MTU; из-за этого страницы и загрузки могут зависать, хотя небольшие запросы работают.
Шаг 7: Что отправить в поддержку
Чтобы проблему с маршрутом решили быстро, укажите в тикете:
- IP сервера, ваш внешний IP (его покажет любой сайт вида «мой IP»), а также ваш город и провайдера.
- Результат WinMTR или pathping с вашей стороны до сервера и, если возможно, с сервера до вашего IP.
- Время возникновения проблемы (с часовым поясом) и её характер: постоянно или только в определённые часы.
- При проблемах со скоростью — результаты iperf3 в обоих направлениях.
См. также статью о том, как создать тикет в техническую поддержку IMIDC.
Частые вопросы
tracert показывает «Превышен интервал ожидания для запроса» на некоторых узлах
Эти маршрутизаторы просто не отвечают на пакеты трассировки. Если следующие узлы и конечный адрес отвечают нормально, с маршрутом всё в порядке.
Ночью скорость нормальная, а вечером падает
Это типичная перегрузка международных каналов или сети вашего провайдера в часы пик. Проведите тесты в оба периода и приложите результаты к тикету; решением может стать маршрут, который лучше работает в часы пик (например, премиальный маршрут до Китая).
Ping проходит, но удалённый рабочий стол не подключается
Сетевой путь в порядке: порт заблокирован или служба не отвечает. Воспользуйтесь статьёй о решении проблем с удалённым рабочим столом.
Если проблема не решена, создайте тикет — техническая поддержка IMIDC работает 24/7. Укажите IP сервера, ваш внешний IP и местоположение, а также результаты WinMTR, pathping или iperf3, чтобы мы быстрее нашли причину.