Utiliser Discourse sur un VPN privé : que faire des e-mails ?

Soutien Installation
1

Bonjour !

J’aimerais utiliser Discourse dans une configuration particulière : le serveur web ne sera accessible qu’à un nombre limité d’utilisateurs privés au sein d’un VPN. L’adresse IP du serveur sera du type 10.0.0.1, il est donc évident que je ne pourrai pas avoir de nom de domaine public valide pour cela.

J’ai lu qu’il est fortement recommandé de configurer correctement l’envoi des e-mails. J’ai également lu qu’il est possible, avec quelques astuces, de terminer la création du compte administrateur sans e-mail.

Je me demande donc quelle est la meilleure approche :

a) Configurer Discourse complètement sans e-mail. Cela fonctionnera-t-il ? Je suppose que je devrai suivre au moins une procédure manuelle un peu hasardeuse pour activer chaque compte, mais cela me convient pour le nombre limité d’utilisateurs que j’attends. Est-ce que cela fonctionnera ? Quelles seraient les limitations si l’envoi d’e-mails ne fonctionne pas ? Bien sûr, je ne pourrai pas envoyer de notifications par e-mail (ce qui est un inconvénient mineur pour moi) — est-ce tout ?

b) Bien que le serveur utilise une adresse IP privée, je pourrais peut-être avoir une adresse publique uniquement pour les e-mails. Je m’attends à ce que tout soit optimisé (dans la mesure du possible) pour une configuration facile : en suivant quelques tutoriels d’installation, je n’entrerais l’adresse du serveur qu’une seule fois, laquelle serait probablement utilisée pour les redirections HTTP, etc., ainsi que pour le SMTP. Est-il facile de faire la différence ? Puis-je facilement configurer un serveur avec une adresse IP privée et un domaine non correspondant utilisé uniquement pour les e-mails ?

Je précise que je n’ai pas encore acquis d’expérience avec Discourse. Je suis prêt à faire des recherches de mon côté lorsque je rencontrerai des problèmes concrets. Cependant, je vois qu’il faut prendre une décision fondamentale entre ces deux options (a ou b), et il serait formidable de recevoir quelques conseils pour éviter de partir dans la mauvaise direction.

Merci !

2

Vous devez disposer d’un nom de domaine. Discourse ne peut pas fonctionner avec une adresse IP.

Le serveur peut-il accéder à Internet ? Installer Discourse sans connexion Internet est… délicat.

Si le serveur peut accéder à Internet, la capacité à envoyer des e-mails ne pose pas de problème.

3

Construisez-le sur une connexion publique, ajoutez une entrée DNS dans votre VPN vers l’adresse IP privée, puis désactivez l’accès public.

N’utilisez pas Let’s Encrypt, car les mises à jour des certificats échoueront.

Vous ne pourrez pas facilement le mettre à jour, mais si vous l’isolez, je suis sûr que cela vous était déjà évident.

L’e-mail est au cœur de Discourse ; sans lui, de nombreuses fonctionnalités ne fonctionneront pas.

4

Merci d’avoir essayé d’aider. Je suppose que je dois préciser un peu plus.

D’abord, je devrais expliquer ce que je connais bien et ce que je ne connais pas ;). Je comprends assez bien la partie de bas niveau : adresses IP, TCP, etc. Mais je n’ai aucune expérience des choses qu’une application web complexe fait. Et aussi pour les e-mails : comment un expéditeur d’e-mail est-il authentifié, comment vérifie-t-on qu’il n’envoie pas de spam non autorisé ? (Je ne m’attends pas à ce que vous m’expliquiez tout cela, juste à ce que vous clarifiiez mes questions…)

Je n’ai pas ici une infrastructure VPN d’entreprise complète ; tout ce que j’ai actuellement, c’est un sous-réseau VPN privé et des règles au niveau IP.

La configuration est la suivante : le serveur possède un domaine accessible publiquement, mais tous les ports sont fermés sauf le point d’entrée VPN. Les clients se connectant au VPN obtiennent une adresse 10.0.x.x. Le serveur est alors accessible sur 10.0.0.1:80.

Ma compréhension (et je suppose que je me trompe ici) est que le serveur s’attend à être accessible lui-même via son domaine.

Disons que j’ai le domaine xyz.com qui résout vers l’adresse IP publique 8.7.6.5. Les clients utilisent ce domaine/IP uniquement pour le tunnel. Une fois le tunnel configuré, leurs navigateurs se connectent à 10.0.0.1.

