Вопрос или проблема
Я пользуюсь одним и тем же интернет-провайдером (ZoomInternet) уже несколько лет. В целом это был достаточно хороший опыт, и сервис обычно работает нормально.
Однако за последние 2 или 3 дня у меня возникли заметные проблемы с задержкой в некоторых играх, в которые я играю. Например, WGT – это гольф-игра, время загрузки новых изображений после каждого удара значительно увеличилось. Я постоянно испытываю задержки в Agario, иногда совсем теряю соединение. Ничего из этого не происходило 3 дня назад.
Итак, я делаю обязательный сброс компьютера/модема/роутера. Освобождаю/обновляю свой IP и все такое. Я всегда предполагаю, что дело во мне. Однако я не устанавливал новое программное обеспечение неделю, и не могу найти ничего, что указывало бы на меня как на проблему. Поскольку это происходит на каждом сайте, который я отслеживаю, я склонен думать, что “это не я в этот раз”.
Когда я запускаю tracert к игровому серверу WGT (или Agar.io или даже yahoo.com), я получаю тайм-ауты в одном и том же месте. Шаги 3 и 4.
Вот скриншот нескольких трасс, которые я сделал: Скриншот TraceRt
Это последовательно выдает тайм-аут за последние пару дней на шагах 3 и 4. IP 209 на шаге 5 – это дата-центр в Индианаполисе. Что-то идет не так где-то между Zoom и этим IP в Индианаполисе.
Так что сотрудник поддержки попросил меня отследить armstrongonewire.com (в частности, в их магистрали). У меня было около 10 тайм-аутов за 12 шагов, прежде чем он сказал мне прекратить. Я дошел до шага 2, как и в других трассах, а потом все пошло не так.
Парень потом говорит мне, что «некоторые» серверы в магистрали не настроены на то, чтобы возвращать ответ на трассировку. Я никогда не слышал об этом раньше, так что это меня озадачивает. Если сервер не отвечает, как мой компьютер знает, что данные доходят до него? Без ответа разве он просто не продолжит отправлять до истечения времени повторной попытки?
Я выполняю трассировки много лет, включая трассировки к WGT ранее, и все шаги обычно разрешаются без проблем. Теперь я не могу получить полное разрешение всей поездки к любому серверу на каждом шаге. Я считаю, что объяснение «не настроены на ответ» – это ерунда. Это кажется нелегитимным. Как вы думаете?
Я загружаю WinMTR, чтобы получить второе мнение, но я уверен, что что-то не так с ISP (или с их провайдером), и они не говорят о проблеме честно или не осознают ее.
Вот мои результаты MTR: http://vvcap.com/Ak0yyHjoT09
Кто-нибудь когда-нибудь слышал о «магистральных» серверах (или какой-либо крупной сети), которые специально настроены на то, чтобы НЕ отправлять ответ на трассировку или пинг?
Спасибо.
Отказ от ответственности: я не эксперт в этом, так что… пожалуйста, укажите на любую ерунду, которую я написал.
Но, да, это вполне возможно, потому что пакеты, которые отправляют и ожидают эти диагностические инструменты, не совсем такие же, как ваши обычные пакеты данных. Они не пытаются установить такое же соединение TCP-порт-80, как это делает ваш веб-браузер.
Команда ping проста – она отправляет ICMP “Echo” пакеты (предназначенные для этой цели) и ожидает ICMP “Echo Reply” ответы от целевого адреса. Поскольку ICMP сам по себе также используется для отчетности об ошибках соединения, большинство операционных систем уже имеют встроенную поддержку для ответа на Echo-запросы, однако…
-
Существуют некоторые другие ICMP пакеты, которые не совсем полезны, например “Redirect” или даже старый “Source Quench” (легко злоупотреблять). Даже тот же Ping/Echo имеет историю использования в качестве Ping of Death против различных ошибочных сетевых стеков.
В результате многие системные администраторы до сих пор настраивают общее блокирование всех входящих ICMP пакетов, полагая, что это сделает их сеть более безопасной.
Иногда они блокируют даже исходящие ICMP пакеты, что, среди прочего, ломает Traceroute, а также другие вещи, такие как обнаружение MTU. (Я имею в виду, это очевидно их сеть и их дело, но… арgh.)
-
Хотя Windows не используется для маршрутизаторов (в значительной степени), это, вероятно, самый распространенный пример – начиная с Windows XP SP3, встроенный файрвол по умолчанию сбрасывает все входящие Echo-запросы.
(Почти любой файрвол позволяет вам избирательно фильтровать TCP & UDP пакеты, основываясь на таких вещах, как адрес источника и/или целевой порт. Так что неудивительно, что файрволы могут пропускать TCP, но блокировать ICMP, например.)
Что касается Traceroute, у него нет специального сообщения или протокола, на самом деле он зависит от ответов об ошибках. Точная реализация варьируется – в Windows команда tracert отправляет ICMP Echo пакеты, в то время как большинство вариантов инструмента Linux traceroute отправляют мусор по UDP (хотя также могут использовать ICMP). Но общий момент заключается в том, что они отправляют пакеты с небольшими, увеличивающимися пределами “времени жизни” или “количества переходов”, ожидая, что каждый маршрутизатор на пути ответит обратно с ICMP “Time-to-live Exceeded” ошибкой. Большинство операционных систем делают это по умолчанию.
Но, снова же, некоторые системы имеют настроенные файрволы, которые молча сбрасывают ICMP Echo пакеты, и в результате они не отправляют никаких ошибок обратно. (В данном случае, кажется, фильтрация применяется только к пакетам, которые сам маршрутизатор будет обрабатывать, но не к пакетам, которые он просто пересылает дальше.)
Некоторые другие системы имеют файрволы, настроенные на блокировку именно исходящих ICMP ошибок. Честно говоря, не знаю, почему, но я видел, как это происходило.
И некоторые маршрутизаторы действительно отключают генерацию ICMP ошибок, возможно, чтобы уменьшить нагрузку или избежать обработки пакетов медленным основным процессором, в то время как они в противном случае были бы пересланы быстрым специализированным оборудованием.
Так что в конце концов, дело не в том, что “некоторые маршрутизаторы не настроены на ответ”, а скорее в том, что они “настроены не отвечать” на сообщения трассировки.
(Я не могу действительно ответить, почему иногда mtr работает, а ни одна из команд traceroute не работает. На первый взгляд, он использует тот же подход, что и traceroute, но я не исследовал это глубже.)
Ответ или решение
Проблемы с TRACERT: постоянные таймауты на конкретных этапах
Проблема с таймаутами на определенных этапах в использовании команды tracert (или traceroute) может быть вызвана множеством факторов, начинающими от конфигурации локальной сети до неподходящих настроек на уровне провайдера. Ваша ситуация, когда на последних этапах трассировки (этапы 3 и 4) наблюдаются таймауты – вполне распространенная проблема, и разберем основные причины ее возникновения, а также возможные пути ее решения.
1. Архитектура сети и правила фильтрации
Как вы уже упомянули, не все маршрутизаторы и устройства в сети настроены на ответ на ICMP-пакеты, которые используются для команд ping и tracert. На самом деле многие администраторы сетей настраивают свои маршрутизаторы так, чтобы блокировать ICMP (Internet Control Message Protocol) пакеты. Это делается для улучшения безопасности сети, так как ответы на такие пакеты могут быть использованы для получения информации о сети, что дает злоумышленникам дополнительные данные для возможной атаки.
На уровне провайдера, такие настройки могут быть установлены на узловых маршрутизаторах, которые отвечают за определение пути трафика. В результате этого ваш компьютер может не получать нужные ответы от некоторых промежуточных маршрутизаторов, что и вызывает задержки на дальнейших этапах трассировки. Таким образом, таймауты на первом, втором или третьем этапе не обязательно являются признаком проблемы; это может быть просто следствием настройки сетевой архитектуры.
2. Провайдер и качество обслуживания
Вы упомянули, что у вас наблюдаются проблемы с задержками в играх и онлайн-сервисах, несмотря на то, что до этого времени не было никаких значительных проблем. Важно отметить, что даже если ваш интернет-провайдер ZoomInternet стабилен, возможны проблемы в их сети или в сети их партнеров. Это может проявляться как ухудшение качества обслуживания, особенно если вы заметили ухудшение производительности за последние несколько дней.
Рекомендуется связаться с вашей службой поддержки и уточнить, нет ли известных проблем с сетью или планового обслуживания в вашем районе.
3. Использование альтернативных инструментов
Вы упомянули, что собираетесь использовать WinMTR для более детальной диагностики. Это действительно хорошее решение, так как MTR (My Traceroute) объединяет функции ping и traceroute, позволяя увидеть более полную картину. Вы сможете понять, на каком этапе теряется больше всего пакетов, что может дать больше информации о месте возникновения проблемы. Обратите внимание на фрагменты сети, в которых наблюдаются высокие показатели потерь пакетов, а также задержки.
4. Настройки локальной сети
Не забывайте также проверять настройки вашего собственного оборудования: маршрутизатор, модем, а также локальную конфигурацию вашего компьютера. Убедитесь, что настройки firewall не блокируют ICMP-пакеты, и проверьте, нет ли установленных программ, которые могут влиять на сетевые подключения. Попробуйте временно отключить антивирус или firewall, чтобы проверить, сохраняется ли проблема.
5. Ожидание обратной связи
В конечном счете, важно понимать, что отсутствие ответа от конкретных участников сети не всегда указывает на проблему. Некоторые сетевые устройства просто могут быть настроены на фильтрацию ICMP-трафика, а это значит, что они лишь «не отвечают» на такие запросы, но в то же время они могут нормально обрабатывать исходящие пакеты данных. Если проблемы с соединением сохраняются, несмотря на ваш анализ и диагностику, возможно, потребуется обратиться к более глубокой технической поддержке вашего провайдера.
Заключение
Проблемы с трассировкой являются многогранными и могут возникать по множеству причин. Важно последовательно исключать возможные источники проблемы — от вашей сети до настроек провайдера и архитектуры интернет-соединений. Использование инструментов, таких как MTR и сочетание с аналитическими запросами к службе поддержки вашего интернет-провайдера, поможет вам выявить корень проблемы и, возможно, устранить его.