Após atualizar para
o último endereço de uso de todos os usuários passou a ser o gateway do Docker, como 172.17.0.1
Minha arquitetura é:
Cloudflare → Nginx no VPS → Nginx no Docker do Discourse → Discourse
Após atualizar para
o último endereço de uso de todos os usuários passou a ser o gateway do Docker, como 172.17.0.1
Minha arquitetura é:
Cloudflare → Nginx no VPS → Nginx no Docker do Discourse → Discourse
Tenho uma configuração semelhante à sua, aqui está o que adicionei à minha configuração do nginx do host para que ele passe o IP do usuário:
location / {
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;
real_ip_header X-Forwarded-For;
proxy_pass http://unix:/var/discourse/shared/standalone/nginx.http.sock:;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
olá @CLOUD_PHT - bem-vindo ao Meta ![]()
assumo que você está executando mais de um site na mesma configuração de máquina? (como um site WordPress + Discourse)
o problema é que você está roteando o tráfego através da rede interna do Docker (mapeamento de portas), o que mascara todas as solicitações de entrada como o IP do gateway do Docker (172.17.0.1). como o Nginx interno não reconhece 172.17.0.1 como um IP do Cloudflare, ele descarta o cabeçalho CF-Connecting-IP por segurança.
para corrigir isso, você precisa mudar sua configuração para usar um soquete Unix - isso permite que seu Nginx externo passe o tráfego (e os cabeçalhos) diretamente para o Discourse sem que a rede do Docker estrague os endereços IP.
siga este guia oficial e certifique-se de manter cloudflare.template.yml em seu arquivo app.yml ao reconstruir.
Esse commit corrigiu um erro de configuração no qual você estava dependendo, mas que também poderia permitir que qualquer usuário final falsificasse seu endereço IP definindo esse cabeçalho.
Na verdade, existe uma maneira mais fácil que não exige o uso de um soquete — acabei de escrever um guia sobre como fazer isso.
Para sua configuração @CLOUD_PHT, você deve adicionar isso à definição do seu container (se já existir uma seção run, adicione essas diretivas a ela; caso contrário, adicione a seção run):
run:
- file:
path: /etc/nginx/conf.d/outlets/server/real-ip-header.conf
chmod: 644
contents: |
real_ip_header x-forwarded-for;
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
Você talvez também precise do seguinte:
- file:
# precisamos ativar a recursividade, pois teremos pelo menos duas entradas: uma do host e outra do CloudFlare
path: /etc/nginx/conf.d/outlets/server/real-ip-recursive.conf
chmod: 644
contents: |
real_ip_recursive on;
dependendo se o nginx executado no seu servidor está processando o cabeçalho do Cloudflare para determinar o IP real do usuário final (o que é recomendado) ou apenas adicionando o seu próprio por cima. Consulte https://meta.discourse.org/t/handling-the-chain-of-trust-of-the-end-users-real-ip/406372#p-2001772-more-than-one-proxy-7 para mais detalhes.
Outros leitores: estejam cientes de que essa diretiva
run:
- file:
path: /etc/nginx/conf.d/outlets/server/set-real-ip-from-host.conf
chmod: 644
contents: |
set_real_ip_from 172.17.0.1;
não é apropriada para todas as configurações. Faça isso apenas se todas as conexões com o container Discourse a partir desse IP forem confiáveis.
Especificamente, um problema conhecido em configurações IPv6 é que as conexões IPv6 com o servidor são encaminhadas pelo Docker via IPv4 — a maneira como isso é feito faz com que todas as conexões pareçam vir do endereço IP docker0 do host. Se você aplicar a diretiva acima à sua configuração, permitirá que todos os usuários conectados via IPv6 falsifiquem seu endereço IP à vontade.