Acabo de notar que las direcciones IP de muchos miembros de mi foro se están guardando como 172.17.0.1. No estoy ejecutando un proxy inverso ni nada por el estilo; no hay nada entre tú y el Docker de Discourse. ¿Alguna idea?
¿Estás usando CloudFlare o algo similar?
Solo para DNS (modo gris). (Técnicamente, creo que tengo el modo naranja para www.intfiction.org, pero será redirigido al dominio raíz intfiction.org antes de llegar a mi servidor.) Tengo lo siguiente en mi app.yml, aunque no pensé que ninguna de las dos partes fuera 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;
}
¿No solo será relevante si hay un proxy delante de mi servidor?
Yo también estoy experimentando este problema después de migrar mi Discourse a un nuevo servidor y decidir NO usar Cloudflare.
Reinstalé Discourse desde cero y luego restauré mi copia de seguridad.
Nunca volví a agregar la opción de plantilla de Cloudflare en app.yml.
También intenté agregar el código de otro hilo:
- 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 {
en app.yml, pero el problema persiste:
Todos los usuarios de IPv6 muestran su última IP como 172.17.0.1.
Las direcciones de los usuarios de IPv4 se muestran correctamente.
No hay ningún proxy inverso ni nada similar en uso en este servidor; solo la instalación estándar de Discourse tal como se describe en la documentación, sirviendo tráfico en los puertos 80/443.
Creo que sé por qué está sucediendo esto.
Para IPv4, Docker inserta reglas de firewall en iptables para realizar NAT inverso desde la dirección/puerto expuesta del host hacia la dirección/puerto del contenedor. Esto permite que el contenedor vea la dirección de origen original.
Para IPv6, Docker utiliza un proxy de espacio de usuario (docker-proxy) que simplemente reenvía desde un puerto a otro. Esto hace que el contenedor vea la dirección de origen como localhost. Este no es un proxy consciente de HTTP; es solo reenvío de puertos, por lo que no puede insertar encabezados X-Forwarded-For.
El proyecto principal de Docker no ha añadido soporte para realizar NAT en IPv6, ya sea porque consideran que el NAT de IPv6 es problemático o porque aún no han tenido tiempo de implementarlo.
Sin embargo, puedes solucionar esto habilitando IPv6 para Docker y luego ejecutando un contenedor que inserte automáticamente las reglas correctas de NAT para IPv6.
Consulta https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2 para una guía sobre cómo configurarlo.
TLDR: Asegúrate de que IPv6 funcione en tus contenedores y luego ejecuta GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub
¿Es esto algo que debe cambiarse dentro de la aplicación/contenedor Docker, externamente o en ambos? Asumo que en ambos… pero esto suena como tareas administrativas de alto nivel. Si se confirma, sería muy agradecido contar con una guía fácil de seguir sobre cómo habilitar Discourse (Docker) para IPv6.
Lo intentaré implementar en mi sitio más tarde y trataré de documentar mis pasos. En absoluto soy un experto en Docker, pero creo que no debería ser demasiado difícil.
Lamentablemente, esto ha sido más complicado de lo esperado debido a mi conocimiento limitado de Docker. Actualmente estoy experimentando con solo hacer proxy de Discourse a través de nginx ejecutándose en casa para sortear esta limitación. Si todo lo demás falla, volveré a usar Cloudflare, pero preferiría no depender de ellos para un sitio funcional.
Una nota rápida para cualquier interesado: Poner Discourse detrás de nginx es la solución más sencilla a este problema. Usa el enlace en los comentarios predeterminados de app.yml para configurar Discourse en un socket. Para mí, el beneficio adicional ha sido la capacidad de configurar una página de error personalizada que aparezca durante las reconstrucciones.