Utilizzare Discourse in una VPN privata: cosa succede con l'email?

Supporto Installazione
1

Ciao!

Vorrei utilizzare Discourse in una configurazione particolare: il server web sarà accessibile solo a un numero limitato di utenti privati all’interno di una VPN. L’indirizzo IP del server sarà qualcosa come 10.0.0.1, quindi è chiaro che non potrò avere un nome di dominio pubblico valido per questo.

Ho letto che è fortemente consigliato configurare correttamente la trasmissione delle email. Ho anche letto che è possibile almeno completare la generazione dell’account amministrativo con alcuni workaround senza email.

Mi chiedo: qual è la strada migliore da seguire?

a) Configurare Discourse completamente senza email. Funzionerà? Immagino di dover seguire almeno una procedura manuale un po’ macchinosa per attivare ogni account, ma va bene per il numero limitato di utenti che mi aspetto. Funzionerebbe? Quali sarebbero i limiti non avendo funzionante la trasmissione delle email? Ovviamente, non potrò inviare notifiche via email (uno svantaggio piuttosto piccolo per me) - è tutto?

b) Anche se il server utilizza un indirizzo IP privato, potrei avere in qualche modo un indirizzo pubblico solo per le email. Mi aspetto che tutto sia ottimizzato (il più possibile) per una configurazione semplice, quindi seguendo alcune guide di installazione, immetterei l’indirizzo del server solo una volta, che verrebbe probabilmente utilizzato anche per i reindirizzamenti HTTP e per SMTP. È facile differenziarli? Posso configurare facilmente un server con un indirizzo IP privato e un dominio non corrispondente utilizzato solo per la posta?

Devo precisare che non ho ancora acquisito esperienza con Discourse. Sono pronto a cercare informazioni da solo quando incontro problemi concreti. Ma vedo che c’è una scelta fondamentale da compiere su quale strada intraprendere (a o b) e sarebbe ottimo ricevere qualche consiglio per evitare di prendere la strada sbagliata.

Grazie!

2

È necessario disporre di un nome di dominio. Discourse non può essere eseguito su un indirizzo IP.

Il server può accedere a Internet? Costruire Discourse senza connessione a Internet è… complicato.

Se il server può accedere a Internet, allora la possibilità di inviare email non è un problema.

3

Costruiscilo su una connessione pubblica, aggiungi una voce DNS all’interno della tua VPN all’indirizzo IP privato e poi disattiva l’accesso pubblico.

Non usare Lets Encrypt, poiché gli aggiornamenti del certificato falliranno.

Non potrai aggiornarlo facilmente, ma se lo stai isolando, sono sicuro che ti fossi già reso conto di questo.

L’email è fondamentale per Discourse; senza di essa, molte cose non funzioneranno.

4

Grazie per il tentativo di aiuto. Immagino di dover spiegare un po’ meglio.

Prima di tutto, dovrei chiarire quali parti conosco bene e quali no ;). Comprendo piuttosto bene la parte a basso livello: indirizzi IP, TCP, ecc. Ma non ho esperienza di ciò che fa un’applicazione web complessa. Anche per quanto riguarda la posta elettronica: come viene autenticato un mittente di email? Come si verifica che non invii spam non autorizzato? (Non mi aspetto che voi mi spieghiate tutto questo, ma solo di chiarire le mie domande…)

Non ho qui un’infrastruttura VPN aziendale completa; attualmente ho solo una subnet VPN privata e regole a livello IP.

La configurazione è la seguente: il server ha un dominio raggiungibile pubblicamente, ma tutte le porte sono chiuse tranne il punto di ingresso della VPN. I client che si connettono alla VPN ottengono un indirizzo 10.0.x.x. Il server è quindi raggiungibile su 10.0.0.1:80.

La mia comprensione (e credo di sbagliare qui) è che il server si aspetta di essere raggiungibile tramite il proprio dominio.

Supponiamo di avere il dominio xyz.com che risolve all’indirizzo IP pubblico 8.7.6.5. I client usano questo dominio/IP solo per il tunnel. Una volta configurato il tunnel, i loro browser si connettono a 10.0.0.1.

