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

Esta postagem do blog descreve como configurar o NGINX Open Source e o NGINX Plus como um proxy transparente para tráfego para servidores upstream. Ele explica como você pode usar um proxy transparente para falsificar o endereço IP de origem dos pacotes para implementar a transparência de IP e como você pode implementar um modo de balanceamento de carga chamado Retorno Direto do Servidor para tráfego UDP.

As informações nesta postagem se aplicam tanto ao NGINX Open Source quanto ao NGINX Plus . Para resumir, nos referiremos apenas ao NGINX Plus.

Editor – Esta é a quinta de uma série de postagens de blog que exploram os novos recursos do NGINX Plus R10 em profundidade.

• Autenticação de clientes de API com JWT e NGINX Plus
• NGINX Plus R10 aproveita o IBM POWER
• Autenticação de usuários em aplicativos existentes com OpenID Connect e NGINX Plus
• Usando o módulo JavaScript NGINX para fazer a transição progressiva de clientes para um novo servidor
• Transparência de IP e retorno direto do servidor com NGINX e NGINX Plus como proxy transparente (este post)

Não deixe de conferir também o webinar sob demanda, O que há de novo no NGINX Plus R10?

Resumo

O NGINX Plus opera como um proxy reverso de Camada 7. Isso permite que o NGINX Plus aplique uma série de otimizações e melhorias às solicitações de rede que ele 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. Isto é um desafio se o servidor upstream precisa determinar o verdadeiro endereço IP de origem (do cliente remoto), por exemplo, para fins de autenticação ou registro.

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

• A transparência de IP garante que os servidores upstream observem que cada conexão se origina do cliente remoto que a iniciou. É aplicável aos protocolos baseados em TCP e UDP.
• O Direct Server Return (DSR) também organiza que as respostas dos servidores upstream vão diretamente para os clientes remotos e ignoram o balanceador de carga intermediário. É aplicável a protocolos baseados em UDP e pode ser implementado executando NAT (tradução de endereço de rede) no servidor de origem ou em um roteador intermediário.

É complexo implantar e solucionar problemas de transparência de IP e DSR. Implemente essas configurações somente se o modo de operação de proxy reverso padrão não for suficiente para seu aplicativo ou serviço.

Introdução: Fluxo de pacotes em um proxy reverso padrão da 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. Neste modo de operação, o NGINX Plus gerencia conexões TCP separadas do lado do cliente e do lado upstream (para tráfego HTTP e TCP) ou sessões UDP para controlar a comunicação entre o cliente remoto e o servidor upstream selecionado.

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

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

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

O modo de operação de proxy reverso da Camada 7 traz ganhos significativos de desempenho e eficiência para tráfego HTTP e TCP (incluindo otimizações de TCP, buffering e reutilização de keepalive de HTTP). Isso representa um desafio se o servidor upstream precisar determinar o verdadeiro endereço IP de origem da conexão ou sessão, para propósitos como autenticação e controle de acesso, limitação de taxa e registro.

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. Esta postagem descreve dois métodos adicionais, possibilitados pelo parâmetro transparente da diretiva proxy_bind , que foi introduzida no NGINX Plus Release 10 (R10)<.htmla>.

Método 1: Transparência de PI

A intenção da Transparência IP é ocultar a presença do proxy reverso para que o servidor de origem observe que os pacotes IP se originam do endereço IP do cliente. A transparência de IP pode ser usada com protocolos baseados em TCP e UDP.

Criando 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 de quatro servidores web que respondem com algumas informações de conexão simples.

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

   # no contexto 'http'
   servidor {
   escutar 80;
   
   localização / {
   senha_proxy http://http_upstreams;
   }
   }
   
   upstream http_upstreams {
   servidor 172.16.0.11;
   servidor 172.16.0.12;
   servidor 172.16.0.13;
   servidor 172.16.0.14;
   }
   

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

   # no contexto 'http'
   server {
   listen 80;
   
   location / {
   return 200 "Olá de $hostname. Você se conectou de $remote_addr:$remote_port para $server_addr:$server_port\n";
   }
   }
   

Quando testamos essa configuração, os upstreams relatam 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 Olá do dev1. Você se conectou de 172.16.0.1:42723 a 172.16.0.11:80 Olá do dev2. Você se conectou de 172.16.0.1:39117 a 172.16.0.12:80 Olá do dev3. Você se conectou de 172.16.0.1:54545 a 172.16.0.13:80 Olá do dev4. Você se conectou de 172.16.0.1:57020 a 172.16.0.14:80

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

