Forum Linux.debian/ubuntu AutoHebergement matrix synapse pour remplacer whatsapp

Posté par  . Licence CC By‑SA.
Étiquettes :
3
1
oct.
2022

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

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;
    }
}
  • # deja ... les routes

    Posté par  . Évalué à 5.

    est-ce que tes routeurs 1.52 et 1.53 savent comment joindre les machines du reseau 192.168.11.x voire meme le reseau 10.x.y.z ?

    c'est dans la table de routage statique de chaque routeur qu'il faut ajouter la route vers ces reseaux par l'IP du routeur 1.51

    sinon, par defaut ils vont envoyer à la box, qui ne connait pas les services

    et à l'inverse il faut que ton routeur 1.51 connaissent les reseaux qui sont derriere les autres routeurs

    evidemment si tu fais du NAT ca simplifie mais pas forcement
    car ton service en 10.x.y.z s'annonce comme tel, est NAT derriere le routeur 1.51
    le PC en 192.168.12 est caché derriere le routeur 1.52

    du coup il n'y a que 1.51 et 1.52 qui se voit…
    etc

    • [^] # Re: deja ... les routes

      Posté par  . Évalué à 1.

      Bonjour, Merci pour le premier retour :)

      Les 3 routeurs openwrt (1.51, 1.52 et 1.53) ont pour passerelle l'IP de la box FAI : 192.168.1.1 => Ainsi tous les clients de ces 3 routeurs ont accès à internet et peuvent communiquer à mon autre serveur connecté en RJ à la BOX en 192.168.1.3

      Dans la BOX FAI je route les ports que je veux rendre accessibles depuis l'extérieur vers la machine concernée:
      Pour le premier serveur directement l'ip 192.168.1.3.
      Pour le nouveau serveur derrière le routeur je redirige vers l'ip du routeur 192.168.1.51 puis dans le routeur vers l'IP du serveur 192.168.11.5 et enfin dans le serveur vers l'IP du conteneur lxc : 10.0.3.4 par exemple.
      A noter que sur la box le menu de configuration sur lequel je paramètre cela est "reseau v4 > NAT > Redirection de ports"
      Alors que dans les routeurs openwrt c'est le menu "Network > Firewall > port forwards" et non le menu "Network > Firewall > NAT rules" et du coup je ne comprends pas bien la différence.

      Je pensais que comme par exemple sur la Box le port 8008 est routé vers le routeur openwrt 1.51, quand le routeur 1.52 reçoit une demande depuis son réseau à destination de 192.168.11.4:8008, il l'envoie à sa passerelle donc la box. Et la box devrait activer sa redirection comme quand cela vient de l'extérieur, mais ce n'est peut-être pas le cas? En fait cela semble logique que non puisque la box ne connaît pas l'IP 192.168.11.5… Aurait-il aurait fallu que je paramètre le serveur en 192.168.1.51 sur le client du réseau local? En revanche lorsque je mets l'IP publique comme serveur sur le client du routeur 1.52 je crois que cela fonctionne.

      Il y a peut-être des choses que je devrais apprendre sur les réseaux, routage ou j'y suis presque?

      • [^] # Re: deja ... les routes

        Posté par  . Évalué à 3.

        Je pensais que comme par exemple sur la Box le port 8008 est routé vers le routeur openwrt 1.51, quand le routeur 1.52 reçoit une demande depuis son réseau à destination de 192.168.11.4:8008, il l'envoie à sa passerelle donc la box. Et la box devrait activer sa redirection comme quand cela vient de l'extérieur, mais ce n'est peut-être pas le cas?

        helas non,
        cela peut marcher (car ca depend des box) si ton PC "client" demande ton IP publique sur le port 8008

        alors à ce moment là le flux va rentrer dans la box port 8008, etre renvoyé par le port forward de la box vers le routeur 1.51, port 8008, qui renverra vers le serveur…

        en aucun ca ta box ne va prendre "tout ce qui va vers 8008" et le renvoyer vers 1.51 8008

        pour ca que je te disais qu'il pouvait etre necessaire et plus propre de dire à tes routeurs 1.52 et 1.53 qu'il faut contacter 1.51 pour joindre le reseau 192.168.11

        ainsi ton client demande 192.168.11.4:8008, sera envoyé par son routeur vers le routeur 192.168.1.51…

        • [^] # Re: deja ... les routes

          Posté par  . Évalué à 1.

          C'est ce que j'ai réalisé en écrivant la réponse :)

          Du coup comment faire cela?
          Quels mots clefs (français ou anglais) chercher pour trouver de la doc là dessus?

          En attendant d'en apprendre un peu plus, je vais continuer tous mes essais à partir de clients hors réseau interne à partir de l'IP publique.

          Pour les autres points as-tu des pistes/idées/commentaires?
          Pour le serveur coturn en regardant les ports écoutés, je me rends compte que le 3479 l'est aussi, du coup je vais l'ajouter dans la box/routeur/iptable et voir si le journal syslog s'active lorsque je tente un appel (je suis passé en "verbose" dans le fichier de config de coturn).

          • [^] # Re: deja ... les routes

            Posté par  . Évalué à 1. Dernière modification le 03 octobre 2022 à 11:02.

            Je viens de faire un petit pas je pense:

            Bon je tentais d'écouter le journal avec les permissions insuffisantes donc forcément je n'avais rien. Depuis j'ai vu le warning suivant
            NO EXPLICIT LISTENER ADDRESS(ES) ARE CONFIGURED

            J'ai du coup ajouté à mon fichier de config turnserver.conf:
            listening-ip=0.0.0.0
            listening-ip=xxx.xxx.xxx.xxx#Ip publique
            listening-ip=192.168.1.1
            listening-ip=192.168.1.51
            listening-ip=192.168.11.5
            listening-ip=10.0.3.5
            listening-ip=10.0.3.4

            Bon je pense que 0.0.0.0 aurait suffit, mais je voulais pas passer à côté de quelque-chose.

            Depuis le log est très bavard et les warnings suivants tournent en boucle:

            0: : Trying to bind fd 49 to <xxx.xxx.xxx.xxx:3478>: errno=99
            0: : Cannot bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478
            0: : Trying to bind DTLS/UDP listener socket to addr xxx.xxx.xxx.xxx:3478, again...
            bind: Cannot assign requested address
            Cannot bind local socket to addr: Cannot assign requested address
            En effectuant quelques recherches cela ressemble à un port déjà utilisé, mais là je ne vois pas le conteneur est dédié à coturn et ne contient pas grand chose d'autre.

            Lorsque j'arrête le service coturn ss -plntu ne renvoie rien
            Lorsque je le relance ss -plntu renvoie:

            Netid          State           Recv-Q           Send-Q                     Local Address:Port                         Peer Address:Port          Process          
                udp            UNCONN          0                0                                0.0.0.0:3478                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3478                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3478                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3478                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3479                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3479                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3479                          0.0.0.0:*                              
                udp            UNCONN          0                0                                0.0.0.0:3479                          0.0.0.0:*                                      
                tcp            LISTEN          0                1024                             0.0.0.0:3478                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3478                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3478                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3478                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3479                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3479                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3479                          0.0.0.0:*                              
                tcp            LISTEN          0                1024                             0.0.0.0:3479                          0.0.0.0:*                              
            

            Est-ce que ma configuration le force à ouvrir plusieurs fois le même port?

            • [^] # Re: deja ... les routes

              Posté par  . Évalué à 1.

              Bon effectivement si je ne mets que le seul :
              listening-ip=0.0.0.0

              Je n'ai plus l'erreur…

              (dommage qu'on ne puisse plus modifier ses commentaires après 5 minutes :/)

              • [^] # Re: deja ... les routes

                Posté par  . Évalué à 1.

                Je suis tombé sur ça

                Du coup j'ai l'impression que sur mon serveur le "PREPROUTING" avec iptable est insuffisant. Mais là c'est bien au delà de mes capacités…

          • [^] # Re: deja ... les routes

            Posté par  . Évalué à 4.

            Du coup comment faire cela?
            Quels mots clefs (français ou anglais) chercher pour trouver de la doc là dessus?

            ben, comme indiqué, tu veux gerer des routes statiques
            en anglais static route sur tes boitiers openWRT ou sur ta box si elle le permet

            • [^] # Re: deja ... les routes

              Posté par  . Évalué à 1.

              D'accord,

              Du coup sur le routeur 1.52 j'ai ajouté la route statique suivante:
              - Interface : Wan
              - Target : 192.168.11.5
              - IPv4-Netmask : 255.255.255.0
              - IPv4-Gateway : 192.168.1.51

              Dans le doute j'ai aussi ajouté sur la box la "table de routage" suivante:
              - Destination : 192.168.11.5
              - Masque de sous réseau : 255.255.255.0
              - Passerelle : 192.168.1.51

              Mais depuis un client sur le routeur 1.51 je n'ai toujours pas accès au serveur 192.168.11.5

              • [^] # Re: deja ... les routes

                Posté par  . Évalué à 3.

                les routes semblent bien, j'aurai fait plus large pour englober le reseau 11 au complet (192.168.11.0/255.255.255.0) mais l'idée est là

                ensuite evidemment il faut
                - supprimer le portforward 8008 sur le routeur 1.51 vers la machine distante
                - autoriser ceux qui demandent 192.168.11.5:8008 à y acceder

                ou
                - laisser le port forward 8008 sur 1.15
                - que le client demande 1.51:8008
                - que le routeur 1.51 autorise le client

                ne pas oublier la "route retour"
                qui permet à 11.5 de demander à 1.51 à qui envoyer le paquet vers 12.x par exemple

  • # Salon Matrix

    Posté par  (site web personnel) . Évalué à 3.

    Il y a un salon Matrix pour l'autohébergement, en français:

    https://matrix.to/#/#autohebergement:matrix.underworld.fr

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Salon Matrix

      Posté par  . Évalué à 1.

      Bonjour merci pour l'info :)

      Quel est la plage horaire qu'il est préférable d'utiliser pour demander de l'aide? Le soir entre 19h et 20h?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.