Abbiamo un’installazione di Discourse in uso da diversi anni, attualmente aggiornata all’ultima versione (2.4.0beta2) tramite l’immagine Docker più recente. Il server è raggiungibile tramite un indirizzo IP pubblico, senza proxy o altri intermediari, e utilizza certificati LetsEncrypt.
A volte l’indirizzo IP di registrazione e l’ultimo IP degli utenti vengono rilevati correttamente, altre volte no. Non sembra esserci una logica precisa. Ad esempio, ecco un utente creato 7 ore fa con indirizzi privi di senso:
E così via: per alcuni utenti funziona, per altri no. Avete qualche idea su cosa possa star succedendo?
Ora che ci penso, mi viene in mente che potrebbe trattarsi di utenti che si collegano tramite IPv6, dato che non ho mai visto indirizzi IPv6 in questi campi. Discourse non supporta IPv6? Il proxy Docker non è in grado di interpretare o inoltrare le informazioni pertinenti? O c’è qualcos’altro?
Discourse lo supporta senz’altro, ma dovrai configurare il tuo server e qualsiasi altro componente posto davanti ad esso affinché IPv6 funzioni correttamente, ecc.
IPv6 è molto funzionale e si utilizzano le immagini Docker consigliate configurate con i modelli web e dati. Non c’è nulla di fronte. Cosa dovremmo modificare?
Tieni presente che il nostro file yml dei container esiste da alcuni anni, sebbene includa gli ultimi modelli e le immagini stesse vengano ricostruite frequentemente. È qualcosa che potrebbe essere cambiato nel frattempo?
È difficile dirlo. Ho appena verificato gli ultimi 8 nuovi utenti registrati su talk.commonmark.org, che è un’installazione standard predefinita, e tutti avevano indirizzi IPv4 validi per l’ultimo IP e l’IP di registrazione (a volte i due differivano, come pure).
So che se gli account utente arrivano tramite SSO o altre vie insolite, ciò può influenzare gli IP riportati lì. Tutti questi utenti a cui ti riferisci sono registrazioni normali tramite la finestra di dialogo standard per la registrazione di nuovi utenti in Discourse?
Allora sono certo che non presenterà il problema di mostrare localhost invece degli indirizzi IPv6 per gli utenti che si connettono tramite IPv6. Questo non significa che il problema non esista.
Il problema non esiste nell’hosting ufficiale di Discourse, almeno non su quello, ed è abilitato per IPv6. Non vedo nemmeno problemi su un’installazione standard presso un host di co-locazione a caso. Non so cosa altro dirti, se non che non hai risposto alla mia domanda piuttosto importante.
Non metto in dubbio che funzioni nel tuo hosting, ma non utilizzi l’impostazione Docker “standard” usata dalla maggior parte degli utenti, vero? Voglio dire, sono sicuro che sia possibile farlo funzionare dato un proxy che imposti le intestazioni corrette, ecc., la domanda è solo se l’impostazione predefinita lo faccia e, in caso contrario, se possiamo far sì che lo faccia.
Sono abbastanza sicuro che tu debba aggiungere una riga al tuo app.yml per indicare a nginx di riconoscere il tuo indirizzo IPv6 e inoltrare l’indirizzo del client. Non sono ancora riuscito a capire come farlo io stesso. I topic relativi all’esecuzione di un reverse proxy includono esempi IPv6 che forniscono degli indizi.
Questo è nella mia lista di cose da risolvere, ma ho una lista piuttosto lunga. Alla fine ho disabilitato IPv6, probabilmente a causa di questo problema, ma forse anche per qualche altra mia ignoranza su IPv6.
(Jeff, puoi ottenere un blocco IPv6 instradato, ma devi richiederlo e poi configurare i tuoi host per utilizzarlo.)
Penso che il reverse proxy esterno sia la chiave: non credo che sia risolvibile, o almeno non facilmente, solo all’interno del container Docker.
L’ho risolto ora facendo in modo che Discourse Docker ascolti su una socket Unix e ponendo davanti Caddy sulla stessa macchina (fuori da Docker). La configurazione di Caddy è banale, include Let’s Encrypt e ora funziona come previsto anche per IPv6.