Почему некоторые сетевые API могут принимать удаленные подключения, а другие нет?

Я затрудняюсь объяснить такое поведение с веб-серверами в Windows. Он находится в среде домена с брандмауэром Windows, установленным в качестве политики домена.

  • local web servers - both as localhost:port and FQDM:port
    • Tomcat OK
    • IIS в порядке
    • ВЕБрик ОК
    • Сервер Дженкина - ОК
  • remote access - using FQDM:port
    • Tomcat No connection
    • ИИС Нет подключения
    • ВЕБрик ОК
    • Сервер Дженкина - ОК

Что я не понимаю, что использует WEBRick и сервер Jenkins для приема удаленных подключений.

Есть ли другая диагностика, на которую я должен обратить внимание? Можно ли настроить Tomcat для использования аналогичного подхода?


person Scott Weinstein    schedule 25.08.2012    source источник
comment
Есть ли какие-либо записи в журналах ошибок/доступа Tomcat и IIS? Если вы выполняете tracert/traceroute к машине, получаете ли вы полную трассировку? Сервера пингуются? Регистрирует ли брандмауэр сброс для IIS/Tomcat? Можете ли вы опубликовать свои конфигурации Tomcat и IIS?   -  person hughdbrown    schedule 20.09.2012
comment
Вы хотите сказать, что все они находятся на локальном хосте, когда вы получаете к ним доступ внутри своего брандмауэра? Но через удаленный доступ можно получить доступ только к WEBrick и Jenkins? Кроме того, что вы подразумеваете под удаленным доступом - не к вашему компьютеру, но все же в той же внутренней сети, или вы получаете к ним доступ из-за пределов брандмауэра? В любом случае это звучит как проблема блокировки порта. Пожалуйста, укажите, какие порты использует каждый из них.   -  person Domenic D.    schedule 22.09.2012


Ответы (2)


Я не могу много рассказать о WEBRick или Jenkins, но для Tomcat - если вы посмотрите на исходный код Tomcat 7 (StandardServer.java), вы увидите:

// Set up a server socket to wait on
try {
    awaitSocket = new ServerSocket(port, 1,
              InetAddress.getByName(address));
 } catch (IOException e) { ... }

Это означает, что все, что вы укажете в адресе (в вашем server.xml), проходит через это.

В контракте от InetAddress.getByName говорится:

Имя хоста может быть либо именем компьютера, например "java.sun.com", либо текстовым представлением его IP-адреса. Если указан литеральный IP-адрес, проверяется только правильность формата адреса.

На вашем месте я бы сначала попробовал установить только IP-адрес и посмотреть, есть ли какие-либо проблемы.

Второй шаг — проверить, не ошиблась ли у вас политика разрешения локальных имен (файл hosts). Я был в ситуациях, когда локальный файл hosts был неправильным или содержал неразрешимые записи, вызывая всевозможные странные проблемы, подобные той, что у вас есть.

person mindas    schedule 17.09.2012

Похоже, ваш удаленный запрос никогда не достигает служб, которые не отвечают. И это подразумевает, что это проблема брандмауэра или NAT. Я не думаю, что это проблема конфигурации, поскольку вы сказали, что с локальной машины localhost:port и FQDN:port работают.

Для диагностики хорошим первым шагом будет посмотреть, есть ли какая-либо удаленная связь с помощью telnet.

порт имени хоста telnet

Если вы не видите ответа Connected to FQDN., значит, брандмауэр, аппаратный или локальный программный брандмауэр заблокировал соединение. Вам нужно будет убедиться, что у брандмауэров на пути открыты все нужные порты, перенаправление и т. Д.

person jimp    schedule 21.09.2012