Transparência de IP e retorno direto do servidor com NGINX e NGINX Plus como proxy transparente

Owen GarrettDiretor Sênior de Gestão de Produtos

Esta publicação do blog descreve como configurar o NGINX Open Source e o NGINX Plus como um proxy transparente para o tráfego destinado a servidores upstream. Ela explica como usar um proxy transparente para falsificar o endereço IP de origem dos pacotes a fim de implementar a Transparência de IP e como implementar um modo de balanceamento de carga chamado Direct Server Return para tráfego UDP.

As informações desta publicação se aplicam tanto ao NGINX Open Source quanto ao NGINX Plus. Para simplificar, mencionaremos apenas o NGINX Plus.

Editor – Este é o quinto de uma série de posts do blog que exploram em detalhes os novos recursos do NGINX Plus R10.

• Autenticação de clientes de API com JWT e NGINX Plus
• NGINX Plus R10 aproveita o poder do IBM POWER
• Autenticação de usuários em aplicações existentes com OpenID Connect e NGINX Plus
• Como usar o módulo JavaScript do NGINX para migrar clientes progressivamente para um novo servidor
• Transparência de IP e retorno direto do servidor com o NGINX e o NGINX Plus como proxy transparente (este artigo)

Não deixe também de conferir o webinar sob demanda, Quais são as novidades do NGINX Plus R10?

Resumo

O NGINX Plus funciona como um proxy reverso de camada 7. Isso permite que o NGINX Plus aplique diversas otimizações e melhorias às solicitações de rede que gerencia.

Como consequência, os servidores upstream (com balanceamento de carga) observam que todo o tráfego se origina de um endereço IP no proxy NGINX Plus. Isso representa um desafio quando o servidor upstream precisa determinar o verdadeiro endereço IP de origem (o do cliente remoto), por exemplo, para fins de autenticação ou registro em log.

Há soluções alternativas eficazes para o tráfego HTTP e HTTPS, usando o cabeçalho HTTP X-Forwarded-For ou o protocolo PROXY. Este artigo descreve dois métodos adicionais, aplicáveis ao tráfego TCP e UDP:

• Transparência de IP garante que os servidores upstream identifiquem que cada conexão se origina do cliente remoto que a iniciou. Ela se aplica a protocolos baseados em TCP e UDP.
• Retorno direto do servidor (DSR) também faz com que as respostas dos servidores upstream sejam enviadas diretamente aos clientes remotos, sem passar pelo balanceador de carga intermediário. É aplicável a protocolos baseados em UDP e pode ser implementado por meio de NAT (tradução de endereços de rede) no servidor de origem ou em um roteador intermediário.

Método 1 – Transparência de IP Método 2a – DSR (NAT no roteador) Método 2b – DSR (NAT na origem)Protocolos compatíveis Baseados em TCP e UDP Somente baseados em UDP Somente baseados em UDPRoteamento de tráfego pelos servidores upstream Todo o tráfego de saída é roteado para o proxy NGINX Plus e encerrado Todo o tráfego de saída é roteado pelo servidor NGINX Plus intermediário Todo o tráfego é roteado normalmenteDesempenho Padrão: o tráfego de saída é encerrado no proxy NGINX Plus Melhor: o tráfego de saída é encaminhado pelo servidor NGINX Plus intermediário Ideal: o tráfego de saída é roteado diretamente para o cliente remoto, ignorando o NGINX PlusVerificações de integridade Passivas por padrão; há suporte para verificações ativas Verificações ativas obrigatórias; verificações passivas não são possíveis Verificações ativas obrigatórias; verificações passivas não são possíveisConfiguração necessáriaTCP e UDP no proxy NGINX Plus TCP: funciona por padrão
UDP: proxy_responses 1 TCP: não compatível
UDP: proxy_responses 0 TCP: não compatível
UDP: proxy_responses 0Como e onde os pacotes são processados? iptables encerra os pacotes no proxy NGINX Plus tc nat reescreve os pacotes no servidor NGINX Plus intermediário tc nat reescreve os pacotes nos servidores upstreamConfiguração de rede no proxy NGINX Plus iptables para capturar pacotes de saída Encaminhamento de IP e NAT sem estado NenhumaConfiguração de rede no servidor upstream Definir o NGINX Plus como rota padrão Definir o NGINX Plus como rota padrão NAT sem estado

