Bonjour,
J'ai installé le serveur Snikket sur mon hébergement à partir de leur fichier docker-compose. Je rencontre un problème pour la redirection des ports vers le serveur (J'ai trouvé un contournement plus ou moins acceptable en attendant d'avoir mieux).
J'héberge plusieurs services sur une petite machine et j'utilise Nginx Proxy Manager (NPM) pour gérer le partage des ports 80/443 entre plusieurs VM. Mon problème est que les règles de redirection dans NPM sont spécifiées par domaine et non par domaine:port. Je ne peux donc pas rediriger pour le domaine chat.example.com les requêtes faites sur :80 et sur :443 vers deux ports différents, or cela est nécessaire pour Snikket d'après leur doc.
- Si je redirige tout vers le port 80 en faisant gérer le certificat SSL par NPM, Snikket renvoie une redirection vers https (on a une redirection en boucle).
- Si je redirige tout vers le port 443, ça a l'air de fonctionner (si les certificats de Snikket ont pu être validés avant en http). Mais Snikket doit pouvoir renouveler ses certificats SSL (pour le serveur XMPP, pas que l'interface web) et pour cela il faut que le répertoire .well-known soit accessible, or c'est NPM qui répond à ces requêtes car lui aussi doit pouvoir valider ses certificats…
J'ai pu contourner le problème en paramétrant un port personnalisé pour https avec l'option SNIKKET_TWEAK_HTTPS_PORT. Par chance la redirection se fait bien de http vers https sur le bon port, ce qui permet de passer en dehors du reverse-proxy. Mais ce n'est pas vraiment prévu pour être publique, par exemple les liens d'invitations que je génère ne tiennent pas compte de ce port.
Avez-vous une idée pour faire quelque chose de plus propre?
# comment fait-il ?
Posté par NeoX . Évalué à 4 (+1/-0).
ton NPM ecoute sur 80 et 443 de la machine physique,
il envoie ensuite selon les regles que tu lui donnes, vers des machines virtuelles, port 80 ou 443
à toi de modifier la config docker pour ne pas exposer le port 80/443 de snikket à l'exterieur du docker, il sera alors simplement lancer sur le reseau interne de docker comme pour les autres machines, et NPM enverra le 80 et 443 de chat.domain.tld vers l'IP de ce docker
[^] # Re: comment fait-il ?
Posté par totof2000 . Évalué à 2 (+1/-1).
Arretez e parler de machine virtuelle pour un conteneur. Ca n'a rien à voir. Un conteneur c'est une hierarchie de processus dans un environnement cloisonné : un chroot++++.
[^] # Re: comment fait-il ?
Posté par NeoX . Évalué à 4 (+1/-0). Dernière modification le 08 mai 2025 à 11:02.
avec un reseau à part, donc pour la comprehension c'est un process isolé dans un sous reseau dédié
donc il faut le gérer comme tel.
ne pas exposé le port à l'exterieur et laisser le reverse proxy causer par l'interface reseau interne
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.