Avatares, logotipos de sitios y errores de certificados

[markcichy (Mark)]

Aquí hay un enlace a una de las instancias:
https://discourse.mobiusnode.io

Está apagado. X-Forwarded-Proto está en mi bloque de servidor. Por lo tanto, el único elemento (o elementos) que no estoy utilizando, según los enlaces que todos han compartido, es este:

# plantillas base utilizadas; se puede reducir para incluir menos funcionalidad por plantillas de contenedor:
# - "templates/cron.template.yml" # cron ahora está incluido en la imagen base
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # eliminar - https será manejado por nginx externo
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Agregado
# ¿qué puertos exponer?
# expose: comentar toda la sección

[itsbhanusharma (Bhanu Sharma)]

Cargué el sitio en 3 navegadores (Edge, Firefox y Chrome móvil) y obtuve un certificado perfectamente válido como anónimo. ¿Cuáles son tus pasos para reproducir esto?

[markcichy (Mark)]

Regístrate como usuario; una vez registrado y conectado, todo se descontrola y obtengo los errores mencionados anteriormente.

[itsbhanusharma (Bhanu Sharma)]

Ok, me registraré como un usuario falso a través de Firefox ahora mismo.

[itsbhanusharma (Bhanu Sharma)]

Tus correos electrónicos nunca llegan a mi bandeja de entrada. He intentado reenviarlos sin éxito. ¿Solo están activando cuentas manualmente aquí?

[markcichy (Mark)]

No. Probablemente fueron a la carpeta de Basura o Spam. No hay quejas de ningún usuario al respecto.

[itsbhanusharma (Bhanu Sharma)]

El infierno no se desató aquí. Un problema potencial es que tus correos electrónicos aún contienen el enlace http://. Sin embargo, fui redirigido correctamente al sitio https para activar mi cuenta y no veo ningún error relacionado con SSL aquí.

Así que sí, estoy 99% seguro de que tu force_https no está habilitado o hay algo muy muy mal con tu instalación que está causando esto.

[markcichy (Mark)]

Tengo una redirección en mi bloque de servidor, así que no importa qué enlace se muestre allí. Siempre se redirigirá a https.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

No importa qué enlace se muestre allí.

Eso es donde te equivocas. Si la opción forzar HTTPS está habilitada, Discourse debe enviar todos los enlaces como HTTPS. Cada enlace relacionado con el foro debe cargarse a través de HTTPS. Si sigues haciendo cosas extrañas y no lo haces de la manera sugerida, tendrás que arreglártelas solo. No podemos ayudar más allá de los procedimientos estándar que funcionan.

[markcichy (Mark)]

Eso no tiene mucho sentido para mí. Si lo desglosamos lógicamente, en esencia estoy haciendo exactamente lo que está destinado a hacer force-https, pero con el bloque del servidor.

[markcichy (Mark)]

Además, cuando activo force-https, mi sitio se rompe y los usuarios no pueden autenticarse.

[itsbhanusharma (Bhanu Sharma)]

force_https no es simplemente una reescritura; internamente hace más que eso. Si quieres que se resuelvan tus problemas, ya se ha proporcionado una solución. Si rechazas la solución, siéntete libre de tomar el asunto en tus propias manos y explorar nuevas vías.

@markcichy

Además, cuando activo force-https, mi sitio se rompe y los usuarios no pueden autenticarse.

Eso se debe a tu proxy inverso inestable. Tendrás que averiguar qué está mal y hacerlo de la manera correcta. No podemos brindar asistencia con tus propias soluciones.

[markcichy (Mark)]

Todas las “soluciones” que se han presentado no se ajustan a mi caso de uso específico:

• Servidor remoto (dentro de la misma red) – Creo que todos los ejemplos asumen que Nginx se ejecuta en el mismo servidor que Discourse; yo estoy utilizando proxy_pass para acceder a otra IP interna.

¿Por qué he hecho esto? Mayor seguridad y dispersión de recursos. Es la misma razón por la que separo los servicios de dos maneras: mediante contenedores y máquinas virtuales. La documentación sugerida parece favorecer un escenario donde todos los servicios se ejecutan en el mismo servidor.

Imagino que las condiciones descritas anteriormente son bastante comunes. Si alguna de ellas puede utilizarse para acomodar una condición de proxy_pass, estaré más que dispuesto a ajustar mis configuraciones en consecuencia. Solo siento que ofrecer una declaración general de “usted se las arregla solo” porque estoy tratando de evitar un escenario de “poner todos los huevos en la misma cesta” es un poco injustificado.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

en Discourse, exponer 192.168.20.10:8080:80

eliminar la plantilla enmascarada.

activar force_https

Éxito.

[markcichy (Mark)]

Esto tiene un montón de implicaciones más allá de lo que acabas de escribir, que tendré que investigar; podríamos haber empezado por ahí.