A implantação e a solução de problemas de Transparência de IP e DSR são complexas. Implemente essas configurações somente se o modo de operação padrão de proxy reverso não for suficiente para seu aplicativo ou serviço.

Introdução: fluxo de pacotes em um proxy reverso padrão de camada 7

Ao contrário de um switch ou roteador que simplesmente encaminha pacotes, o NGINX Plus opera como um proxy reverso de camada 7. Nesse modo de operação, o NGINX Plus gerencia conexões TCP separadas no lado do cliente e no lado do upstream (para tráfego HTTP e TCP) ou sessões UDP, a fim de controlar a comunicação entre o cliente remoto e o servidor upstream selecionado.

1. Os clientes remotos estabelecem conexões TCP ou enviam datagramas UDP diretamente ao proxy reverso NGINX Plus no endereço IP e na porta publicados. O NGINX Plus encerra a conexão TCP ou a sessão UDP e lê os dados da solicitação contidos nela.
2. Em seguida, o NGINX Plus estabelece uma nova conexão (ou reutiliza uma conexão ociosa existente) com o servidor upstream selecionado (por balanceamento de carga).
3. Quando o NGINX Plus envia a solicitação ao servidor upstream, a conexão se origina no endereço IP interno do NGINX Plus.
4. Quando o servidor upstream responde à solicitação, ele grava os dados no endereço IP interno do NGINX Plus.
5. O NGINX Plus recebe os dados da resposta na conexão com o servidor upstream. Ele pode processar ou modificar a resposta (por exemplo, aplicar compactação a uma resposta HTTP).
6. Em seguida, o NGINX Plus grava os dados da resposta na conexão do lado do cliente.

Uma consequência desse modo de operação padrão de proxy reverso é que o servidor upstream identifica que o tráfego TCP e UDP se origina no proxy NGINX Plus local.

Benefícios e limitações do modo de proxy reverso da camada 7

O modo de operação de proxy reverso da camada 7 proporciona ganhos significativos de desempenho e eficiência para o tráfego HTTP e TCP (incluindo otimizações de TCP, armazenamento em buffer e reutilização de conexões HTTP keepalive). No entanto, ele representa um desafio quando o servidor upstream precisa determinar o verdadeiro endereço IP de origem da conexão ou sessão para fins como autenticação e controle de acesso, limitação de taxa e registro de logs.

Para alguns protocolos, o NGINX Plus pode usar o cabeçalho HTTP X-Forwarded-For ou o protocolo PROXY para fornecer o endereço IP de origem aos servidores upstream. Este artigo descreve dois métodos adicionais, possibilitados pelo parâmetro transparent da diretiva proxy_bind, que foi introduzido no NGINX Plus Release 10 (R10)<.htmla>.

Método 1: transparência de IP

O objetivo da Transparência de IP é ocultar a presença do proxy reverso para que o servidor de origem identifique que os pacotes IP são provenientes do endereço IP do cliente. A Transparência de IP pode ser usada com protocolos baseados em TCP e UDP.

Como criar um serviço de proxy reverso HTTP no balanceador de carga NGINX Plus

Para demonstrar a Transparência de IP, primeiro criamos um cluster com balanceamento de carga composto por quatro servidores web que respondem com algumas informações básicas sobre a conexão.

1. Configure um servidor virtual HTTP simples que distribua a carga do tráfego entre um grupo de servidores upstream:

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_pass http://http_upstreams;
    }
}

upstream http_upstreams {
    server 172.16.0.11;
    server 172.16.0.12;
    server 172.16.0.13;
    server 172.16.0.14;
}

1. Para confirmar que os servidores upstream identificam que as conexões se originam no balanceador de carga NGINX Plus, configure um servidor web NGINX Plus em cada um dos quatro servidores (de 172.16.0.11 a 172.16.01.14), com um servidor virtual simples que retorne informações sobre a conexão, como:

