Métodos para Recuperar o IP de Origem do Cliente

Em certas situações, nossos serviços exigem o uso do IP do cliente por razões específicas de negócios ou segurança. No entanto, o cenário usual envolve o tráfego passando por várias redes, balanceadores de carga ou serviços de proxy antes de chegar ao serviço real. Em cada camada desse processo, o IP original do cliente pode ser perdido, deixando nosso serviço apenas com o IP da rede anterior. Esse resultado não é ideal para nós.

Devido à natureza complexa de nossa stack tecnológica, obter o IP do cliente envolve o uso de vários métodos, às vezes em combinação.

Gerenciamento do IP do Cliente via NAT

Em certas infraestruturas de IDC estabelecidas ou alugadas por usuários, nossos serviços podem residir em uma rede LAN separada atrás de um gateway. Quando os clientes tentam se conectar aos nossos serviços a partir de uma rede externa, o tráfego é roteado através do gateway.

Um cenário semelhante pode surgir ao utilizar serviços em nuvem. A rede VPC fornecida por plataformas de nuvem pública funciona como uma rede LAN independente, isolada de outras VPCs e da internet. Como resultado, um gateway é necessário para facilitar o acesso à internet externa e conectar-se a serviços externos.

Esse gateway, que pode ser um roteador ou dispositivo de firewall, geralmente oferece serviços de tradução de endereço DNAT (Destination NAT) para serviços internos. Isso envolve o gateway possuindo um ou mais endereços IP públicos e encaminhando o tráfego de portas específicas no IP público para portas específicas em um IP interno. O gateway gerencia o encaminhamento de tráfego e o mapeamento de portas. No entanto, devido à modificação do endereço de origem no cabeçalho do pacote IP original pelo gateway, nossos serviços dentro da rede interna só podem identificar o endereço IP do gateway, não o endereço real do cliente.

Historicamente, as capacidades de DNAT fornecidas por dispositivos de rede ou software eram relativamente básicas. Elas operavam principalmente na camada 3 e não tinham capacidade de manipulação e reconhecimento de payloads de camadas mais profundas. Seu principal propósito era a exposição de serviços, e elas não podiam passar o IP do cliente para o próximo nível. Além disso, devido às limitações de desempenho desses dispositivos ou software, havia restrições no número de conexões ativas e no número máximo de novas conexões que podiam lidar. Escalar sem atualizações de hardware era frequentemente desafiador, tornando-os menos adaptáveis ao ambiente dinâmico de hoje.

Para lidar com essas limitações, recorremos ao balanceamento de carga, que possui capacidades mais avançadas de manipulação de tráfego.

IP do Cliente no Balanceamento de Carga

Em geral, o balanceamento de carga é principalmente categorizado em dois tipos com base em sua camada de trabalho: camada 4 e camada 7, correspondendo a fluxos de dados TCP e tráfego de aplicação (representado por HTTP), respectivamente.

Diferente dos gateways de IP, o balanceamento de carga evita modificar o cabeçalho do pacote IP. No nível do pacote IP, ele apenas realiza encaminhamento transparente. Consequentemente, em contraste com o DNAT discutido anteriormente, o balanceamento de carga garante a passagem correta do IP de origem contido no pacote IP para os componentes atrás do balanceador de carga.

Para o balanceamento de carga na camada 4, após realizar o encaminhamento básico de tráfego, os serviços subsequentes podem recuperar com precisão o IP do cliente sem a necessidade de qualquer processamento especial. Em cenários excepcionais, ele pode aproveitar o Proxy Protocol. Isso envolve anexar uma nova seção antes do payload original do tráfego, englobando o IP do cliente. Outros servidores proxy reverso ou o próprio serviço atrás do balanceador de carga podem então interpretar os dados do Proxy Protocol para obter o IP do cliente.