Comme je l’ai dit, je n’ai aucune expérience avec Discourse. Ce que j’attends de Discourse d’utiliser son propre domaine pour, ce sont des actions de redirection. Par exemple, rediriger les nouveaux clients qui ouvrent 10.0.0.1 vers 10.0.0.1/login.php. (Ou similaire, juste comme exemple). Si Discourse les redirigeait vers .xyz Domain Names | Join Generation XYZ à la place, ils seraient perdus car le serveur n’est pas accessible depuis l’extérieur du VPN. C’est le type de problème attendu que j’assume qu’une adresse interne devrait résoudre.

En ce qui concerne les e-mails, je dois contacter des serveurs de messagerie externes. L’internet public est accessible à tout moment ! Je ne connais pas beaucoup ce sujet, cependant. Je suppose simplement que se connecter à un serveur de messagerie public en disant « hé, je suis 10.0.0.1, veuillez envoyer quelques e-mails pour moi » ne fonctionnera pas car j’utilise une adresse IP privée. Ici, je suppose avoir besoin d’une adresse publique.

En lisant vos réponses de manière optimiste, je suppose que le domaine configuré n’est pas utilisé pour les sessions HTTP des clients. Si le serveur est accessible via une adresse IP privée, et que je me connecte à cette adresse IP, tous les liens et redirections auto-référencés sont relatifs, donc l’utilisateur n’est pas redirigé vers le domaine que le serveur s’attend à être connecté. Je peux simplement configurer xyz.com comme domaine, et toujours ouvrir Discourse dans le navigateur avec 10.0.0.1, sans être redirigé vers des adresses xyz.com (dysfonctionnelles).

J’espère que ma question est un peu claire. Désolé d’être si confus !
Ah, et HTTPS n’est pas requis. Je préfère même ne pas l’utiliser — je suis à l’intérieur de mon tunnel et les utilisateurs n’ont pas besoin d’être séparés de manière sécurisée. Je voudrais éviter tous ces problèmes liés aux certificats et aux noms d’hôte correspondants.

5

Cela dépend du serveur de messagerie. Supposons que vous utilisiez un service de messagerie comme MailGun, SendGrid, etc. Ils s’authentifient généralement via une API, une URL, ainsi qu’un nom d’utilisateur et un mot de passe.

Dans ce cas, tant que le serveur peut accéder aux adresses IP externes (filtrage uniquement entrant), vous ne devriez pas rencontrer de problème pour vous connecter au service de messagerie.

Surtout si le domaine résout vers l’adresse IP correcte.

Vous n’auriez même pas besoin d’ouvrir les ports pour l’installation. En effet, vous pouvez accéder au domaine example.com via le VPN si le domaine pointe vers l’adresse IP privée lorsque vous utilisez le tunnel VPN.

Je ne suis pas tout à fait certain que Discourse n’utilise que des URL relatives ; il est presque certain qu’il n’en sera pas ainsi. Cependant, vous pouvez modifier les enregistrements DNS du domaine de manière à avoir deux enregistrements A : le premier pointant vers l’adresse 10.0.0.1, et le second vers l’adresse IP publique 8.7.6.5. Cela peut parfois être délicat lors de la résolution des adresses et de la mise en cache, entre autres, mais vous pouvez essayer.

6

Vous pouvez faire en sorte que xyz.com pointe vers 10.0.0.1.

Si le serveur peut accéder à Internet, le seul problème est que vous ne pouvez pas créer de certificat HTTPS Let’s Encrypt.

7

Voici une question pour vous : qu’apporte votre VPN que SSL ne ferait pas ?

Une instance Discourse sur SSL, accessible sur invitation uniquement, assure déjà l’authentification et le chiffrement. Qu’ajoute un VPN ?

8

J’ai d’autres services en cours d’exécution qui doivent être protégés. Et j’aime bien l’idée de n’ouvrir qu’un seul port non standard.

Mais vous avez raison : je devrais envisager d’assouplir cette exigence et permettre à Discourse de s’exécuter sur l’interface publique, avec SSL.

9

Merci à tous. Je pense avoir mis de l’ordre dans mes affaires :

  • Pour un serveur web exécuté à l’intérieur du VPN, le serveur VPN doit également agir comme serveur DNS. Le DNS interne doit résoudre le même domaine vers une adresse IP interne, qui est résolue publiquement vers une adresse IP externe. Et je devrais arrêter d’utiliser l’adresse IP du serveur partout et laisser le DNS gérer cette complexité. Actuellement, mon VPN fonctionne uniquement au niveau IP, et je n’étais même pas au courant de ces détails.
    Inconvénient : je risque de faire tout foirer sur tout le site web de tous les utilisateurs.
  • Je pourrais aussi faire tourner le serveur web directement sur un port public et laisser SSL gérer la protection.
    Inconvénient : je suis exposé à tout le mal du monde réel.