Проблемы TRACERT, постоянный тайм-аут на определенных шагах

Я работаю с одним и тем же интернет-провайдером (ZoomInternet) уже несколько лет. Это был относительно хороший опыт, и обслуживание, как правило, в порядке, просто отлично.

Однако в последние 2 или 3 дня у меня были некоторые заметные проблемы с задержкой в ​​некоторых играх, в которые я играю. Например, WGT - игра в гольф, время загрузки новых изображений после каждого выстрела значительно увеличилось. Я постоянно отстаю в Агарио, иногда теряю связь полностью. Ничего этого не происходило 3 дня назад.

Итак, я делаю обязательный сброс компьютера / модема / роутера. Освободите / обновите мой IP на целых 9 ярдов. Я всегда предполагаю, что это я. Тем не менее, я не установил никакого нового программного обеспечения в течение недели, и я не могу найти ничего, что указывало бы на меня как на проблему. Так как это происходит на каждом сайте, который я отслеживаю, я склоняюсь в направлении «это не я в этот раз».

Когда я запускаю трассировку на игровой сервер WGT (или на Agar.io, или даже на yahoo.com), я получаю тайм-ауты в том же месте. Шаги 3 и 4.

Вот скриншот нескольких следов, которые я сделал: Скриншот TraceRt

В течение последних нескольких дней на этапах 3 и 4 это время истекало. 209 IP на этапе 5 является центром обработки данных в Индианаполисе. Где-то между Zoom и этим Indy IP что-то идет не так.

Поэтому парень поддержки попросил меня отследить armstrongonewire.com (в частности, по их позвоночнику). У меня было около 10 таймаутов за 12 шагов, прежде чем он сказал мне убить его. Я ударил шаг 2 точно так же, как и все остальные следы, а затем все пошло не так.

Затем парень продолжает говорить мне, что «некоторые» серверы в магистрали не настроены на возврат ответа на трассировку. Я никогда не слышал об этом раньше, так что это сбило меня с толку. Если сервер не отвечает, как мой компьютер узнает, что данные туда попадают? Без ответа он не продолжит отправку до истечения времени ожидания?

Я годами запускал трассировки, включая трассы до WGT, и все шаги обычно решались без проблем. Теперь я не могу получить полную поездку на любой сервер, полностью решенный на каждом шагу. Я звоню BS на это "не настроен, чтобы ответить" объяснение. Не кажется законным. Что вы ребята думаете?

Я загружаю WinMTR, чтобы получить второе мнение, но я уверен, что что-то не так с провайдером (или его провайдером), и они не обсуждают или не обращают внимания на проблему.

Вот мои результаты MTR: http://vvcap.com/Ak0yyHjoT09

Кто-нибудь когда-нибудь слышал о «магистральных» серверах (или любой крупномасштабной сети), специально настроенных на НЕ отправку ответа на трассировку или пинг?

Благодарю.

Отказ от ответственности: я не эксперт в этом, поэтому ... пожалуйста, укажите на любую чушь, которую я написал.

Но, да, это вполне возможно, потому что пакеты, которые эти диагностические инструменты отправляют и ожидают , не совсем такие же, как ваши обычные пакеты данных. Они не пытаются установить такое же соединение TCP-port-80, как ваш веб-браузер.

Команда pingпроста - она ​​отправляет ICMP-пакеты «Эхо» (выделенные для этой цели) и ожидает ICMP-ответа «Эхо-ответ» от цели. Поскольку сам ICMP также используется для сообщения об ошибках подключения, большинство операционных систем уже имеют встроенную поддержку для ответа на эхо-запросы, однако ...

• Есть некоторые другие ICMP-пакеты, которые не так полезны, например, «Redirect» или даже старый «Source Quench» (легко злоупотреблять). Даже тот же Ping / Echo имеет историю использования в качестве Ping of Death против различных глючных сетевых стеков.

  В результате многие системные администраторы до сих пор настраивают общий блок всех входящих ICMP-пакетов, полагая, что это сделает их сеть более безопасной.

  Иногда они блокируют даже исходящие ICMP-пакеты, что, помимо прочего, нарушает Traceroute, а также другие вещи, такие как обнаружение MTU. (Я имею в виду, это, очевидно, их сеть и их бизнес, но ... аааа.)

• Хотя Windows не используется для маршрутизаторов (в значительной степени), она все еще, вероятно, является наиболее распространенным примером этого - с момента выпуска Windows XP SP3 встроенный брандмауэр по умолчанию отбрасывает все входящие эхо-запросы.

(Практически любой брандмауэр позволяет выборочно фильтровать пакеты TCP и UDP, основываясь на таких вещах, как адрес источника и / или порт назначения. Поэтому неудивительно, что брандмауэры могут передавать TCP, но блокируют ICMP, например.)

Что касается Traceroute, у него нет выделенного сообщения или протокола, фактически он полагается на сообщения об ошибках . Точная реализация варьируется - в Windows tracertкоманда отправляет эхо-пакеты ICMP, в то время как большинство вариантов tracerouteинструмента Linux вместо этого отправляют мусор через UDP (хотя может и ICMP). Но общая часть заключается в том, что они отправляют пакеты с небольшими, увеличивающими «время жизни» или «счетчик переходов», ожидая, что каждый маршрутизатор на пути ответит с ошибкой ICMP «Время жизни превысило». Большинство операционных систем делают это по умолчанию.

Но, опять же, некоторые системы имеют брандмауэры, настроенные для тихого отбрасывания эхо-пакетов ICMP, и в результате они не отправляют никаких сообщений об ошибках обратно. (В этом случае кажется, что фильтрация применяется только к пакетам, которые обрабатывает сам маршрутизатор, но не к пакетам, которые он просто передает.)

В некоторых других системах установлены межсетевые экраны, специально предназначенные для блокировки только исходящих ошибок ICMP. Я честно не знаю почему, но я видел, как это произошло.

И некоторые маршрутизаторы действительно есть генерация ошибки ICMP сама выключается, возможно , чтобы уменьшить нагрузку или избежать пакетов, обрабатываются путем медленным центральным процессором , когда они могли бы быть перенаправлены быстрым специализированным аппаратным обеспечением.

Таким образом, в конце концов, дело не в том, что «некоторые маршрутизаторы не настроены на ответ», а в том, что они « настроены не отвечать » на сообщения traceroute.

(Я не могу действительно ответить, почему иногда mtrработает, но не tracerouteвызывает вызовы . На первый взгляд, он использует тот же подход, что и traceroute, но я не исследовал это подробно.)