O NGINX Plus R10 e posterior (e o NGINX Open Source 1.11.0 e posterior) podem falsificar o endereço de origem do tráfego upstream. Inclua o parâmetro transparente na diretiva proxy_bind . Mais comumente, você define o endereço de origem para o do cliente remoto:

proxy_bind $remote_addr transparente;

No entanto, essa etapa simples cria um desafio significativo, porque você precisa 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, e o NGINX Plus deve encerrar a conexão TCP upstream. O NGINX Plus então envia o tráfego de resposta para o 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 eles possam vincular 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 :

   # no contexto 'main'
   # 'user daemon' é o padrão; altere para 'user root' com proxy_bind transparente
   user root;
   

2. No balanceador de carga NGINX Plus , certifique-se de que cada conexão se origine do endereço do cliente remoto.

   Adicione a diretiva proxy_bind com o parâmetro transparent à configuração do servidor virtual:

   # no contexto 'http'
   servidor {
   escutar 80;
   
   localização / {
   proxy_bind $remote_addr transparente;
   proxy_pass http://http_upstreams;
   }
   }
   

3. 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 dos servidores representados pelo intervalo IP 172.16.0.0/28:

   # regra ip adicionar fwmark 1 pesquisa 100 # rota ip adicionar local 0.0.0.0/0 dev lo tabela 100 # iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff
   

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

   # iptables -t mangle -L Chain PREROUTING (política ACEITAR) destino prot opt origem MARCAR tcp -- 172.16.0.0/28 em qualquer lugar tcp spt:http MARCAR definir 0x1 Chain INPUT (política ACEITAR) destino prot opt origem Chain FORWARD (política ACEITAR) destino prot opt origem Chain OUTPUT (política ACEITAR) destino prot opt origem Chain POSTROUTING (política ACEITAR) destino prot opt origem
   

4. Nos servidores upstream , configure o roteamento para que todo o tráfego de retorno seja encaminhado para o NGINX Plus.

   Em cada servidor upstream, remova qualquer rota padrão pré-existente e configure a rota padrão para ser o endereço IP do balanceador de carga/proxy reverso NGINX Plus. Observe que este endereço IP deve estar na mesma sub-rede de uma das interfaces do servidor upstream.

   # rota del gw padrão 10.0.2.2 # rota adicionar gw padrão 172.16.0.1
   

   Verifique se a tabela de roteamento parece sensata:

   # route -n Tabela de roteamento de IP do kernel Gateway de destino Genmask Sinalizadores Métrica Ref Uso 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
   

   Se seus servidores upstream precisarem se conectar a servidores externos, você também precisará configurar o novo gateway NGINX Plus para encaminhar e mascarar o tráfego – veja Habilitando upstreams para alcançar 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 que você está enviando solicitações de um endereço IP remoto que não seja diretamente roteável dos servidores upstream:

$ for i in {1..4}; do curl http://192.168.99.10 ; done Olá do dev1. Você se conectou de 192.168.99.1:60729 a 172.16.0.11:80 Olá do dev2. Você se conectou de 192.168.99.1:43070 a 172.16.0.12:80 Olá do dev3. Você se conectou de 192.168.99.1:45749 a 172.16.0.13:80 Olá do dev4. Você se conectou de 192.168.99.1:46609 a 172.16.0.14:80

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

Se a configuração não funcionar, consulte 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) para se conectar. Antes que o NGINX Plus se conecte, ele vincula seu soquete 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 pacotes para o endereço do cliente remoto e roteando-os através do NGINX Plus (o roteador padrão).
• A regra iptables no balanceador de carga NGINX Plus marca esses pacotes e o roteamento os entrega localmente.
• O NGINX Plus lê a resposta.
• O NGINX Plus então envia a resposta ao cliente remoto.

O resultado líquido é que, da perspectiva dos servidores upstream, as conexões parecem se originar diretamente dos clientes remotos.

Método 2: Retorno direto do servidor

O Direct Server Return (DSR) é uma extensão do conceito de Transparência de IP. Na Transparência de IP, o servidor upstream recebe pacotes que parecem se originar do cliente remoto. Com o DSR, além disso, o servidor upsteam responde diretamente ao cliente remoto; os pacotes de retorno ignoram completamente o balanceador de carga.

O DSR pode oferecer um pequeno benefício de desempenho porque reduz a carga no balanceador de carga, mas traz uma série de limitações:

• O balanceador de carga nunca vê os pacotes de retorno, portanto, ele não pode detectar se o servidor upstream está respondendo ou falhou.
• O balanceador de carga não pode inspecionar uma solicitação além do primeiro pacote antes de selecionar um 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 do controlador de entrega de aplicativos (ADC) não são possíveis com o DSR, como cache, multiplexação HTTP e registro.

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

