URL: https://linuxfr.org/forums/linux-debian-ubuntu/posts/autohebergement-matrix-synapse-pour-remplacer-whatsapp Title: AutoHebergement matrix synapse pour remplacer whatsapp Authors: ROUGEXIII Date: 2022年10月01日T21:07:47+02:00 License: CC By-SA Tags: auto-hébergement, matrix et nat Score: 3 Bonjour la compagnie, Dans ma quête de remplacer les séduisants outils mis à disposition par les GAFAM de mon écosystème mobile/informatique (et de celui de mes proches) pour les remplacer par de l'auto-hébergé, je souhaite remplacer whatsapp. Après quelques recherches matrix-synapse couplé au client élément, semble représenter une bonne option. Si à tout hasard l'un de vous a réussi à mettre en place quelque-chose de similaire à ce que j'essaye de faire, a des conseils, des suggestions, des pistes ou des réponses, alors je suis preneur :) Quelques contraintes perso : - Pas de nom de domaine acheté pour l'instant, je souhaite ne dépendre d'aucun service externe, à voir si ce choix tiendra dans le temps (j'ai d'ailleurs prévu d'héberger mon serveur DNS) - Hébergement sur un serveur maison sur une connexion ADSL modeste, le débit montant est donc très faible, mais je compte faire avec au moins pour toute la phase de tests et puis éventuellement par la suite passer sur une connexion fibre - J'utilise encore la box du fournisseur d'accès internet (et pas juste en mode bridge puisse que j'ai encore besoin de la VOIP fournie par par le FAI) - J'ai plusieurs (mauvais) routeurs (sous openwrt) qui composent mon réseau pour couvrir une surface plus grande, par commodité d'accès (provisoire) le serveur se trouve derrière l'un d'eux. - J'ai compartimenté les services du serveurs et ai choisi d'utiliser lxc sur un serveur debian avec des conteneurs debian. L'installation et configuration basique de matrix-synapse sur le conteneur dédié du serveur c'est bien passé et après queqlues ports redirigés, les clients de l'extérieur ainsi que ceux connectés au routeur du serveur peuvent sans problème utiliser la messagerie, l'envoi de photo/vidéos/messages audios, c'est super chouette :) Voici l'architecture: ![architecture](https://wtf.roflcopter.fr/pics/0pivGmrC/LwBYegrL.png) Là ou cela se corse: 1. Je n'arrive pas à me connecter au serveur matrix-synapse depuis les clients derrières les routeurs 52 et 53 2. Je n'arrive pas à mettre en place le proxy inversé avec nginx sur le port ssl 8448 (certificat auto-signé). En suivant la doc matrix-synapse, l'adresse:port m'envoie sur la page du serveur nginx mais pas sur la page de matrix-synapse comme avec le port initial. 3. Avec ma petite connexion internet, l'échange de vidéos pose vite problème dans un sens, est-il possible de paramétrer le niveau de compression soit sur les clients, soit sur le serveur afin de limiter le besoin de bande passante? 4. Les appels audio et vidéo ne passent pas en dehors des appareils branchés sur le réseau privé. D'après la doc il faut un serveur coturn si l'on a des NAT sur le réseau: - Est-il possible de faire les appels vidéo/audio sans webRTC (par exemple en utilisant la même mécanique que l'envoi de fichiers mais en temps réeel) avec le serveur matrix-synapse afin de se passer de coturn ? - J'ai tenté de mettre en place un serveur coturn. Je sais que la doc indique clairement qu'il y a de grandes chances que cela ne puisse pas être utilisé si le serveur est derrière un NAT mais comme il y a des paramètre pour et que je ne peux me résoudre à passer cela chez un tiers, j'aimerais vraiment à le faire fonctionner en interne si je ne peux pas m'en passer. **journalctl -u coturn** reste malheureusement silencieux. Ce que j'ai dans les fichiers de configuration: _xxx.xxx.xxx.xxx correspond à mon ip publique_ **/etc/matrix-synapse/homeserver.yaml** pid_file: "/var/run/matrix-synapse.pid" listeners: - port: 8008 tls: false type: http x_forwarded: true bind_addresses: ['0.0.0.0'] resources: - names: [client, federation] compress: true log_config: "/etc/matrix-synapse/log.yaml" media_store_path: /var/lib/matrix-synapse/media signing_key_path: "/etc/matrix-synapse/homeserver.signing.key" trusted_key_servers: - server_name: "messagerie" tls_certificate_path /etc/nginx/mesclefs/messagerie.pem tls_private_key_path /etc/nginx/mesclefs/messagerie.key allow_public_rooms_without_auth: false allow_public_rooms_over_federation: false turn_uris: [ "turn:xxx.xxx.xxx.xxx:3478?transport=udp", "turn:xxx.xxx.xxx.xxx:3478?transport=tcp" ] turn_shared_secret: s€cr€t turn_user_lifetime: 86400000 turn_allow_guests: True **/etc/turnserver.conf** listening-port=3478 external-ip=xxx.xxx.xxx.xxx/10.0.3.5 external-ip=xxx.xxx.xxx.xxx/192.168.11.5 min-port=49152 max-port=49155 use-auth-secret static-auth-secret=s€cr€t realm=xxx.xxx.xxx.xxx syslog allowed-peer-ip=10.0.0.1 allowed-peer-ip=10.0.3.4 **/etc/nginx/sites-available/messagerie** server { server_name messagerie; # Client port listen 80; listen [::]:80; return 301 https://$host$request_uri; } server { server_name messagerie; # Client port listen 443 ssl http2; listen [::]:443 ssl http2; # Federation port listen 8448 ssl; listen [::]:8448 ssl; # TLS configuration # ssl_certificate /etc/letsencrypt/live/matrix.example.org/fullchain.pem; # ssl_certificate_key /etc/letsencrypt/live/matrix.example.org/privkey.pem; ssl_certificate /etc/nginx/mesclefs/messagerie.pem; ssl_certificate_key /etc/nginx/mesclefs/messagerie.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; location ~ ^(/_matrix|/_synapse/client) { proxy_pass http://localhost:8008; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Host $host; # Default Synapse upload size. # If you change max_upload_size in Synapse config, update it here too. client_max_body_size 50M; } }

AltStyle によって変換されたページ (->オリジナル) /