Avatar, loghi del sito ed errori di certificato

[markcichy (Mark)]

Ecco un link a una delle istanze:
https://discourse.mobiusnode.io

È disattivata. X-Forwarded-Proto è presente nel mio blocco del server. Quindi, l’unico elemento (o gli unici elementi) che non sto utilizzando, in base ai link che avete condiviso, è questo:

# modelli di base utilizzati; possono essere ridotti per includere meno funzionalità nei modelli dei container:
# - "templates/cron.template.yml" # cron è ora incluso nell'immagine di base
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # rimuovere - https sarà gestito da nginx esterno
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- Aggiunto
# quali porte esporre?
# expose: commenta l'intera sezione

[itsbhanusharma (Bhanu Sharma)]

Ho caricato il sito in 3 browser (Edge, Firefox e Chrome mobile) e ho ottenuto un certificato perfettamente valido come anonimo. Quali sono i tuoi passaggi per riprodurre questo problema?

[markcichy (Mark)]

Registrati come utente; una volta completata la registrazione e effettuato l’accesso, si scatena l’inferno e ricevo gli errori segnalati in precedenza.

[itsbhanusharma (Bhanu Sharma)]

Ok, mi iscriverò come utente finto tramite Firefox ora.

[itsbhanusharma (Bhanu Sharma)]

Le tue email non arrivano mai alla mia casella di posta. Ho provato a rispedirle senza successo. State attivando gli account manualmente?

[markcichy (Mark)]

No. Probabilmente sono finiti nella cartella Junk o Spam. Nessun reclamo da parte di alcun utente in merito.

[itsbhanusharma (Bhanu Sharma)]

Non è successo nulla di grave qui. Un possibile problema è che le tue email contengono ancora il link http://. Tuttavia, sono stato correttamente reindirizzato al sito HTTPS per attivare il mio account e non vedo errori relativi a SSL.

Quindi sì, sono sicuro al 99% che force_https non sia abilitato o che ci sia qualcosa di gravemente sbagliato nella tua installazione che sta causando questo problema.

[markcichy (Mark)]

Ho una reindirizzamento nel mio blocco server, quindi non importa quale link viene mostrato lì. Verrà sempre reindirizzato a https.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

non importa quale link viene mostrato lì

È proprio qui che ti sbagli. Se l’opzione “forza HTTPS” è abilitata, Discourse deve inviare tutti i link come HTTPS. Ogni singolo link relativo al forum deve essere caricato tramite HTTPS. Se continui a fare cose strane e non segui il metodo consigliato, sei da solo. Non possiamo andare oltre le procedure standard che funzionano.

[markcichy (Mark)]

Per me non ha molto senso. Se lo analizziamo logicamente, sto essenzialmente facendo esattamente ciò che è destinato a fare force-https, ma all’interno del blocco server.

[markcichy (Mark)]

Inoltre, quando attivo force-https, il mio sito si rompe e gli utenti non possono autenticarsi.

[itsbhanusharma (Bhanu Sharma)]

force_https non è semplicemente una riscrittura: internamente fa molto di più. Se vuoi che i tuoi problemi vengano risolti, è già stata fornita una soluzione. Se rifiuti la soluzione, sentiti libero di prendere in mano la situazione ed esplorare nuove strade.

@markcichy

Inoltre, quando attivo force-https, il mio sito si rompe e gli utenti non possono autenticarsi.

Questo è dovuto al tuo reverse proxy instabile. Dovrai scoprire cosa non va e agire nel modo corretto. Non possiamo fornire assistenza con le tue soluzioni personali.

[markcichy (Mark)]

Tutte le “soluzioni” presentate non si adattano al mio caso d’uso specifico:

• Server remoto (all’interno della stessa rete) – Credo che tutti gli esempi presuppongano che Nginx sia eseguito sullo stesso server di Discourse; io sto utilizzando proxy_pass per raggiungere un altro IP interno

Perché ho fatto questo? Maggiore sicurezza e distribuzione delle risorse. È la stessa ragione per cui ho suddiviso i servizi in due modi: tramite container e VM. La documentazione suggerita sembra favorire una condizione in cui tutti i servizi sono eseguiti sullo stesso server.

Immagino che le condizioni descritte sopra siano piuttosto comuni. Se qualcuna di esse può essere utilizzata per adattarsi a una condizione proxy_pass, sono più che disposto a modificare le mie impostazioni di conseguenza. Sento solo che fornire una generica affermazione del tipo “sei solo” perché sto cercando di evitare uno scenario del tipo “mettere tutte le uova nello stesso paniere” è un po’ ingiustificato.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

