yo @Falco, o real_ip (fornecido pelo cf como cabeçalho CF-Connecting-IP) está chegando para você nos logs do nginx? não está para mim. eu só vejo o ip do cloudflared.
eu acho que uma ou ambas as coisas precisam ser feitas (vou acompanhar após a investigação):
adicionar uma linha de configuração set_real_ip_from ao nginx para o ip do cloudflared. se esse for o problema, então eu acho que nenhuma das outras linhas set_real_ip_from (fornecidas por templates/cloudflare.template.yml) são necessárias para usuários do argotunnel. e neste caso, talvez um template separado do argotunnel deva ser adicionado ao repositório docker que puxa o seu ip do cloudflared de uma variável de ambiente ou algo assim no seu app.yml principal.
corrigir o log_format. eu acho que isso provavelmente não é o problema, embora. confirmado desnecessário
edit:
aqui está o que estou fazendo para fazer funcionar:
não use o template do cloudflare. não tem sentido.
em vez disso, mescle isso no seu app.yml:
hooks:
after_web_config:
- file:
path: /etc/nginx/conf.d/cloudflare_tunnel_real_ip.conf
contents: |
# restaurar ips originais do visitante (ngx_http_realip_module)
set_real_ip_from 10.100.20.200/32; # seu range de ip do cloudflared/argotunnel
real_ip_header CF-Connecting-IP;
isso automaticamente acaba no contexto http do nginx, o que é apropriado.
ps: na minha opinião, para limpeza, o template do cloudflare também deveria gerar sua configuração nginx em um arquivo separado em vez de usar sed -i para adicioná-la a /etc/nginx/conf.d/discourse.conf.
Sim @shyguy, eu sigo os passos, Sr. @Falco.
Sim, estou no túnel. Antes, eu recebia alguma proteção contra DDoS da Cloudflare. O DDoS fazia meu servidor ficar sobrecarregado de CPU, com 20 MB no log de acesso e eu via apenas o meu IP do Docker. Eu desafio o visitante no caminho da URL / para proteger o servidor, mas o cache expirado deu erro de descontinuidade.
para que ficasse claro, meu post lá era apenas sobre como corrigir o registro do nginx.
se você não corrigir, todas as solicitações em seus logs do nginx parecerão vir de um IP (seu cloudflared) em vez de ter os IPs reais do cliente.
esse IP (ou intervalo de IPs) é de onde seu cloudflared está se conectando ao discourse, então depende da sua configuração. uma maneira de ter certeza é olhar no arquivo de log do nginx e pegar o IP de lá. e então adicionar um /32 depois.
se você estiver seguindo o guia dele exatamente, eu diria que é 127.0.0.1/32
nah, essa foi apenas uma sugestão para o template cloudflare.template.yml – que você não deveria estar usando nesta configuração.
apenas siga o guia dele na primeira postagem, mas ignore a etapa de adicionar esse template à sua configuração. em vez disso, adicione o hook que eu forneci.
que pena. isso me parece correto, então não tenho certeza do que está errado.
é assim que isso deve funcionar:
o proxy do cloudflare adiciona um cabeçalho CF-Connecting-IP contendo o IP do cliente
o nginx no discourse foi compilado com ngx_http_realip_module – um software que lê este cabeçalho e corrige logs, etc., para mostrar o IP real do cliente
set_real_ip_from habilita este recurso para conexões de intervalos de IP passados a ele. normalmente seriam os intervalos de IP do cloudflare (fornecidos pelo template de conveniência cloudflare.template.yml), mas como você está usando o argotunnel, você usaria apenas o IP do argotunnel.
tente desabilitar meu hook. você vê o mesmo IP em seus logs do nginx antes/depois?
provavelmente a única diferença em nossas configurações é que estou executando o argotunnel (cloudflared) no docker.
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
command: tunnel run
restart: unless-stopped
networks:
wan:
cf_tunnel:
# para ngx_http_realip_module
# definido para um IP alto para que, esperançosamente, o docker não atribua via DHCP
# outro contêiner com esse IP se ele iniciar antes do cloudflared
ipv4_address: 10.200.10.200 # este é o ip para `set_real_ip_from` no nginx
volumes:
# deve ser de propriedade de uid:gid 65532:65532
- ./conf:/home/nonroot/.cloudflared
networks:
cf_tunnel:
external: true # apenas significa uma rede não gerenciada pelo compose
# para desempenho:
# https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size
# sudo nano /etc/sysctl.conf
# adicione esta linha:
# net.core.rmem_max=2500000
# (meu valor antigo era 212992 – verifique com: sudo sysctl net.core.rmem_max)
você pode transferir sua configuração/certificado para ele nesse diretório conf (lembre-se de chown como a nota no arquivo compose diz) ou apenas passar pelo procedimento de configuração novamente. você pode executar comandos cloudflared para fazer login ou o que quiser assim:
docker run -it --rm -v /path/to/conf:/home/nonroot/.cloudflared cloudflare/cloudflared:latest YOUR_CMD_HERE
e então você tem que juntar seu contêiner discourse à rede. você pode fazer isso com isto na parte inferior do seu yml de contêiner:
docker_args:
- '--network=cf_tunnel' # opcionalmente, você também pode definir um IP estático aqui
Alguém obteve sucesso em fazer o container do servidor de e-mail de entrada do Discourse funcionar através do túnel Cloudflare?
Tive problemas para configurar outro servidor de e-mail atrás do túnel Cloudflare no passado, mas consigo fazer com que aplicativos na minha Pi que usam as portas 80 e 443 funcionem bem.
Já configurei o Discourse em servidores várias vezes e não estou muito preocupado com o container principal do Discourse por enquanto.
Acho que isso está relacionado, mas por favor, crie um novo post a partir da minha resposta se achar que está fora do tópico.
Usei o serviço argo. Desisti quando paguei 28 euros pelo primeiro mês. Na verdade, houve uma diferença de pelo menos 200 ms. No entanto, cancelei porque não podia pagar 28 euros todos os meses por 200 ms. Sites maiores terão mais faturas, tenha em mente.
O site tem 800-1000 usuários únicos. Você pode calcular de acordo.
É essa a questão kkkk é 64 bits. Mas eu descobri. Eu fiz apt get upgrade e reiniciei o serviço do Cloudflare e ele foi carregado. Você também sabe se o Cloudflare limita o upload de vídeos com túnel? Estou tendo problemas para fazer upload de um vídeo de tipo 20 MB e antes eu não tinha.
No entanto, o erro de que o Discourse não consegue alcançar o domínio sempre aparece durante a instalação.
Escrevi DISCOURSE_FORCE_HTTPS: true no App.yml.
No entanto, não cancelei a instalação, mas ela foi cancelada automaticamente antes que eu pudesse alterar o App.yml. Isso pode ser o erro?