Os protocolos UDP são muito mais simples, sem 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, e isso pode oferecer benefícios de desempenho. Especificamente, DSR significa que o NGINX Plus não precisa manter soquetes UDP abertos na expectativa de um pacote de resposta (o que melhora a escalabilidade), e os pacotes de resposta podem ignorar completamente o processamento da Camada 7 do NGINX Plus (o que reduz a latência).

Como uma configuração DSR difere da transparência de IP?

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

• O NGINX Plus deve falsificar o endereço IP e a porta do cliente remoto ao enviar datagramas para servidores upstream (configuração de porta proxy_bind ).
• O NGINX Plus não deve ser configurado para esperar datagramas de resposta de servidores upstream (o proxy_responses0 diretiva).
• Uma etapa adicional é necessária para reescrever o endereço de origem dos datagramas de retorno para corresponder ao endereço público do balanceador de carga.

Além disso, o NGINX Plus deve ser configurado para executar verificações de integridade ativas nos servidores upstream. O NGINX Plus não pode confiar em suas verificações passivas usuais para verificar se um servidor está íntegro porque o NGINX Plus não observa os pacotes de resposta enviados pelo servidor.

Criando um serviço de proxy reverso UDP padrão

Para demonstrar o DSR, primeiro crie um cluster com balanceamento de carga de quatro servidores DNS que respondem com diferentes endereços IP para pesquisas do nome www.example.com .

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

# no contexto 'stream'
servidor {
escutar 53 udp;

proxy_responses 1;
proxy_timeout 1s;
proxy_pass dns_upstreams;
}

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

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

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

$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
2 ; Serial
604800 ; Atualizar
86400 ; Tentar novamente
2419200 ; Expirar
604800 ) ; TTL de cache negativo

example.com.    EM NS ns1.example.com.

ns1 EM A 172.16.0.11
www EM A 172.16.0.11

Os testes deixam claro que o NGINX Plus está balanceando a carga de solicitações entre os servidores DNS:

$ para i em {1..4} ; faça dig +short @192.168.99.10 www.example.com ; feito
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 posterior (e o NGINX Open Source 1.11.2 e posterior) podem falsificar o endereço de origem e a porta do tráfego upstream. Inclua o parâmetro transparente na diretiva proxy_bind :

proxy_bind $remote_addr:$remote_port transparente;

Isso permite que o servidor upstream observe o endereço IP de origem completo, para que ele possa construir 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 usando 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.

Dois métodos são possíveis:

1. Roteador NAT – 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 saem de cada servidor DNS upstream

Ambos os métodos usam o recurso NAT sem estado que você configura com o comando tc . Se os servidores upstream estiverem conectados diretamente à Internet (a topologia significa que os pacotes de retorno não são enviados por meio de um roteador intermediário que você pode controlar), você deverá selecionar o método NAT de origem .

Configurando o NGINX Plus para DSR

Os pacotes de resposta não são entregues ao NGINX Plus, então você precisa desabilitar a verificação de integridade configurada em Criando 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 espera por respostas e não conclui que o servidor upstream falhou quando não as recebe. Desabilitar essa verificação também permite que o NGINX Plus reutilize os recursos de soquete imediatamente.

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 de origem original e a porta de origem nos datagramas enviados aos servidores upstream:

# no contexto 'stream'
server {
listen 53 udp;

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

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

Você pode reescrever 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 uma rota padrão e reescrever os pacotes conforme eles são encaminhados.

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

   # rota adicionar gw padrão nginx-ip-address
   

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

   # sysctl -w net.ipv4.ip_forward=1
   

3. Configure o servidor NGINX Plus para executar a reescrita de NAT sem estado:

   # tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 corresponder ao ip src 172.16.0.11 corresponder ao ip sport 53 ação nat egress 172.16.0.11 192.168.99.10 # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 corresponder ao ip src 172.16.0.12 corresponder ao ip sport 53 ação nat egress 172.16.0.12 192.168.99.10 # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 corresponder ao ip src 172.16.0.13 corresponder ao ip sport 53 ação nat egress 172.16.0.13 192.168.99.10 # filtro tc adicionar dev eth0 pai 10: protocolo ip prio 10 u32 corresponder ip src 172.16.0.14 corresponder ip sport 53 ação nat egress 172.16.0.14 192.168.99.10
   

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

Para mais informações sobre NAT sem estado, consulte a página de manual do tc nat . Dependendo da sua configuração, você pode reduzir os comandos do filtro tc para um único comando usando máscaras CIDR para os parâmetros src e egress old .

Para exibir a configuração atual do filtro tc , execute este comando:

# filtro tc mostra dev eth0

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

Se você conseguir configurar a rede nos servidores upstream, especialmente se eles estiverem conectados diretamente à Internet, você pode usar a seguinte configuração. Deve ser aplicado a cada servidor upstream.

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

# tc qdisc add dev eth0 root handle 10: htb # tc filter add dev eth0 parent 10: protocolo ip prio 10 u32 corresponder ip src 172.16.0.11 corresponder ip sport 53 ação 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 do DSR

Para testar a configuração, envie solicitações de DNS ao balanceador de carga NGINX Plus e verifique se elas estão balanceadas nos servidores upstream.

O DSR não tem efeitos diretamente visíveis. Você pode ter certeza de que está funcionando se tiver usado o proxy_responses0 diretiva para configurar o NGINX Plus para não esperar pacotes de resposta, mas seus clientes DNS recebem respostas com balanceamento de carga. Você pode observar ainda mais o fluxo de pacotes usando tcpdump , conforme descrito em Solução de problemas abaixo.

RESUMO:Como funciona a configuração do 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) para gravar o conteúdo do datagrama. Antes de o NGINX Plus se conectar, ele 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 de origem e a porta dos datagramas de resposta para seu próprio endereço IP local e porta.
• O endereço IP de origem (e a porta, se necessário) é reescrito pelo servidor upstream (a configuração NAT de origem ) ou por um roteador intermediário (a configuração NAT do roteador ).
• O cliente remoto recebe os datagramas, endereçados com a tupla quádrupla correta (endereços IP de origem e destino e portas).
• O NGINX Plus não espera observar nenhum datagrama de resposta e fecha o soquete upstream imediatamente.

O resultado líquido é que os pacotes de resposta ignoram o processamento da Camada 7 no NGINX Plus e vão diretamente para o cliente remoto.

solucao-problemas

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

Executar como root

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

setsockopt(IP_TRANSPARENT) falhou (1: Operação não permitida) durante a conexão com o cliente upstream: 192.168.99.1, servidor: , solicitação: "GET / HTTP/1.1", upstream: "http://172.16.0.11:80/", host: "192.168.99.10"

Teste com ping

Verifique se você consegue executar ping em clientes e servidores do proxy NGINX Plus. Os servidores upstream não podem 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 intermediário NGINX Plus para encaminhar pacotes.

Sem intervalos de IP sobrepostos

Certifique-se de que as sub-redes IP usadas pelos clientes remotos não estejam conectadas diretamente aos servidores upstream. Se assim for, é provável que surjam 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 e, em vez disso, são enviados diretamente para o cliente remoto conectado localmente.

Use tcpdump em todos os lugares

À medida que você cria a configuração e testa cada etapa intermediária, execute o tcpdump continuamente em cada servidor para verificar se os pacotes estão sendo enviados e recebidos pelos pontos de extremidade corretos em cada estágio:

$ sudo tcpdump -i qualquer -n porta tcp 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 Tabela de roteamento de IP do kernel Gateway de destino Genmask Sinalizadores Métrica Ref Uso 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

Existem rotas inesperadas? Você pode confirmar se todos os pacotes no fluxo serão roteados para o destino correto? Lembre-se de que nas configurações iptables e Router NAT, todos os pacotes de saída devem ser roteados pelo proxy NGINX Plus intermediário.

Pacotes ausentes

Se os pacotes forem descartados inesperadamente ( o tcpdump mostra que eles foram enviados por uma máquina, mas não recebidos por outra), a filtragem de caminho reverso é um possível culpado silencioso. Para desabilitar temporariamente a filtragem de caminho reverso, execute o seguinte comando:

# para f em /proc/sys/net/ipv4/conf/*/rp_filter; faça eco 0 > $f ; feito

Habilitando servidores upstream para alcançar servidores externos

Se seus servidores upstream residirem em uma rede privada e usarem o NGINX Plus (ou outro servidor) como gateway padrão, talvez você queira configurar o gateway para permitir que os servidores upstream alcancem hosts externos (Internet).

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

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

Verifique se você pode 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 de dados.
64 bytes de 8.8.8.8: icmp_seq=1 ttl=61 tempo=6,72 ms 64 bytes de 8.8.8.8: icmp_seq=2 ttl=61 tempo=5,49 ms ^C

Para exibir sua configuração atual de encaminhamento, roteamento e nat do iptables , execute os três comandos a seguir:

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

Obtendo assistência do NGINX

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

Explore a transparência de IP e DSR com o NGINX Plus por si mesmo – comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .