Je déteste vraiment faire quelque chose d’extraordinaire ici. Je déteste ça autant que n’importe qui d’autre, mais c’est tout ce que je sais faire et c’est comme ça que toutes mes autres applications auto-hébergées fonctionnent.
J’ai mon enregistrement A wildcard pointant vers une adresse IP interne sur mon réseau, qui a les ports 80 et 443 exportés par nginx proxy manager, qui a tous mes certificats SSL configurés. J’ai la plupart de mes configurations réseau existantes sous docker, donc nginx proxy manager est sûr à utiliser car il utilise simplement le réseau docker pour proxyfier en http.
Dans le cas de discourse, j’ai essayé de configurer discourse.MYDOMAIN.com vers l’adresse IP locale séparée sous un enregistrement A distinct et j’ai réussi à le résoudre ; cependant, la configuration de nginx proxy manager avec lets encrypt fonctionne et celle de discourse ne fonctionne pas pour les adresses IP internes.
Alors… je veux juste faire du reverse proxy. Je vais essayer toutes sortes de configurations nginx proxy pour que cela fonctionne. Je suis légèrement préoccupé par les attaques de l’homme du milieu, mais j’aimerais comprendre pourquoi la configuration lets encrypt de nginx proxy manager fonctionne avec une configuration interne et pas discourse.
Il doit y avoir un moyen !
(P.S. Je sais que je suis un peu perdu. S’il vous plaît, posez des questions précises et je pourrai apporter des éclaircissements)
Il existe quelques sujets sur l’exécution de Discourse derrière nginx proxy manager. Fondamentalement, vous configurez Discourse pour ne pas se lier à aucun port et ajoutez les étiquettes requises dans une section labels: de votre app.yml.
Si je choisis la voie du gestionnaire de proxy nginx, ce qui est la façon dont je l’ai configuré actuellement (par opposition à la configuration de Let’s Encrypt sur la VM Discourse elle-même)…
Je devrais toujours me lier au port 80 sur la VM Discourse car il s’agit d’une machine distincte dans mon cas.
Mon expérience actuelle est que j’obtiens des erreurs de contenu mixte avec ma configuration actuelle du gestionnaire de proxy nginx avec la configuration SSL là-bas pointant vers l’adresse IP de la VM Discourse sur le port 80.
Je ne pense pas qu’il soit possible de s’en débarrasser car les références http:// dans le code sont codées en dur… ou ai-je tort ? est-ce que ce champ labels auquel vous avez fait référence changerait cela ?
J’essaierai cela si la configuration du socket Unix ne fonctionne pas. Merci @Falco et @pfaffman pour votre soutien. Je reviendrai avec ce qui fonctionne.
Je ne peux pas configurer le socket Unix… ma VM discourse est sur une machine séparée. Retour au plan initial. Je vais voir si je peux activer force_https avec d’autres messages sur le forum. Pour information, cette est l’étape que je ne peux pas réaliser.
J’ai pu le faire dans l’interface graphique comme je l’ai mentionné précédemment.
@Falco, @pfaffman, @Jagster, @merefield… merci à vous tous, j’ai réussi à configurer le proxy inverse et je n’ai plus ces erreurs de contenu mixte.
Une fois que j’ai fait le proxy inverse vers le port 80 de la VM discourse et que j’ai pu m’enregistrer et autres, il s’agissait de définir force_https en utilisant l’interface graphique et d’ajouter le drapeau x-forwarded-proto dans l’onglet avancé du gestionnaire de proxy nginx.