Очень странная проблема с домашним маршрутизатором [закрыто]

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

Можно попробовать traceroute и видеть, как далеко пакеты добираются. Если они останавливаются в Вашем маршрутизаторе, это - вероятно, проблема там. Если они идут дальше, Вы могли бы хотеть выйти на связь со своим ISP.

Читая Ваш вопрос снова, Вы говорите, что можно проверить с помощью ping-запросов серверы успешно, таким образом, Вы не могли бы видеть ничего аварийного на traceroute...

Я решил проблему теперь, и в конце фиксация была чрезвычайно проста. Я зарегистрировал обращение за поддержкой со своим ISP (PlusNet), и они отправили мне ссылку на сообщение форума, объяснив, что этой проблемой является ошибка во встроенном микропрограммном обеспечении моего маршрутизатора. Фиксация должна была просто установить Интернет-соединение маршрутизатора MTU на 1500 (значение по умолчанию является 1400) так, чтобы это соответствовало стороне локальной сети маршрутизатора MTU.

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

Вы не упоминали, проходите ли Вы прокси-сервер. Могло бы быть интересно видеть, проксирует ли Ваш ISP потенциально прозрачно Вас, практика, которую я считаю очень злыми, но я думаю его довольно общее. Возможно, Вы могли попробовать http://tracetcp.sourceforge.net/usage_proxy.html и сделать трассировку tcp к хостам, которые не работают, который мог быть интересным.

Тем временем прохождение через прокси-сервера должно позволить Вам получать доступ к сайтам, таким образом, у Вас, по крайней мере, есть обходное решение.

Вы попытались связаться со своим ISP об этой проблеме?

Мне Ваш traceroute и результаты ping полностью нормальны. Отсутствие ответа в конце нормально, который является последним ТРАНЗИТНЫМ УЧАСТКОМ, который отправляет, максимальное число транзитных участков ICMP достигло ответов. tracepath является утилитой, которая может использоваться для диагностирования mtu проблем, которые могут помочь Вам.

Я определенно соглашаюсь с понятием, что основные признаки этой проблемы кажутся, что она связана с ПУТЕМ проблема MTU. Существуют другие возможности, но это - наиболее вероятное место для запуска.

Учитывая выдающееся положение сайтов Вы упоминаете и по-видимому длительный промежуток времени, когда это происходило для, кажется довольно маловероятным, что это - проблема в сети ISP......, хотя дали результат traceroute, показанный в вопросе, глубине пути и общей задержке, не сияет очень хорошо на Вашем ISP. Вообще говоря, любой достойный ISP должен получить Вас к любому главному/видному веб-ресурсу (в США) в чем-то [хорошо] менее чем 120 мс..., но я отступаю.

Используя traceroute и ping для диагностирования проблемы, поскольку другие упомянули, очень полезно, но это далеко от определенного решения для инструмента, учитывая возможность/вероятность ICMP, блокирующего/просачивающегося различные местоположения. И из-за этого кроме рук квалифицированного аналитика довольно трудно сказать различие между определенным питанием проблем и брандмауэров с ICMP.

Лучший способ исключить проблему MTU состоит в том, чтобы запуститься путем сокращения MTU интерфейса Ethernet в одном из компьютеров, который имеет проблему. См. процедуру, расположенную здесь для систем MAC, так как Вы упомянули, что у Вас есть компьютер MAC.

Если Вы начинаете понижать свой интерфейс MTU, как процесс описывает на шагах, говорят, что 100 байтов за один раз и функциональность проверки, начинающая с с 1400 вниз к 500 байтам....., если проблема внезапно уходит на одном из шагов, то у Вас определенно есть путь проблема MTU наверняка. При раскрытии к 500, поскольку минимум не решает его, затем это не путь проблема MTU, и можно идти дальше к исследованию других возможностей (после переключения MTU создают резервную копию туда, где это запустилось..., который был, вероятно, 1 500 байтов).

Я соглашаюсь, что это звучит как отказ Пути Исследование MTU.

Решение этой проблемы для меня (на Linux) состояло в том, чтобы включить поддержку усовершенствованного маршрутизатора в ядре и целевую поддержку TCPMSS в netfilter/core netfilter раздел конфигурации ядра. И затем сказать iptables захлопывать максимальный размер сегмента:

iptables-t туземный-A PREROUTING-p tcp - tcp-отмечает SYN, RST SYN-j TCPMSS - clamp-mss-to-pmtu

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

Я теперь отправил подобный пакет запроса соединения TCP в www.adobe.com от моей локальной машины (единственная разница, являющаяся исходным IP-адресом), и сравнил ответный пакет, который я получаю с тем в Вашем последнем tcpdump.

Я нашел 3 различия в заголовках IP/TCP:

• поле "Differentiated Services" в IP установлено на 0x80 в Вашем случае и 0x00 в моем случае - я вполне уверен, это вызывается назначением приоритетов трафика PlusNet.
• 4 байта при смещении 0x20 "0000 5012" в Вашем случае и "5012 0000" в моем случае - это смещение данных, флаги и поля размера окна в заголовке TCP. Похоже, что что-то подкачивает эти 2-байтовые слова в Вашем случае. И это определенно что результаты в недопустимом пакете TCP
• запрос ответа соединения имеет опцию TCP MSS (со значением 1460) добавленный в Вашем случае, но в моем случае нет никаких опций TCP

Мое предположение было бы то, что Ваш маршрутизатор пытается быть умным путем добавления опции MSS TCP, но в некоторых случаях портит заголовок TCP. Делает Ваш маршрутизатор, имеют любые настройки "MSS clamping" - если так, я попытался бы отключить те настройки. Иначе я предложил бы спросить поддержку PlusNet (показав им вывод tcpdump).

У меня была подобная проблема с моим запиранием маршрутизатора при доступе к определенному потоковому аудио / ресурсы видео. Обновление настроек сети WMP решило тот конкретный вопрос; не уверенный, если это могло бы быть релевантно в Вашем случае.

Собирание рискнуть и говорит, что это - проблема маски подсети, любой с Вашей локальной LAN (должен быть 255.255.255.0), или с Вашей стороной WAN.

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