1

Я работаю с одним и тем же интернет-провайдером (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

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

Благодарю.

|источник

1 ответ1

0

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

Но, да, это вполне возможно, потому что пакеты, которые эти диагностические инструменты отправляют и ожидают , не совсем то же самое, что и ваши обычные пакеты данных. Они не пытаются установить такое же соединение 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, но я не исследовал его подробно.)

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .