HttpServletRequest.getRemoteAddr () sempre retorna 127.0.0.1

Question

Estamos tentando identificar de onde vêm solicitações específicas dentro de nosso aplicativo Java. Nós alteramos os arquivos de log para incluir o endereço IP e estamos usando httpServletRequest.getRemoteAddr () para obter esse endereço remoto.

Em nossas máquinas de desenvolvimento local executando o Tomcat, isso funciona. Em nosso ambiente de IC (Tomcat em um Mac), isso funciona.

O problema é que, nos nossos ambientes de teste e produção, isso não funciona. Nós sempre vemos 127.0.0.1 de httpServletRequest.getRemoteAddr (). Nossos ambientes de preparação e produção são VMs VMware que executam o CentOS. Eles estão rodando dentro / no ESXI e estão por trás de um Cisco 5500 ASA.

Vimos outras postagens semelhantes a esse problema que dizem procurar por um cabeçalho "X-Forwarded-For" e imprimir isso se existir. Não faz. Abaixo está uma lista completa dos cabeçalhos que estão chegando através da solicitação.

Não temos muitas informações sobre como o ASA ou o VMware são configurados, portanto, se houver algo que possa estar causando isso, forneça uma resposta detalhada sobre o que solicitar ao nosso grupo de TI para corrigir isso. Achamos que isso pode estar relacionado ao VMware, já que estamos vendo 127.0.0.1. Se fosse o ASA, presumiríamos que veríamos o IP do ASA, mas estou aberto para dizer que estou incorreto.

Preencha os cabeçalhos para uma solicitação:

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

UPDATE - Acabamos de perceber que tivemos um redirecionamento de porta local envolvido:

A única outra coisa que pode ser relevante é que estamos usando uma porta HTTP xinetd redirecionar para encaminhar o tráfego SSL para uma porta interna:

service https
{
    disable = no
    flags = REUSE
    socket_type = stream
    wait = no
    user = root
    port = 443
    protocol = tcp
    redirect = localhost 8999
    log_on_failure += USERID
}

    

Answer 1

Acontece que foi a parte do xinetd da nossa configuração que estava fazendo isso. Vou fechar essa questão e perguntar a outra especificamente sobre isso.

    

Answer 2

Provavelmente, os arquivos de configuração de rede não estão configurados corretamente. Mais detalhes sobre eles podem ser encontrados aqui: link