# in the 'http' context
server {
    listen 80;

    location / {
        return 200 "Hello from $hostname. You connected from $remote_addr:$remote_port to $server_addr:$server_portn";
    }
}

Quando testamos essa configuração, os servidores upstream informam que as conexões se originam do endereço IP local do NGINX Plus (172.16.0.1):

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 172.16.0.1:42723 to 172.16.0.11:80
Hello from dev2. You connected from 172.16.0.1:39117 to 172.16.0.12:80
Hello from dev3. You connected from 172.16.0.1:54545 to 172.16.0.13:80
Hello from dev4. You connected from 172.16.0.1:57020 to 172.16.0.14:80

Configurando o NGINX Plus e seus upstreams para transparência de IP

O NGINX Plus R10 e versões posteriores (e o NGINX Open Source 1.11.0 e versões posteriores) podem simular o endereço de origem do tráfego enviado aos servidores upstream. Inclua o parâmetro transparent na diretiva proxy_bind. Na maioria dos casos, você define como endereço de origem o endereço do cliente remoto:

proxy_bind $remote_addr transparent;

No entanto, essa etapa simples cria um desafio significativo, pois é necessário garantir que o tráfego de resposta (saída) para o cliente remoto seja tratado corretamente. O tráfego de resposta deve ser roteado para o NGINX Plus, que deve encerrar a conexão TCP upstream. Em seguida, o NGINX Plus envia o tráfego de resposta ao cliente remoto pela conexão TCP do cliente.

Você precisa fazer várias alterações de configuração, tanto no balanceador de carga NGINX Plus quanto em cada servidor upstream:

1. No balanceador de carga NGINX Plus, configure os processos de trabalho para serem executados como root, para que possam associar os soquetes upstream a endereços arbitrários. No contexto principal (nível superior) em /etc/nginx/nginx.conf, inclua a diretiva user para definir o ID dos processos de trabalho do NGINX Plus como root:

# in the 'main' context
# 'user daemon' is the default; change to 'user root' with transparent proxy_bind
user root;

1. No balanceador de carga NGINX Plus, certifique-se de que cada conexão seja originada do endereço do cliente remoto. Adicione a diretiva proxy_bind com o parâmetro transparent à configuração do servidor virtual:

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_bind $remote_addr transparent;
        proxy_pass http://http_upstreams;
    }
}

1. No balanceador de carga NGINX Plus, configure o iptables para capturar os pacotes de retorno dos servidores upstream e entregá-los ao NGINX Plus. Neste exemplo, executamos os comandos iptables e ip rule para capturar todo o tráfego TCP na porta 80 proveniente dos servidores representados pelo intervalo de IPs 172.16.0.0/28:

# ip rule add fwmark 1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100
# iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff

1. Execute o seguinte comando para listar (-L) a configuração atual da tabela mangle do iptables:

# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  172.16.0.0/28        anywhere             tcp spt:http MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

1. Nos servidores upstream, configure o roteamento para que todo o tráfego de retorno seja encaminhado ao NGINX Plus. Em cada servidor upstream, remova qualquer rota padrão preexistente e configure a rota padrão com o endereço IP do balanceador de carga/proxy reverso NGINX Plus. Observe que esse endereço IP deve estar na mesma sub-rede que uma das interfaces do servidor upstream.

# route del default gw 10.0.2.2
# route add default gw 172.16.0.1

1. Verifique se a tabela de roteamento parece correta:

# route -n
Kernel IP routing table
Destination   Gateway     Genmask        Flags Metric Ref Use Iface
0.0.0.0       172.16.0.1  0.0.0.0        UG    0      0     0 eth2
10.0.2.0      0.0.0.0     255.255.255.0  U     0      0     0 eth0
172.16.0.0    0.0.0.0     255.255.255.0  U     0      0     0 eth2
192.168.56.0  0.0.0.0     255.255.255.0  U     0      0     0 eth1

1. Se os servidores upstream precisarem se conectar a servidores externos, você também precisará configurar o novo gateway do NGINX Plus para encaminhar e mascarar o tráfego – consulte Como permitir que servidores upstream acessem servidores externos abaixo.

Testando a configuração de transparência de IP

