yo @Falco, ¿la real_ip (proporcionada por cf como encabezado CF-Connecting-IP) te llega en los logs de nginx? a mí no. solo veo la IP de cloudflared.
creo que hay que hacer una o ambas de estas cosas (haré seguimiento después de investigar):
añadir una línea de configuración set_real_ip_from a nginx para la IP de cloudflared. si ese resulta ser el problema, entonces supongo que ninguna de las otras líneas set_real_ip_from (proporcionadas por templates/cloudflare.template.yml) son necesarias para los usuarios de argotunnel. y en este caso, tal vez se debería añadir una plantilla separada de argotunnel al repositorio de docker que obtenga tu IP de cloudflared de una variable de entorno o algo en tu app.yml principal.
corregir el log_format. creo que esto probablemente no sea el problema, sin embargo. confirmado que no es necesario
editar:
esto es lo que estoy haciendo para que funcione:
no uses la plantilla de cloudflare. no tiene sentido.
en su lugar, fusiona esto en tu app.yml:
hooks:
after_web_config:
- file:
path: /etc/nginx/conf.d/cloudflare_tunnel_real_ip.conf
contents: |
# restaurar IPs originales de visitantes (ngx_http_realip_module)
set_real_ip_from 10.100.20.200/32; # tu rango de IP de cloudflared/argotunnel
real_ip_header CF-Connecting-IP;
eso termina automáticamente en el contexto http de nginx, por cierto, lo cual es apropiado.
pd: en mi opinión, para mayor limpieza, la plantilla de cloudflare también debería generar su configuración de nginx en un archivo separado en lugar de usar sed -i para añadirla a /etc/nginx/conf.d/discourse.conf.
sí @shyguy sigo los pasos Sr. @Falco
sí, estoy en el túnel, antes tenía protección contra ataques ddos de cloudflare, los ataques ddos hacían que mi servidor tuviera un alto uso de CPU, en el registro de acceso 20mb y solo veía mi IP de docker, desafié al visitante en la ruta de URL / para proteger el servidor pero la caché caducada dio un error de descortés
por si no quedó claro, mi publicación allí era solo sobre cómo arreglar el registro de nginx.
si no lo arreglas, todas las solicitudes en tus registros de nginx parecerán provenir de una IP (tu cloudflared) en lugar de tener las IPs reales del cliente.
esa IP (o rango de IP) es desde la que tu cloudflared se conecta a discourse, así que depende de tu configuración. una forma de estar seguro es mirar en el archivo de registro de nginx y obtener la IP de allí. y luego agregar un /32 después.
si sigues su guía exactamente, supongo que será 127.0.0.1/32
nah, esa fue solo una sugerencia para la plantilla cloudflare.template.yml, que no deberías usar en esta configuración.
simplemente sigue su guía en la primera publicación, pero ignora el paso de agregar esa plantilla a tu configuración. en lugar de eso, agrega el hook que proporcioné.
vaya. eso me parece correcto, así que no estoy seguro de qué está mal.
así es como se supone que debe funcionar:
el proxy de cloudflare agrega una cabecera CF-Connecting-IP que contiene la IP del cliente
nginx en discourse ha sido compilado con ngx_http_realip_module, un software que lee esta cabecera y corrige los registros, etc., para mostrar la IP real del cliente
set_real_ip_from habilita esta función para conexiones de rangos de IP que se le pasan. normalmente serían los rangos de IP de cloudflare (suministrados por la plantilla de conveniencia cloudflare.template.yml), pero dado que estás usando argotunnel, simplemente usarías la IP de argotunnel en su lugar.
intenta deshabilitar mi hook. ¿ves la misma IP en tus registros de nginx antes/después?
probablemente la única diferencia en nuestras configuraciones es que estoy ejecutando argotunnel (cloudflared) en docker.
si quieres probar eso…
creé una red solo para cloudflared:
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
command: tunnel run
restart: unless-stopped
networks:
wan:
cf_tunnel:
# para ngx_http_realip_module
# establecido en una IP alta para que, con suerte, docker no asigne por DHCP
# otra contenedor esa IP si se inicia antes que cloudflared
ipv4_address: 10.200.10.200 # esta es la IP para `set_real_ip_from` en nginx
volumes:
# debe ser propiedad de uid:gid 65532:65532
- ./conf:/home/nonroot/.cloudflared
networks:
cf_tunnel:
external: true # solo significa una red no administrada por compose
# para rendimiento:
# https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size
# sudo nano /etc/sysctl.conf
# agrega esta línea:
# net.core.rmem_max=2500000
# (mi valor anterior era 212992 – compruébalo con: sudo sysctl net.core.rmem_max)
puedes transferir tu configuración/certificado a él en ese directorio conf (recuerda chown como dice la nota en el archivo compose) o simplemente volver a pasar por el procedimiento de configuración. puedes ejecutar comandos de cloudflared para iniciar sesión o lo que sea así:
docker run -it --rm -v /ruta/a/conf:/home/nonroot/.cloudflared cloudflare/cloudflared:latest TU_COMANDO_AQUI
y luego tienes que unir tu contenedor de discourse a la red. puedes hacerlo con esto al final de tu archivo yml de contenedor:
docker_args:
- '--network=cf_tunnel' # opcionalmente, también podrías establecer una IP estática aquí
¿Alguien ha tenido éxito al hacer que el contenedor del servidor de correo entrante de Discourse funcione a través del túnel Cloudflare?
He tenido problemas para configurar otro servidor de correo detrás del túnel Cloudflare en el pasado, pero puedo hacer que las aplicaciones que se ejecutan en mi Pi y que utilizan los puertos 80 y 443 funcionen bien.
He configurado Discourse en servidores varias veces y no estoy demasiado preocupado por el contenedor principal de Discourse por ahora.
Creo que esto está relacionado, pero por favor cree una nueva publicación a partir de mi respuesta si considera que está fuera de tema.
Utilicé el servicio de argo. Me di por vencido cuando pagué 28 euros por el primer mes. En realidad, hubo una diferencia de al menos 200 ms. Sin embargo, lo cancelé porque no podía permitirme pagar 28 euros cada mes por 200 ms. Los sitios más grandes tendrán más facturas, tenedlo en cuenta.
El sitio tiene entre 800 y 1000 usuarios únicos. Puedes calcular en consecuencia.
Además, desde que empecé a usar tunnel, subir archivos multimedia ha sido una molestia o casi imposible
Las subidas van bien y luego me sale este error
Esa es la cuestión, lol, es de 64 bits. Pero lo he resuelto. Hice apt get upgrade y reinicié el servicio de Cloudflare y se subió. Además, ¿sabes si Cloudflare limita la carga de vídeos con tunnel? Estoy teniendo problemas para subir un vídeo de unos 20 MB y antes no los tenía.
Sin embargo, el error de que Discourse no puede alcanzar el dominio siempre aparece durante la instalación.
He escrito DISCOURSE_FORCE_HTTPS: true en el App.yml.
Sin embargo, no cancelé la instalación, sino que se canceló automáticamente antes de que pudiera cambiar el App.yml. ¿Podría ser este el error?
