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

Я провел некоторое тестирование, и у меня есть доступ к сайту через мою сеть WIFI, но он не работает через локальную сеть. Моя сеть WIFI - это просто точка доступа WIFI, подключенная к моей локальной сети, поэтому оба используют одну подсеть и шлюз. У меня были одни и те же проблемы на нескольких компьютерах, и это, кажется, связано только с этим одним сайтом. Остальные сайты, которые я посетил, без проблем.

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

Любые идеи, почему определенный домен будет работать только на точке доступа WIFI, а не на самой локальной сети?

|источник

1 ответ1

0

Если точка доступа Wi-Fi действует как шлюз NAT (который предполагает, что ее порт WAN подключен к порту LAN вышестоящего маршрутизатора), он может работать с DNS по-другому или может выполнять лучшую работу TCP MSS Clamping, чем ваш восходящий поток NAT шлюз делает.

Что касается DNS, предположим, что ваш вышестоящий NAT-шлюз, когда выдает DHCP-аренду для проводного Ethernet-клиента, говорит клиентам использовать DNS-сервер A. Поддерживает вашу точку доступа Wi-Fi, когда вы предоставляете DHCP-аренду клиентам Wi-Fi, вынуждает клиентов использовать DNS-сервер B. Теперь предположим, что у DNS-сервера A есть ошибка, из-за которой он дросселирует ответы DNS для доменного имени одного веб-сайта. Все ваши клиенты Ethernet не смогут найти IP-адрес, который им нужен для подключения к этому веб-сайту, поэтому все они не смогут подключиться. Но ваши клиенты Wi-Fi будут запрашивать DNS-сервер B, у которого нет этой ошибки, поэтому они получат ответы, которые ищут, и смогут подключиться.

Чтобы проверить, является ли DNS проблемой, убедитесь, что все ваши клиенты Ethernet и Wi-Fi получают одинаковые адреса DNS-серверов.

TCP MSS Clamping - это метод, при котором шлюз NAT думает, что он знает о MTU в восходящем направлении (MTU = Maximum Transmission Unit; воспринимает его как максимальный размер IP-пакета), чем его клиенты, поэтому, если он когда-либо увидит, что клиент попытается согласовать TCP MSS (MSS - это максимальный размер сегмента уровня TCP, который является эквивалентом концепции MTU на уровне TCP), который больше, чем уместится в восходящем канале, шлюз NAT переписывает эти поля согласования TCP MSS в пакетах TCP SYN, чтобы обмануть конечные точки TCP, чтобы они согласились на меньшую MSS, которая должна фактически работать, учитывая, что шлюз NAT знает об ограничениях MTU на других сетевых скачках.

Чтобы проверить, является ли проблема MTU, попытайтесь пропинговать проблемный веб-сайт с помощью обычного ~ 64-байтового эхо-запроса ICMP, а затем повторите попытку с эхо-запросом ICMP, который заполняет весь 1500-байтовый кадр:

# Normal small pings first, just to see if pings work
ping badwebsite.example.com
# Now pad the pings out to 1472 so that, after headers are added, it's a full 1500 byte frame.
ping -s 1472 badwebsite.example.com

(Полагаю, мне не следовало это говорить, но на всякий случай убедитесь, что вы выполнили эти тесты ping с клиента Ethernet, а не клиента Wi-Fi.)

Если маленькие пинги работают, но большие пинги терпят неудачу, это указывает на проблему MTU. Попробуйте разные значения после -s чтобы увидеть, какое максимальное значение подходит вам. Добавьте к нему 28, чтобы узнать, какой MTU вы можете безопасно установить на своих клиентах Ethernet. На самом деле, лучше, чем ручная установка меньшего MTU на ваших клиентах Ethernet, исправьте свой восходящий NAT, чтобы выполнить надлежащий MSS-зажим или что-то в этом роде.

|источник

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