in Discourse, esponi 192.168.20.10:8080:80

rimuovi il template socketed.

abilita force_https

Fatto.

[markcichy (Mark)]

Questo comporta un sacco di implicazioni oltre a quanto hai appena scritto, che dovrò indagare—avremmo potuto iniziare da lì.

Domande immediate:

1. In app.yml cambiare la porta di ascolto predefinita in 8080?
2. Che dire di SSL 443? Mantenere la 443?
3. Rimuovere il reindirizzamento sulla porta 80 dal blocco del server Nginx?
4. Il punto #3 ha importanza se sto solo cambiando il proxy_pass lato interno? Probabilmente no? Sto solo reindirizzando alla 8080?
5. La domanda più importante: perché? Perché questo farebbe la differenza, passando dalla porta 80 alla 8080?
6. Mantenere attive tutte le altre Template? Commentare solo socketed?

Grazie per il tuo aiuto e la tua pazienza.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

In app.yml cambiare la porta di ascolto predefinita in 8080?

È una tua preferenza, l’ho scritta come esempio. Puoi anche scegliere di esporre la porta 80.

@markcichy

E per SSL 443? Lasciare 443?

Non c’è alcun vantaggio o senso nell’abilitare SSL su una rete locale.

@markcichy

Rimuovere il reindirizzamento sulla porta 80 dal blocco server di Nginx?

Questo deve esistere.

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

@markcichy

Il punto #3 è importante se sto solo cambiando proxy_pass sul lato interno? Probabilmente no? Sto solo reindirizzando verso la 8080?

È esattamente ciò che sta accadendo: stai inoltrando tutte le richieste ricevute dal tuo proxy/ingress a un backend interno sulla porta 8080 (ovvero Discourse).

@markcichy

La domanda più grande: perché? Perché dovrebbe fare una differenza cambiare da 80 a 8080?

Risposto al punto #1: era una preferenza personale, sentiti libero di utilizzare la porta che preferisci.

@markcichy

Mantenere attivi tutti gli altri template? Commentare solo socketed?

Non hai bisogno di nulla che riguardi socket o SSL sul server interno. SSL dovrebbe essere terminato correttamente sul reverse-proxy.

NB: la maggior parte di queste scelte è basata su preferenze personali legate alla distribuzione per i clienti.

[markcichy (Mark)]

Ok. Grazie per i commenti.

Ecco il mio blocco server Nginx, per tua informazione:

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

    server_name discourse.mobiusnode.io;

    location / {
            # traffico 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; # gestito da Certbot`
`ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # gestito da 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;
} # gestito da Certbot

listen 80;
listen [::]:80;

server_name discourse.mobiusnode.io;
return 404; # gestito da Certbot

}

[markcichy (Mark)]

Il comportamento che sto riscontrando si verifica nelle condizioni sopra indicate.

L’inizio di app.yml è il seguente:

## questo è il modello del contenitore Docker Discourse standalone all-in-one
##
## Dopo aver apportato modifiche a questo file, DEVI ricostruire
## /var/discourse/launcher rebuild app
##
## FAI *MOLTA* ATTENZIONE DURANTE LA MODIFICA!
## I FILE YAML SONO SUPER SUPER SENSIBILI A ERRORI NELLO SPAZIATURA O NELL'ALLINEAMENTO!
## visita http://www.yamllint.com/ per convalidare questo file quando necessario

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## Scommenta queste due righe se desideri aggiungere Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## quali porte TCP/IP deve esporre questo contenitore?
## Se vuoi che Discourse condivida una porta con un altro server web come Apache o nginx,
## consulta https://meta.discourse.org/t/17247 per i dettagli
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## Imposta db_shared_buffers a un massimo del 25% della memoria totale.
## verrà impostato automaticamente durante l'avvio in base alla RAM rilevata, oppure puoi sovrascriverlo
db_shared_buffers: "1024MB"

## può migliorare le prestazioni di ordinamento, ma aumenta l'utilizzo di memoria per connessione
#db_work_mem: "40MB"

## Quale revisione Git dovrebbe utilizzare questo contenitore? (predefinito: tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

Stai effettuando la connessione alla porta 80 sul secondo nginx, quindi pensa che tu ti stia connettendo a HTTP e non a HTTPS.

Prova a cercare X-Forwarded-Proto nell’nginx interno e modifica proxy_set_header X-Forwarded-Proto $thescheme; in proxy_set_header X-Forwarded-Proto https;

oppure inoltra il tuo traffico a HTTPS proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

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

Questa parte deve essere modificata