Странная проблема с брандмауэром
Мы установили веб-сервер в сети, он был недавно перемещен из среды тестирования в другой подсети в другой офис. Теперь, когда у нас есть сервер, мы можем получить к нему доступ по внутреннему IP-адресу, но не можем связаться с ним по назначенному внешнему IP-адресу. Я не уверен, что делать как обычно, как только вы пропустите через порты 80 и 443 и сопоставите внешний IP-адрес с внутренним, который вы обычно используете и работаете.
Я даже зашел так далеко, что отключил брандмауэр на сервере IIS под управлением сервера 2008. Я могу получить доступ к сайту по его внутреннему ip как по HTTP, так и по SSL. Администратор говорит мне, что на брандмауэре установлены правильные настройки, но у меня недостаточно прав для подтверждения. Моя обычная логика говорит мне, что если я смогу получить к нему доступ внутри, пока брандмауэр / маршрутизатор настроен правильно, я также смогу получить доступ и за пределами сети.
Это сервер 2008, а не R2. Я знаю, что Windows 2008 может отличать трафик от локальной и внешней сетей в брандмауэре, но я подумал, что это можно обойти, отключив брандмауэр Windows. Я продолжаю смотреть на брандмауэр, но хочу убедиться, что ничего не пропустил.
Есть ли что-то кроме того, что я упомянул, что я должен проверить? Я в растерянности
2 ответа
Таким образом, ваша проблема заключается в том, что вам трудно определить, где находится проблема, то есть, находится ли проблема на новом веб-сервере, который переместился из среды тестирования в другую подсеть.
Часть путаницы связана с терминологией. Вы должны уточнить, хотя бы для вашего собственного здравомыслия между сетевым брандмауэром (который может использовать программное обеспечение Checkpoint на основе ваших тегов, но не указано иное) и брандмауэром Windows системы веб-сервера на веб-сервере.
Под "внешним IP" я понимаю, что вы имеете в виду маршрутизируемый IP-адрес, доступ к которому можно получить через Интернет, или, другими словами, не частный IP-адрес RFC 1918.
Трудно сказать, не зная топологию сети, на которую ссылается user48838 в своем хорошем ответе.
При включенном брандмауэре Windows и зарегистрированных отклоненных или запрещенных подключений, если вы не видите запрещенных / отклоненных подключений для веб-подключения или неудачных попыток подключения к сети в журналах средства просмотра событий, то, скорее всего, возникнет проблема, связанная с трансляция сетевых адресов назначения (D-NAT или DNAT) для пересылки внешних запросов на веб-сервер в вашей внутренней сети с его внутренним IP-адресом. Возможны и другие подходы для пересылки внешних IP-адресов, но DNAT является наиболее распространенным.
Будучи фанатом Unix, я бы обычно использовал tcpdump для проверки этого. Поэтому включите любой мониторинг TCP на хосте на сервере ( WinDump, Ethereal или Wireshark), чтобы узнать, получает ли он какие-либо попытки TCP-соединения для порта 80 (HTTP) или 443. tcpdump "tcp port 80 or port 443"
Конечно, как сказал @user48838, возможно, дело в том, что ваша сеть не настроена для правильной пересылки внутренних запросов на ваши внешние IP-адреса, что может быть проблемой, если вы пытаетесь получить доступ к веб-серверу из внутренней сети., Если это не является обычной проблемой, вам нужно изменить процедуры тестирования, например, использовать внешний прокси для тестирования.
Вы не упомянули никаких прокси-серверов, я предполагаю, что они не вовлечены в эту настройку сети.
"не может связаться с ним по назначенному внешнему IP"
Откуда в сети это делается? Внутренне или внешне? Если внутренне, вы пробовали также с внешней точки зрения?
Если его внешний IP-адрес доступен из внешней точки, но не изнутри, то это может быть конфигурация / способность маршрутизатора "зацикливаться" на трафике, который пересекает / переходит между внутренним-внешним-внутренним.