Come ho detto, non ho esperienza con Discourse. Mi aspetto che Discourse utilizzi il proprio dominio per azioni di reindirizzamento. Ad esempio, reindirizzare nuovi client che aprono 10.0.0.1 verso 10.0.0.1/login.php. (O qualcosa di simile, solo come esempio). Se Discourse li reindirizzasse a .xyz Domain Names | Join Generation XYZ, sarebbero persi, poiché il server non è raggiungibile dall’esterno della VPN. Questo è il tipo di problema che immagino richieda la configurazione di un indirizzo interno.

Per quanto riguarda la posta, devo contattare server di posta esterni. Internet pubblico è raggiungibile in ogni fase! Tuttavia, non so molto su questo argomento. Mi aspetto semplicemente che connettermi a un server di posta pubblico dicendo “ciao, sono 10.0.0.1, per favore invia alcune email per me” non funzioni, dato che sto usando un indirizzo IP privato. Qui immagino di aver bisogno di un indirizzo pubblico.

Leggendo ottimisticamente le vostre risposte, suppongo che il dominio configurato non venga utilizzato per le sessioni HTTP dei client. Se il server è raggiungibile tramite un indirizzo IP privato e mi connetto a quell’indirizzo, tutti i collegamenti e i reindirizzamenti autoreferenziali sono relativi, quindi l’utente non viene reindirizzato al dominio a cui il server si aspetta di essere connesso. Posso semplicemente configurare xyz.com come dominio e aprire comunque Discourse nel browser tramite 10.0.0.1, senza essere reindirizzato agli indirizzi xyz.com (non funzionanti).

Spero che la mia domanda sia almeno in parte chiara. Scusate se sono stato così confuso!
Oh, e HTTPS non è richiesto. Anzi, preferisco non usarlo: sono all’interno del mio tunnel e gli utenti non devono essere separati in modo sicuro. Vorrei saltare tutti questi problemi legati ai certificati e ai nomi host corrispondenti.

5

Dipende dal server di posta. Supponiamo che tu utilizzi un servizio di posta come MailGun, SendGrid, ecc. Di solito si autenticano tramite un’API, come un URL più nome utente e password.

In questo caso, poiché il server può raggiungere IP esterni (solo filtraggio in entrata), non dovresti avere problemi a connetterti al servizio di posta.

Specialmente se il dominio risolve all’indirizzo IP corretto.

Non avresti nemmeno bisogno di aprire le porte per l’installazione. Perché puoi raggiungere il dominio example.com tramite la VPN se hai il dominio puntato all’indirizzo IP privato quando usi il tunnel VPN.

Non sono sicuro al 100% se Discourse utilizzerà solo URL relativi; è quasi certo che non lo farà. Ma puoi modificare i record DNS nel dominio in modo da avere due record A: il primo (il primo) che punta all’indirizzo 10.0.0.1 e un secondo che punta all’indirizzo IP pubblico 8.7.6.5. Questo potrebbe essere complicato a volte quando si risolvono gli indirizzi e si gestisce la cache, ma puoi provare.

6

Puoi configurare xyz.com in modo che risolva a 10.0.0.1.

Se il server può raggiungere Internet, l’unico problema è che non è possibile creare un certificato HTTPS di Let’s Encrypt.

7

Ecco una domanda per te: cosa ottieni con la tua VPN che l’SSL non garantirebbe?

Un’istanza di Discourse su SSL, accessibile solo su invito, garantisce già autenticazione e crittografia. Cosa aggiunge una VPN?

8

Ho altri servizi in esecuzione che devono essere protetti. E mi piace l’idea di avere aperto solo una porta non tipica.

Ma hai ragione: dovrei valutare di allentare quel requisito e far girare Discourse sull’interfaccia pubblica, con SSL.

9

Grazie a tutti voi. Penso di aver messo in ordine le cose:

  • Per un server web in esecuzione all’interno della VPN, il server VPN deve agire anche come DNS. Il DNS interno dovrebbe risolvere lo stesso dominio all’indirizzo IP interno, che viene risolto pubblicamente all’indirizzo IP esterno. Dovrei smettere di utilizzare l’IP del server ovunque e lasciare che sia il DNS a gestire questa complessità. Attualmente la mia VPN funziona solo a livello IP e non ero nemmeno a conoscenza di questi dettagli.
    Svantaggio: potrei compromettere l’intero www di tutti gli utenti.
  • Potrei anche far girare il server web su una porta pubblica e lasciare che sia SSL a gestire la protezione.
    Svantaggio: sono esposto a tutto il male del mondo reale.