Para o balanceamento de carga na camada 7, ele possui capacidades mais profundas de processamento de tráfego. Ele pode transmitir diretamente o IP de origem no nível do protocolo HTTP. Uma abordagem prevalente é a utilização do cabeçalho HTTP X-Forwarded-For. O componente de balanceamento de carga extrai o IP de origem do pacote IP do tráfego, subsequentemente analisando e reescrevendo a requisição HTTP. Ele insere um novo campo XFF em seu cabeçalho de requisição, incorporando o valor do IP do cliente.

O HTTPS apresenta um desafio particular devido ao seu payload criptografado, tornando o componente de balanceamento de carga incapaz de manipular diretamente seus cabeçalhos HTTP. Nessas situações, as seguintes abordagens podem ser consideradas:

• Sem requisitos específicos, tratar o tráfego HTTPS como tráfego TLS padrão e encaminhá-lo diretamente na camada 4 é uma opção. Nesse cenário, o IP do cliente ainda pode ser transmitido para o serviço atrás do balanceador de carga através do cabeçalho do pacote IP.

• Quando a funcionalidade da camada 7 é necessária, hospedar o certificado TLS no componente de balanceamento de carga permite a terminação TLS. Esse processo envolve remover a criptografia TLS na camada de balanceamento de carga, utilizando HTTP simples na LAN atrás do balanceador de carga ou estabelecendo uma nova conexão HTTPS para o serviço em vez de encaminhamento direto. Isso permite que o componente de balanceamento de carga manipule novamente o tráfego HTTP original e continue passando o IP usando o método XFF.

Através de manipulação sutil de tráfego, o balanceamento de carga oferece vários métodos para transmitir o IP do cliente para o serviço de backend. Implementações representativas de componentes de balanceamento de carga incluem serviços ELB baseados em nuvem, F5 BIG-IP baseado em hardware, Linux Virtual Server (LVS) baseado no kernel Linux e NGINX baseado em software de usuário.

Transmissão do IP do Cliente em Serviços de CDN

Ocasionalmente, aproveitamos os serviços de CDN fornecidos por plataformas de nuvem pública para melhorar a velocidade de acesso dos usuários aos nossos serviços. Seu funcionamento é semelhante a um servidor proxy reverso na camada 7, mas em um contexto mais amplo, os CDNs podem ser considerados parte do domínio de balanceamento de carga.

Os serviços de CDN geralmente fornecem capacidades de terminação TLS e podem incorporar o IP do cliente em requisições HTTP enviadas ao serviço. Por exemplo, o serviço de CDN AWS CloudFront suporta passar o IP do cliente usando o método XFF, semelhante à abordagem usada no balanceamento de carga na camada 7.

Utilização de API Gateway

Embora os componentes de balanceamento de carga geralmente ofereçam capacidades básicas de controle de tráfego, as APIs fornecidas por balanceadores de carga baseados em nuvem ou hardware podem ser difíceis de alinhar com nossas necessidades específicas de negócios. Nessas situações, recorremos a componentes mais adaptáveis para aplicar estratégias personalizadas aos nossos serviços. É aqui que um API gateway, como Apache APISIX ou API7 Enterprise, entra em cena.

APISIX e API7 Enterprise suportam o Proxy Protocol, permitindo a recuperação do IP do cliente do balanceador de carga.

Além disso, eles possuem um plugin chamado "real-ip", semelhante ao ngx_http_realip_module do NGINX. Esse plugin obtém o IP do cliente de uma fonte e o usa para transmissão e registro downstream. O plugin real-ip no APISIX e API7 Enterprise aprimora a funcionalidade encontrada no NGINX. Ele permite a ativação ou desativação dinâmica do recurso de IP de origem real e expande as fontes de IP do cliente além das restrições do ngx_http_realip_module, que é limitado a cabeçalhos HTTP e Proxy Protocol. Ele pode aproveitar qualquer variável estendida do NGINX ou APISIX, como parâmetros de consulta ou campos de formulário POST.

Resumo

Ao aproveitar uma combinação de tecnologias em diferentes camadas, podemos efetivamente passar o IP do cliente através de cada componente do serviço, atendendo tanto às necessidades de negócios quanto de segurança.

Para saber mais sobre soluções de gerenciamento de API, entre em contato com API7.ai.