Тайна брандмауэра? Контрольный список для диагностики заблокированных входящих соединений

Question

Я использую веб-сервер для разработки на Lenovo Thinkpad T420s и не могу подключиться к нему с трех отдельных устройств (настольного компьютера, iPad и телефона соответственно).

Ноутбук и другие устройства подключены к маршрутизатору, работающему под управлением DD-WRT (настольный компьютер, все остальное беспроводное). Я уже определил следующее:

Контрольный список для тех, кто испытывает проблемы с подключением к локальному серверу

• Сервер работает и прослушивает соединения (проверено через http на localhost).
• netstat -a -n -b показывает, что что-то прослушивает соответствующий порт.
• Брандмауэр Windows полностью отключен в общедоступных, частных и доменных сетях.
• IP-адрес хоста является статическим.
• Другие серверы на хосте тоже не работают (я пробовал один на порту 8000, 1515, а также тестировал ping).
• На другом (настольном) компьютере я смог разместить сервер и отвечать на пинг с моего телефона. Интересно, что я также смог получить доступ к настольному серверу с моего ноутбука и ipad, но только через секунду после "пробуждения" сервера с помощью запроса с моего телефона. (Это не работает для сервера на ноутбуке.)

В дополнение к обычным исправлениям я пробовал ряд других вещей:

Контрольный список для тех, кто пробовал все вышеперечисленное

• Убедитесь, что изоляция AP отключена (http://www.dd-wrt.com/wiki/index.php/Advanced_wireless_settings#AP_Isolation)
• Восстановление Winsock2 (http://answers.microsoft.com/en-us/windows/forum/windows_7-system/resettingrepairingreinstall-winsock2-testing/aa044f6b-00e2-406b-8edb-cba5c4799cf2)
• Соединения VIP-доступа не установлены, насколько я могу судить (см. Здесь, где кто-то еще находит, что это блокирует входящие соединения)
• Обнаружение обоих входящих подключений с помощью Wireshark (это указывало на то, что веб-хост не услышал входящего запроса, когда я сделал один с моего телефона.)
• Обнаружение исходящих соединений путем попытки получить доступ к хосту с моего рабочего стола и анализ с рабочего стола показало, что исходящих HTTP-запросов вообще не было, только серия TCP:

Мой вопрос двоякий:

1. Есть ли что-то особенное на Thinkpad T420s, которое могло бы тайно блокировать входящие соединения?
2. Какой лучший способ систематически выяснить, почему на входящие соединения не отвечают? (См. Ответ выше)

Любая помощь в этом будет очень и очень признательна. У меня заканчиваются идеи!

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

Answer 1

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

2. Отличным инструментом для систематического устранения неполадок с подключением был бы анализатор пакетов, как wireshark. На данный момент вы угадываете, что происходит в сети. Затем переключение различных настроек в надежде подтвердить предположение. Зачем догадываться, когда можно посмотреть и посмотреть? Захват пакетов даст вам живое считывание того, что происходит. Вы можете обнаружить, что пакет TCP SYN никогда не достигает сервера или он достигает сервера, но ответ не выдается. В качестве альтернативы это может быть что-то еще, например, проблема разрешения имени / IP / ARP. Сниффер ничего не исправит сам по себе, но он должен дать вам гораздо лучшее представление о том, что происходит сейчас.

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

Wireshark Protocol Analyzer

Изменить: Просто хотел продолжить сейчас, когда вы добавили скриншот захвата пакета. Это значительно более ясно, что происходит. Одной из проблем использования такого инструмента, как wireshark, является понимание того, как должны выглядеть протоколы. Так как HTTP работает поверх обычного TCP-соединения, здесь вы видите серию сбоев при настройке TCP-соединения через порт 1515. Причина, по которой вы не видите HTTP, заключается в том, что TCP-соединение не удалось до того, как разговор между клиентом и сервером может зайти так далеко. Я проведу вас по номеру пакета через первые две попытки:

пакет (204) .150 -> .151 [SYN] «Привет, я хотел бы подключиться к порту 1515»

пакет (207) .151 -> .150 [RST, ACK] "Не прослушивается. Здесь нет порта 1515. Окунись хорошо?"

пакет (208) .150 -> .151 [SYN] "Привет, я хотел бы подключиться к порту 1515"

пакет (209) .151 -> .150 [RST, ACK] "Не прослушивается. Здесь нет порта 1515. Окунись хорошо?"

так далее...

Флаг RST в диалоге TCP является принудительным закрытием. Это более грубо, чем обычный флаг FIN, который изящно заканчивает разговор. Обычно это означает, что существует порт 1515 блокировки межсетевого экрана или ничего не прослушивается на порту 1515. Я чаще вижу [RST, ACK] с серверов, у которых нет службы, прослушивающей этот порт, тогда как брандмауэры, как правило, просто RST или черная дыра (без ответа) трафика.

Теперь, когда он работает, сделайте еще один захват, чтобы увидеть, как выглядит успешное соединение. Это должно быть что-то вроде:

.150 -> .151 [SYN] "Привет, я хотел бы подключиться к порту 1515"

.151 -> .150 [SYN, ACK] "Подтверждено, вот мой размер буфера"

.150 -> .151 [ACK] "У меня работает"

.150 -> .151 [ACK] [HTTP/GET] "Запрос html через HTTP"

.151 -> .150 [ACK] [HTTP/1.1 200 OK] "Вот HTML-код, который вы запросили"

серия HTTP-разговоров поверх TCP ACK

.150 -> .151 [FIN] "Спасибо, сервер, я все сделал, теперь закрываю соединение"

.151 -> .150 [ACK, FIN] "Я согласен, мы должны закрыть соединение"