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

Это похоже на проблему с MTU.

Скорее всего, между вами и этими сайтами есть что-то, что не поддерживает типичный 1500-байтовый MTU, и, кроме того, возможно, брандмауэр блокирует пакеты ICMP, которые используются для "Обнаружения MTU пути", поэтому ваша сторона не может сказать, что нормальный MTU использовать нельзя.

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

РЕДАКТИРОВАТЬ - ваш tcpdump вывод показывает, что ваша сторона все еще пытается инициировать «трехстороннее рукопожатие» TCP, потому что SYN бит отправляется в пакетах с вашего конца. Однако пакеты, возвращаемые от Adobe, кажутся усеченными или искаженными. Это довольно странно, потому что в пакетах не должно быть никакой полезной нагрузки, только ответ SYN на дальнем конце. Мне нужно было бы увидеть полный дамп (включая параметр -X) только этих первых 4 или около того пакетов, чтобы узнать больше.

EDIT2 - на основе ваших подробных tcpdumps я считаю, что ваш маршрутизатор портит ответ TCP с некоторых сайтов. Лучший способ проверить это - взять маршрутизатор другой марки.

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

Я определенно согласен с мнением, что основные симптомы этой проблемы звучат так, как будто они связаны с проблемой PATH MTU. Есть и другие возможности, но это наиболее подходящее место для начала.

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

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

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

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

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

Читая ваш вопрос еще раз, вы говорите, что можете успешно пропинговать серверы, поэтому вы можете не увидеть ничего ненормального в трассировке ...

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

Спасибо всем, кто предложил помощь и совет. Я собираюсь принять ответ Альнитака просто потому, что он / она оставались со мной в этом вопросе и возвращались с новыми советами и вещами, которые можно было бы попробовать.

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

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

Вы пытались связаться с вашим интернет-провайдером по этому поводу?

Для меня результаты трассировки и пинга совершенно нормальны. Отсутствие ответа в конце является нормальным явлением, это последний HOP, который отправляет ответы ICMP о достижении максимального количества прыжков. tracepath - это утилита, которую можно использовать для диагностики проблем с mtu, которая может вам помочь.

Я согласен с тем, что это звучит как сбой в обнаружении MTU пути.

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

iptables -t nat -A PREROUTING -p tcp --tcp-flags 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 фиксирования» - если да, я бы попытался отключить эти настройки. В противном случае я бы посоветовал обратиться в службу поддержки PlusNet (показать им вывод tcpdump).

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

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

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