Мы пытаемся определить, откуда поступают конкретные запросы внутри нашего Java-приложения. Мы изменили файлы журнала, чтобы включить IP-адрес, и мы используем httpServletRequest.getRemoteAddr () для получения этого удаленного адреса.
На наших локальных машинах для разработки под управлением Tomcat это работает. В нашей среде CI (Tomcat на Mac) это работает.
Проблема в том, что в нашей тестовой и производственной среде это не работает. Мы всегда видим 127.0.0.1 из httpServletRequest.getRemoteAddr (). Наши тестовые и производственные среды представляют собой виртуальные машины VMware под управлением CentOS. Они работают внутри / на ESXI и находятся за Cisco 5500 ASA.
Мы видели другие сообщения, похожие на эту проблему, в которых говорится, что нужно найти заголовок «X-Forwarded-For» и распечатать его, если он существует. Это не так. Ниже приведен полный список заголовков, поступающих через запрос.
У нас нет особого представления о том, как настраивается ASA или VMware, поэтому, если есть что-то, что могло вызвать это, предоставьте подробный ответ о том, что спросить нашу ИТ-группу, чтобы исправить это. Мы думаем, что это может быть связано с VMware, поскольку мы видим 127.0.0.1. Если бы это был ASA, мы бы предположили, что вместо этого увидим IP-адрес ASA, но я открыт для того, чтобы услышать, что я ошибаюсь.
Полные заголовки запроса:
user-agent:Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)
accept:text/html,application/xhtml+xml,application/xml
q=0.9,*/*
q=0.8
accept-language:en-US,en
q=0.8
accept-charset:ISO-8859-1,UTF-8
q=0.7,*
q=0.7
host:host-omitted-for-stackoverflow.com
connection:keep-alive
ОБНОВЛЕНИЕ - Мы только что поняли, что задействовано перенаправление локального порта:
Единственное, что может иметь значение, это то, что мы используем Перенаправление порта HTTP xinetd для пересылки SSL-трафика на внутренний порт:
service https
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
port = 443
protocol = tcp
redirect = localhost 8999
log_on_failure += USERID
}
Оказывается, это была часть xinetd нашей конфигурации. Я собираюсь закрыть этот вопрос и задать еще один, конкретно спрашивающий об этом.
Вероятно, файлы конфигурации сети установлены неправильно. Подробнее о них можно прочитать здесь: http://docs.oracle.com/cd/E37670_01/E41138/html/ch11s02.html