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