Nginx set_real_ip_from endereço do balanceador de carga do AWS ELB

Eu tenho um conjunto de servidores Nginx atrás de um balanceador de carga Amazon ELB. Estou usando set_real_ip (do HttpRealIpModule ) para poder acessar o endereço IP do cliente de origem nesses servidores (para passar para php-fpm e para uso no HttpGeoIPModule ).

Parece que set_real_ip_fromna configuração do nginx pode aceitar apenas um endereço IP. No entanto, no que diz respeito às máquinas ELB, a Amazon diz:

Nota: Como o conjunto de endereços IP associados a um LoadBalancer pode mudar com o tempo, você nunca deve criar um registro "A" com qualquer endereço IP específico. Se você deseja usar um nome DNS amigável para o LoadBalancer em vez do nome gerado pelo serviço Elastic Load Balancing, crie um registro CNAME para o nome DNS do LoadBalancer ou use o Amazon Route 53 para criar uma zona hospedada. Para obter mais informações, consulte Usando nomes de domínio com o balanceamento de carga elástico.

Mas se eu precisar inserir um endereço IP, não posso usar um CNAME (da Amazon ou do meu). Existe uma solução para este problema?

Se você pode garantir que todos os pedidos serão provenientes do ELB (não estou familiarizado com ele), tente:

real_ip_header X-Forwarded-For;
set_real_ip_from 0.0.0.0/0;

Isso deve dizer ao nginx para confiar em qualquer cabeçalho X-Forwarded-For. A desvantagem é que, se alguém acessar diretamente o servidor, poderá falsificar um cabeçalho X-Forwarded-For e o nginx usará o endereço IP do cliente errado.

A melhor prática de hoje é usar a VPC, para que você saiba o CIDR exato do seu ELB. Em seguida, você pode adicionar algo assim ao seu arquivo de configuração do Nginx:

real_ip_header X-Forwarded-For;
set_real_ip_from 10.0.0.0/8;

Use o CIDR da VPC para set_real_ip_fromVocê pode encontrá-lo no console da Amazon em VPC => Seu VPC (substitua <your VPC CIDR here>por ele):

real_ip_header X-Forwarded-For;
set_real_ip_from <your VPC CIDR here>;

Definir o intervalo confiável como 0.0.0.0/0 no Amazon ELB certamente causará problemas. Você pode garantir que as solicitações venham do ELB se você puder configurar o grupo de segurança para o servidor nginx, mas a solicitação original será originada de qualquer origem possível (Amazon ELBs são interfaces públicas).

Um teste simples irá revelar isso:

curl --header "X-Forwarded-For: 1.2.3.4" "http://your-elb-dns-address/"

Os logs no seu servidor nginx mostrarão 1.2.3.4 como o IP real, que é falso. Consulte Intervalo de IPs para obter o IP privado interno do Amazon ELB para obter melhores respostas.

O realip_module afirma que, no caso do X-Forwarded-For, este módulo usa o último endereço IP no cabeçalho X-Forwarded-For para substituição. Este módulo não funcionará quando apenas real_ip_headere set_real_ip_formestão definidos. Isso ocorre porque este módulo usará um endereço IP de proxy em vez de um IP de cliente. Para resolver esta real_ip_recursivediretiva deve estar habilitado.

Além disso, se você tiver certificados SSL que são implementados e renovados na instância (como digamos letsencrypt ou certificados certbot). Essas autoridades de certificação podem tentar validar esses certificados via IPV6.

Portanto, é importante também ter IPV6. Portanto, o arquivo de configuração do Nginx também deve conter o endereço IP_6 set_real_ip.

real_ip_header X-Forwarded-For;
real_ip_recursive on;
set_real_ip_from <your VPC IPV4 CIDR here>;
set_real_ip_from <your VPC IPV6 CIDR here>;

se aplicar restrições de segurança adicionais, também podemos precisar incluir o set_real_ip_fromVPC CIDR (IPV4 e IPV6) para sub-redes cloudfront / elb / ec2.