Agora você pode testar a configuração enviando solicitações ao NGINX Plus. Certifique-se de enviar as solicitações de um endereço IP remoto que não seja diretamente roteável pelos servidores upstream:

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 192.168.99.1:60729 to 172.16.0.11:80
Hello from dev2. You connected from 192.168.99.1:43070 to 172.16.0.12:80
Hello from dev3. You connected from 192.168.99.1:45749 to 172.16.0.13:80
Hello from dev4. You connected from 192.168.99.1:46609 to 172.16.0.14:80

Observe que agora as conexões parecem se originar do endereço IP do cliente remoto (192.168.99.1), e não de um endereço local do balanceador de carga NGINX Plus.

Se a configuração não funcionar, consulte a seção Solução de problemas abaixo.

Resumo: como funciona a configuração de transparência de IP?

• O NGINX Plus recebe uma solicitação HTTP de um cliente remoto (192.168.99.1).
• O NGINX Plus toma uma decisão de balanceamento de carga, selecionando um servidor upstream (por exemplo, 172.16.0.11) ao qual se conectar. Antes de estabelecer a conexão, o NGINX Plus vincula seu socket upstream ao endereço do cliente remoto.
• O servidor upstream recebe a conexão, que parece se originar diretamente do cliente remoto.
• O servidor upstream responde, endereçando os pacotes ao endereço do cliente remoto e roteando-os por meio do NGINX Plus (o roteador padrão).
• A regra do iptables no balanceador de carga NGINX Plus marca esses pacotes, e o roteamento os entrega localmente.
• O NGINX Plus lê a resposta.
• Em seguida, o NGINX Plus envia a resposta ao cliente remoto.

O resultado final é que, do ponto de vista dos servidores upstream, as conexões parecem se originar diretamente dos clientes remotos.

Método 2: Retorno direto do servidor

O Retorno Direto do Servidor (DSR) é uma extensão do conceito de Transparência de IP. Na Transparência de IP, o servidor upstream recebe pacotes que parecem ter sido originados pelo cliente remoto. Com o DSR, além disso, o servidor upstream responde diretamente ao cliente remoto; os pacotes de retorno ignoram completamente o balanceador de carga.

O DSR pode proporcionar um pequeno ganho de desempenho, pois reduz a carga sobre o balanceador de carga, mas apresenta algumas limitações:

• O balanceador de carga nunca recebe os pacotes de retorno, portanto não consegue detectar se o servidor upstream está respondendo ou se apresentou uma falha.
• O balanceador de carga não consegue inspecionar uma solicitação além do primeiro pacote antes de selecionar um servidor upstream, portanto sua capacidade de tomar decisões de balanceamento de carga (roteamento baseado em conteúdo) é muito limitada.
• O balanceador de carga não pode participar de nenhuma forma de negociação ou processamento com estado, como SSL/TLS.
• A maioria dos outros recursos de controladores de entrega de aplicações (ADC) não é compatível com DSR, como armazenamento em cache, multiplexação HTTP e registro em log.

O DSR tem uso limitado para protocolos TCP e, de qualquer forma, a arquitetura de proxy reverso do NGINX Plus não pode ser aplicada a DSR/TCP.

Os protocolos UDP são muito mais simples e não têm nenhuma das semânticas de conexão do TCP. Você pode configurar o NGINX Plus para oferecer suporte a DSR para protocolos UDP, como DNS, o que pode proporcionar benefícios de desempenho. Especificamente, com DSR, o NGINX Plus não precisa manter os soquetes UDP abertos à espera de um pacote de resposta (o que melhora a escalabilidade), e os pacotes de resposta podem ignorar completamente o processamento de Camada 7 do NGINX Plus (o que reduz a latência).

Qual é a diferença entre uma configuração de DSR e a transparência de IP?

Há três diferenças entre uma configuração de Transparência de IP e uma configuração de DSR para tráfego UDP:

• O NGINX Plus deve falsificar tanto o endereço IP do cliente remoto quanto a porta ao enviar datagramas para servidores upstream (proxy_bind configuração de porta).
• O NGINX Plus não deve ser configurado para esperar datagramas de resposta dos servidores upstream (a diretiva proxy_responses 0).
• É necessária uma etapa adicional para reescrever o endereço de origem dos datagramas de retorno, de modo que corresponda ao endereço público do balanceador de carga.

