Acabei de notar que os endereços IP de muitos membros do meu fórum estão sendo armazenados como 172.17.0.1. Não estou usando um proxy reverso ou qualquer outra coisa — não há nada entre você e o Docker do Discourse. Alguma ideia?
Você está usando o CloudFlare ou algo similar?
Apenas para DNS (modo cinza). (Tecnicamente, acho que tenho o modo laranja para www.intfiction.org, mas ele será redirecionado para o domínio principal intfiction.org antes de chegar ao meu servidor.) Tenho o seguinte no meu app.yml, embora não tenha pensado que nenhuma das partes fosse relevante:
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
server_name www.intfiction.org;
return 301 $scheme://intfiction.org$request_uri;
}
Isso não seria relevante apenas se houver um proxy na frente do meu servidor?
Eu também estou enfrentando esse problema, após migrar meu Discourse para um novo servidor e decidir NÃO usar o Cloudflare.
Reinstalei o Discourse do zero e depois restaurei meu backup.
Nunca re-adicionei a opção do template do Cloudflare no app.yml.
Tentei adicionar o código de outro tópico também:
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: "types {"
to: |
set_real_ip_from 10.0.0.0/24;
set_real_ip_from 172.17.0.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
types {
no app.yml, mas o problema persiste:
Todos os usuários IPv6 mostram seu último IP como 172.17.0.1.
Os endereços dos usuários IPv4 são exibidos perfeitamente.
Não há nenhum proxy reverso ou qualquer outra coisa em uso neste servidor — apenas a instalação padrão do Discourse conforme descrito na documentação, atendendo tráfego nas portas 80/443.
Acho que sei por que isso está acontecendo.
Para IPv4, o Docker insere regras de firewall no iptables para realizar o reverse NAT do endereço/porta exposto do host para o endereço/porta do host do contêiner. Isso permite que o contêiner veja o endereço de origem original.
Para IPv6, o Docker usa um proxy no espaço de usuário (docker-proxy) que apenas encaminha de uma porta para outra. Isso faz com que o contêiner veja o endereço de origem como localhost. Como não se trata de um proxy sensível a HTTP, mas apenas de encaminhamento de portas, ele não consegue inserir cabeçalhos X-Forwarded-For.
O projeto principal do Docker ainda não adicionou suporte para realizar NAT em IPv6, seja porque consideram o NAT em IPv6 indesejável ou simplesmente porque ainda não tiveram tempo de implementá-lo.
No entanto, é possível corrigir isso ativando o IPv6 no Docker e, em seguida, executando um contêiner que insere automaticamente as regras corretas de NAT para IPv6.
Veja https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2 para um guia sobre como configurar isso.
TLDR: Certifique-se de que o IPv6 funcione em seus contêineres e, em seguida, execute GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub
Isso é algo que precisa ser alterado dentro do app/container Docker, externamente ou ambos? Imagino que ambos… mas isso parece ser uma tarefa de administração de alto nível. Se confirmado, um guia fácil de seguir sobre como habilitar o Discourse (Docker) para IPv6 seria muito apreciado.
Vou tentar implementar isso no meu site mais tarde e tentar documentar meus passos. De jeito nenhum sou um especialista em Docker, mas acho que não deve ser muito difícil.
Infelizmente, isso tem sido mais complicado do que o esperado devido ao meu conhecimento limitado sobre Docker. Atualmente, estou experimentando apenas fazer o proxy do Discourse através do nginx rodando na casa para contornar essa limitação. Se tudo mais falhar, voltarei a usar o Cloudflare, mas prefiro não depender deles para um site funcional.
Uma nota rápida para quem estiver interessado: Colocar o Discourse atrás do nginx é a solução mais fácil para esse problema. Use o link nos comentários do arquivo app.yml padrão para configurar o Discourse em um socket. Uma vantagem adicional para mim foi a capacidade de configurar uma página de erro personalizada para aparecer durante as reconstruções.