HTTP-сервисы недоступны для некоторых интернет-провайдеров

У меня действительно странная проблема, и я не знаю, что делать дальше. Все мои проблемы начались пару недель назад.

Базовая схема моей сети доступна в следующем изображении:

Базовая конфигурация:

Услуги М1:

• Апач на порту 80
• RoR с WEBrick на порту 4321
• SSH на порту 22

Услуги M2:

• USBWebserver на порт 8080

Порт маршрутизатора вперед (от внешнего [E:] к внутреннему)

• E: 81 до M1: 80
• E: 4321 до M1: 4321
• E: 8080 до маршрутизатора: 8080
• E: 8081 до M2: 8080
• E: 22 до M1: 22 (ssh)
• E: от 10000 до M1: 10000 (веб-сервер https)
• E: 3389 до M2: 3389 (rdc)

Эта проблема:

На порту 4321 у меня довольно большой входящий трафик. Моя проблема началась, когда я понял, что мои сервисы HTTPD на M1 были доступны только от некоторых интернет-провайдеров.

Мой интернет-провайдер предоставляет мне статический IP-адрес (188.26.X.XXX), основанный на соединении PPPOE и называемый RDS. Другие интернет-провайдеры в этом вопросе - ROMTELECOM, ORANGE, UPC и INTERSAT.

После нескольких тестов проблема была как пара:

E: 81, E: 4321, E: 8080, E: 10000 не загружается из RDS (моя собственная сеть), ROMTELECOM, INTERSAT. E: 81, E: 4321, E: 8080, E: 10000 загружалось из ROMTELECOM (другой географический регион), UPC и мобильных сетей, таких как ORANGE.

E: 8081, E: 3389 и E: 22 были доступны из любого места.

Все услуги доступны в локальной сети.

Действия по устранению неполадок

1. Отключение любого вида межсетевого экрана на маршрутизаторе и M1.
   • Результат: та же проблема.
2. Изменение IP-адресов и MAC-адресов локальной сети для маршрутизатора (wan) и M1
   • Результат: та же проблема.
3. Замена роутера Asus WL-520GU под управлением DD-WRT с WRT54GL под управлением прошивки по умолчанию и затем Tomato.
   • Результат: та же проблема.
4. Удаление M1 из сети и установка 2 виртуальных машин, VM1 и VM2 на M2. VM1 имеет ту же конфигурацию, что и M1. VM2 была для целей тестирования и работала под управлением WINDOWS XP с RoR для Windows и USBWebserver.
   • Результат: VM1 такой же сценарий, как и M1 (ssh OK. RoR и apache не OK). VM2 недоступен.
5. Удаление роутера из сети и подключение напрямую к М2. Переадресация портов на VM1 и VM2.
   • Результат: та же проблема.
6. В шоке.
   • Результат: та же проблема.
7. Позвонив в службу поддержки интернет-провайдера и отправив электронное письмо. Был сделан телефонный разговор и проблема объяснена. Нет известных проблем от них. Никаких изменений трафика от моего провайдера.
   • Результат: та же проблема.
8. Повторение шагов сверху в случайном порядке ...

Другие тесты, которые я сделал

Используя WFetch, я понял, что мой запрос от затронутых сетей был получен моим сервером, но после нескольких байтов ответ получился слишком быстрым. Используя мой E: 81 с _h5aiв качестве службы для моего скриншота и других целей совместного использования файлов я удалил все файлы и создал index.html с 1 символом. Снова протестировав E: 81 из затронутых сетей, сервис был доступен, и было получено содержимое index.html. Добавляя символы в файл, я обнаружил, что index.html с ~ 1499 символами был успешно получен. При добавлении еще одного персонажа эффект перестает отвечать на запросы, как описано. Нет времени ожидания от браузера, просто ожидание ответа. К сожалению, этот буфер не был таким же на WEBrick. Для воспроизведения проблемы потребовался больший отклик от моего сервера (~ 3 тыс. Символов). E: 8081 был доступен все время из всех сетей.

Кроме того, я понял, что, если я запрашиваю несуществующую страницу: 81 / xyz или: 4321 / xyz, я получаю ошибку 404. С обоих серверов HTTP, apache2 и WEBrick. Это связано с максимальным объемом данных, разрешенным в качестве ответа.

Воспроизведение проблемы

Моя текущая конфигурация содержит VM1. M1 и VM2 был удален. Попробуйте получить доступ к 188.26.X.XXX:4321 и 188.26.X.XXX:81 через браузер и, если не работает, через WFetch .

Спасибо, и я надеюсь, что я прояснил мою проблему.

Я обнаружил, что index.html с ~ 1499 символами был получен последовательно. При добавлении еще одного персонажа эффект перестает отвечать на запросы, как описано.

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

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

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

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

Так почему же не все используют небольшие настройки MTU, с которыми каждый может справиться? Хорошо, каждый отправленный пакет имеет служебную информацию, например, информацию о том, от кого пакет и кому он должен быть отправлен, а также он должен получить ответный ответ, указывающий, что пакет был принят правильно. Следовательно, чем меньше размер пакета, тем больше пакетов вам нужно отправить и тем больше накладных расходов, что замедляет ваше соединение. (Например, по соображениям производительности я понимаю, что для XBOX live требуется MTU не менее 1364)

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

Настройка по умолчанию может зависеть от того, какой тип сетевого подключения вы используете. Например, значение по умолчанию для внутренней сети Windows составляет 1500, тогда как значение по умолчанию для подключений к Интернету с использованием PPPoE - 1492.

Согласно SANS , порт 4321 использовался трояном BoBo. Поскольку вы не указали UDP или TCP, мне интересно, возможно ли, что этот порт был закрыт некоторыми провайдерами?!?! Возможно, вы также захотите посмотреть на этом сайте дополнительную информацию о порте 4321. Кроме того, я понимаю, что многие интернет-провайдеры недовольны людьми, использующими свои веб-серверы, если только это не бизнес с бизнес-контрактом с Интернет-провайдером.