Além disso, o NGINX Plus deve ser configurado para realizar verificações ativas de integridade nos servidores upstream. O NGINX Plus não pode depender de suas verificações passivas habituais para determinar se um servidor está íntegro, pois não observa os pacotes de resposta enviados pelo servidor.

Como criar um serviço padrão de proxy reverso UDP

Para demonstrar o DSR, primeiro crie um cluster com balanceamento de carga composto por quatro servidores DNS que respondam com endereços IP diferentes às consultas pelo nome www.example.com.

Configure uma configuração simples de proxy reverso que distribua a carga entre os servidores DNS:

# in the 'stream' context
server {
    listen 53 udp;

    proxy_responses 1;
    proxy_timeout 1s;
    proxy_pass dns_upstreams;
}

upstream dns_upstreams {
    server 172.16.0.11:53;
    server 172.16.0.12:53;
    server 172.16.0.13:53;
    server 172.16.0.14:53;
}

As diretivas proxy_responses e proxy_timeout implementam uma verificação básica de integridade. Se um servidor upstream não enviar uma resposta em até 1 segundo, o NGINX Plus presumirá que o servidor falhou e tentará novamente a solicitação DNS.

Configure cada servidor DNS para responder com seu próprio endereço IP às consultas de www.example.com:

$TTL   	604800
@           IN          SOA         ns1.example.com. admin.example.com. (
                              2           ; Serial
                         604800           ; Refresh
                          86400           ; Retry
                        2419200           ; Expire
                         604800 )         ; Negative Cache TTL

example.com.    IN      NS      ns1.example.com.

ns1             IN      A       172.16.0.11
www             IN      A       172.16.0.11

Os testes deixam claro que o NGINX Plus está distribuindo as solicitações entre os servidores DNS:

$ for i in {1..4} ; do dig +short @192.168.99.10 www.example.com ; done
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

Configurando o NGINX Plus e seus upstreams UDP para DSR

O NGINX Plus R10 e versões posteriores (e o NGINX Open Source 1.11.2 e versões posteriores) pode falsificar tanto o endereço de origem quanto a porta do tráfego upstream. Inclua o parâmetro transparent na diretiva proxy_bind:

proxy_bind $remote_addr:$remote_port transparent;

Isso permite que o servidor upstream veja o endereço IP de origem completo e, assim, crie datagramas de resposta que são enviados diretamente ao cliente remoto.

O servidor upstream gera pacotes de resposta (“saída”) com o destino IP correto, mas usa seu endereço IP local como endereço de origem. O endereço de origem precisa ser reescrito para o endereço IP e a porta do balanceador de carga NGINX Plus ao qual o cliente se conectou originalmente.

Há dois métodos possíveis:

1. NAT do roteador – Reescreva os pacotes de saída em um roteador intermediário (como o proxy NGINX Plus)
2. NAT de origem – Reescreva os pacotes de saída à medida que eles deixam cada servidor DNS upstream

Ambos os métodos usam o recurso de NAT sem estado que você configura com o comando tc. Se os servidores upstream estiverem conectados diretamente à Internet (ou seja, se a topologia fizer com que os pacotes de retorno não sejam enviados por um roteador intermediário que você possa controlar), será necessário selecionar o método de NAT de origem.

Configurando o NGINX Plus para DSR

Os pacotes de resposta não são entregues ao NGINX Plus, portanto, é necessário desabilitar a verificação de integridade configurada em Criação de um serviço de proxy reverso UDP padrão: modifique a diretiva proxy_responses e desabilite a diretiva proxy_timeout. Agora, o NGINX Plus não aguarda respostas nem conclui que o servidor upstream falhou quando não as recebe. Desabilitar essa verificação também permite que o NGINX Plus reutilize imediatamente os recursos de soquete.

Inclua também as variáveis $remote_addr e $remote_port no primeiro parâmetro da diretiva proxy_bind para que o NGINX Plus preserve o endereço e a porta de origem originais nos datagramas enviados aos servidores upstream:

# in the 'stream' context
server {
    listen 53 udp;

    proxy_bind $remote_addr:$remote_port transparent;
    proxy_responses 0;
    #proxy_timeout 1s;
}

NAT no roteador – Reescrevendo os pacotes de saída em um roteador intermediário

Você pode reescrever os pacotes de saída em um único roteador intermediário. Por exemplo, se os servidores upstream estiverem localizados em uma rede privada atrás do balanceador de carga NGINX Plus, você poderá usar o balanceador de carga como rota padrão e reescrever os pacotes à medida que forem encaminhados.

1. Configure cada servidor upstream para rotear todo o tráfego de saída pelo servidor NGINX Plus:

# route add default gw nginx-ip-address

1. Configure o servidor NGINX Plus para encaminhar o tráfego IP:

# sysctl -w net.ipv4.ip_forward=1

1. Configure o servidor NGINX Plus para realizar a reescrita de NAT sem estado:

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 action nat egress 172.16.0.12 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 action nat egress 172.16.0.13 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.14 match ip sport 53 action nat egress 172.16.0.14 192.168.99.10

1. Certifique-se de selecionar a interface de saída adequada e os endereços IP apropriados de cada servidor upstream.

Para obter mais informações sobre NAT sem estado, consulte a página de manual do tc nat man page. Dependendo da sua configuração, talvez seja possível reduzir os comandos tc filter a um único comando usando máscaras CIDR para os parâmetros src e egress old.

Para exibir a configuração atual de tc filter, execute este comando:

# tc filter show dev eth0

NAT de origem – Reescrevendo os pacotes de saída em cada servidor upstream

Se você puder configurar a rede nos servidores upstream, especialmente se eles estiverem conectados diretamente à Internet, poderá usar a configuração a seguir. Ela deve ser aplicada a cada servidor upstream.

Configure cada servidor upstream para realizar a reescrita de NAT sem estado:

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10

Certifique-se de selecionar a interface e os endereços IP apropriados em cada upstream.

Testando a configuração de DSR

Para testar a configuração, envie solicitações DNS ao balanceador de carga NGINX Plus e verifique se elas são distribuídas entre os servidores upstream.

O DSR não produz efeitos diretamente visíveis. Você pode ter certeza de que ele está funcionando se tiver usado a diretiva proxy_responses 0 para configurar o NGINX Plus de modo que ele não espere pacotes de resposta e, ainda assim, seus clientes DNS recebam respostas com balanceamento de carga. Você também pode observar o fluxo de pacotes usando o tcpdump, conforme descrito em Solução de problemas abaixo.

Resumo: como funciona a configuração de DSR?

• O NGINX Plus recebe um datagrama UDP de um cliente remoto (192.168.99.1:porta).
• O NGINX Plus toma uma decisão de balanceamento de carga, selecionando um servidor upstream (por exemplo, 172.16.0.11) no qual gravará o conteúdo do datagrama. Antes de se conectar, o NGINX Plus vincula o lado local do soquete upstream ao endereço IP e à porta do cliente remoto.
• O servidor upstream recebe o datagrama enviado pelo NGINX Plus, que aparentemente se origina diretamente do endereço e da porta do cliente remoto.
• O servidor upstream responde, enviando datagramas de volta ao cliente remoto. O servidor upstream define o endereço IP e a porta de origem dos datagramas de resposta como seu próprio endereço IP local e sua própria porta.
• O endereço IP de origem (e a porta, se necessário) é reescrito pelo servidor upstream (na configuração de NAT de origem) ou por um roteador intermediário (na configuração de NAT do roteador).
• O cliente remoto recebe os datagramas, endereçados com a 4-tupla correta (endereços IP e portas de origem e destino).
• O NGINX Plus não espera receber nenhum datagrama de resposta e fecha imediatamente o soquete upstream.

O resultado final é que os pacotes de resposta ignoram o processamento da Camada 7 no NGINX Plus e seguem diretamente para o cliente remoto.

Solução de problemas

Se a Transparência de IP ou o DSR não funcionar conforme o esperado, use as sugestões a seguir para investigar as possíveis causas:

Execute como root

Verifique se os processos de trabalho do NGINX Plus estão configurados para serem executados como root. Caso contrário, quando o NGINX Plus tentar vincular o soquete a um endereço não local, você verá no log de erros uma mensagem semelhante à seguinte:

setsockopt(IP_TRANSPARENT) failed (1: Operation not permitted) while connecting to upstream, client: 192.168.99.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.16.0.11:80/", host: "192.168.99.10"

Teste com ping

Verifique se é possível executar ping em clientes e servidores a partir do proxy NGINX Plus. Os servidores upstream não conseguem executar ping em endereços IP de clientes remotos, a menos que você primeiro crie a configuração de roteamento necessária e configure o NGINX Plus intermediário para encaminhar pacotes.

Nenhum intervalo de IP sobreposto

Certifique-se de que as sub-redes IP usadas pelos clientes remotos não estejam diretamente conectadas aos servidores upstream. Caso estejam, é provável que ocorram dois problemas:

• A proteção de “filtragem de caminho reverso” do Linux pode rejeitar silenciosamente pacotes do NGINX Plus porque o endereço IP de origem está associado a uma sub-rede em uma interface diferente.
• Os pacotes de retorno não usam a rota padrão; em vez disso, são enviados diretamente ao cliente remoto conectado localmente.

Use o tcpdump em todos os lugares

À medida que você configura e testa cada etapa intermediária, execute o tcpdump continuamente em todos os servidores para verificar se, em cada etapa, os pacotes estão sendo enviados aos endpoints corretos e recebidos por eles:

$ sudo tcpdump -i any -n tcp port 80

Investigue qualquer comportamento incomum usando as verificações listadas abaixo.

Verifique as tabelas de roteamento

Verifique cuidadosamente as tabelas de roteamento em cada servidor, prestando atenção especial aos servidores upstream:

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth2
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

Há alguma rota inesperada? Você pode confirmar se todos os pacotes do fluxo serão encaminhados ao destino correto? Lembre-se de que, nas configurações de iptables e NAT do roteador, todos os pacotes de saída devem ser encaminhados por meio do proxy intermediário NGINX Plus.

Pacotes ausentes

Se os pacotes forem descartados inesperadamente (tcpdump mostrar que eles são enviados por uma máquina, mas não recebidos por outra), a filtragem de caminho reverso pode ser a causa silenciosa. Para desativá-la temporariamente, execute o seguinte comando:

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f ; done

Permitindo que servidores upstream acessem servidores externos

Se os seus servidores upstream estiverem em uma rede privada e usarem o NGINX Plus (ou outro servidor) como gateway padrão, talvez seja conveniente configurar o gateway para permitir que os servidores upstream acessem hosts externos (na Internet).

Você precisa habilitar o encaminhamento de IP para que o gateway possa encaminhar pacotes dos servidores upstream; o encaminhamento de IP geralmente vem desabilitado por padrão. Se os servidores não tiverem endereços IP roteáveis (ou seja, usarem endereços privados, como 172.16.0.0/24), você também precisará configurar o mascaramento de IP nas interfaces externas do servidor de gateway:

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Verifique se é possível executar ping em um servidor externo a partir do seu servidor upstream interno:

root@dev1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=6.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=5.49 ms
^C

Para exibir suas configurações atuais de encaminhamento, roteamento e iptables nat, execute os três comandos a seguir:

# sysctl net.ipv4.ip_forward
# route -n
# iptables -t nat -L

Como obter assistência da NGINX

A configuração da Transparência de IP ou do Retorno Direto do Servidor é complexa, e outros dispositivos de rede intermediários podem afetar a implantação, descartando ou reescrevendo pacotes. Se precisar de ajuda, a equipe de Serviços Profissionais da NGINX está pronta para ajudar.

Explore você mesmo a Transparência de IP e o DSR com o NGINX Plus – comece hoje mesmo sua avaliação gratuita de 30 dias ou entre em contato conosco para discutir seus casos de uso.

Sobre o autor

Owen GarrettDiretor Sênior de Gestão de Produtos

Mais publicações de Owen Garrett