Preguntas inmediatas:

1. ¿En app.yml cambiar el puerto de escucha predeterminado a 8080?
2. ¿Qué pasa con SSL 443? ¿Dejar 443?
3. ¿Eliminar la redirección en el puerto 80 del bloque de servidor de Nginx?
4. ¿Importa el punto #3 si solo estoy cambiando el proxy_pass en el lado interno? ¿Probablemente no? ¿Solo estoy reencaminando al 8080?
5. La pregunta más importante: ¿por qué? ¿Por qué cambiar a 8080 desde 80 marcaría alguna diferencia?
6. ¿Mantener todas las demás plantillas activas? ¿Solo comentar socketed?

Gracias por tu ayuda y paciencia.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

¿En app.yml cambiar el puerto de escucha predeterminado a 8080?

Esa es tu preferencia; lo escribí como ejemplo. También puedes optar por exponer el puerto 80.

@markcichy

¿Qué hay de SSL en el puerto 443? ¿Dejar el 443?

No hay beneficio ni sentido en habilitar SSL en una red local.

@markcichy

¿Eliminar la redirección del puerto 80 en el bloque de servidor de Nginx?

Eso debe existir.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

¿Importa el punto #3 si solo estoy cambiando el proxy_pass en el lado interno? ¿Probablemente no? ¿Solo estoy reencaminando al puerto 8080?

Eso es exactamente lo que está ocurriendo: estás reenviando todas las solicitudes recibidas por tu proxy/ingress a un backend interno en el puerto 8080 (es decir, Discourse).

@markcichy

La gran pregunta: ¿por qué? ¿Por qué marcaría la diferencia cambiar de 80 a 8080?

Ya se respondió en el punto #1: fue una preferencia personal. Siéntete libre de usar el puerto que más te guste.

@markcichy

¿Mantener activadas todas las demás plantillas? ¿Solo comentar socketed?

Específicamente no necesitas nada relacionado con sockets o SSL en el servidor interno. SSL debe terminarse correctamente en el proxy inverso.

Nota: la mayor parte es una preferencia personal basada en la implementación para clientes.

[markcichy (Mark)]

Vale. Gracias por los comentarios.

Aquí está mi bloque de servidor Nginx, para tu información:

server {
# ssl
listen 443 ssl http2;
listen [::]:443 ssl http2;

    server_name discourse.mobiusnode.io;

    location / {
            # tráfico http
            proxy_pass http://192.168.86.108;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Host $http_host;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";

    }

`ssl on;`
`ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # gestionado por Certbot`
`ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # gestionado por Certbot`

`ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';`
`ssl_protocols TLSv1.2;`
`ssl_prefer_server_ciphers on;`
`ssl_session_cache shared:SSL:10m;`

`add_header Strict-Transport-Security "max-age=63072000;";`
`ssl_stapling on;`
`ssl_stapling_verify on;`

`client_max_body_size 0;`

}

server {
if ($host = discourse.mobiusnode.io) {
return 301 https://$host$request_uri;
} # gestionado por Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # gestionado por Certbot

}

[markcichy (Mark)]

El comportamiento que estoy experimentando ocurre bajo las condiciones mencionadas anteriormente.

El inicio de app.yml se ve así:

## este es la plantilla de contenedor Docker Discourse todo-en-uno, independiente
##
## Después de realizar cambios en este archivo, DEBES reconstruir
## /var/discourse/launcher rebuild app
##
## ¡TEN *MUCHO* CUIDADO AL EDITAR!
## ¡LOS ARCHIVOS YAML SON SUPER SENSIBLES A ERRORES EN ESPACIOS EN BLANCO O ALINEACIÓN!
## visita http://www.yamllint.com/ para validar este archivo según sea necesario

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Descomenta estas dos líneas si deseas agregar Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## ¿Qué puertos TCP/IP debe exponer este contenedor?
## Si deseas que Discourse comparta un puerto con otro servidor web como Apache o nginx,
## consulta https://meta.discourse.org/t/17247 para obtener detalles
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Establece db_shared_buffers en un máximo del 25% de la memoria total.
## se establecerá automáticamente durante el arranque según la RAM detectada, o puedes sobrescribirlo
db_shared_buffers: "1024MB"

## puede mejorar el rendimiento de ordenamiento, pero aumenta el uso de memoria por conexión
#db_work_mem: "40MB"

## ¿Qué revisión de Git debe usar este contenedor? (predeterminado: tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

Estás conectando al puerto 80 en el segundo nginx, por lo que este piensa que te estás conectando a http y no a https.

Busca X-Forwarded-Proto en el nginx interno y cambia proxy_set_header X-Forwarded-Proto $thescheme; por proxy_set_header X-Forwarded-Proto https;

o redirige tu tráfico a https proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

Esta parte necesita ser modificada