Comme dit dans ma présentation j’ai quelques questions à propos de mon noeud duniter :
via le wizard key je saisie la clé publique de mon compte, mais celle-ci ne semble pas utilisée par la suite, est-ce que c’est parce que je ne suis pas encore membre?
via le wizard network je saisie le nom de domaine de mon noeud g1.melua.fr (il s’agit d’un enregistrement CNAME) pourtant mon noeud apparait dans Cesium sous la forme IP 163.172.169.239, une explication ?
le port par défaut est 10901, mais il est rarement utilisé par les noeuds, je vois beaucoup plus de 80 ou 443, quelle raison à cela ? pour passer les proxy d’entreprise ?
je vois que certains noeuds utilisent une connexion chiffrée TLS/SSL, quelle raison à cela ? quels sont les chiffrements supportés par le réseau ?
10901 est le port de communication des nœuds entre eux. Les ports 80 et 443 sont eux les ports pour les API json permettant aux clients comme Cesium de faire des requêtes.
Les clients et les noeuds n’utilisent pas la même api JSON over HTTP ? En tout cas je vois bien mon noeud dialoguer avec d’autres noeuds sur n’importe quel port.
Alors pour être plus précis c’est ton couple (id secret + passwd) que tu doit saisir, et non ta clé publique. Cela génère un trousseau de clé qui est utilié pour signer cryptographiquement tout les messages transmis par le noeud sur le réseau.
Puis lorsque tu deviendra membre, ce même trousseau de clé sera utilisé par ton noeud pour calculer des blocs, et ceux de manière automatique dés que tu deviendra membre (pas besoin de restart).
Parce que tua renseigner le champ remote ip, lorsque tu a un DNS correctement configuré tu peut laisser vide le champ remote IP, ainsila vue réseau cesium affichera bien ton domaine et pas ton ip (la répercussion n’est pas immédiate, il faut attendre que quelques blocs passent).
Le port 10901 est le port d’entrée, par lequel ton noeud reçoit les messages du réseau, les autres ports utilisés sont utilisés en sortie, pour contacter les autrs noeuds, hors beaucoup de noeuds écoutent sur 80 ou 443 plutot que 10901, d’ou tes observations
Duniter ne gère pas le chiffrement, la seule chose qu’il fait c’est de rajouter un ‘s’ a la requête si c’est sur 443, en revanche les champs remotehost et remoteport te permettent de placer un reverse proxy entre ton noeud duniter et internet, et c’est ce reverse proxy qui gère le chiffrement, tu peut faire ça avec nginx par exemple
10901 est le port par défaut pour l’API BMA, qui sert pour toutes les communications réseaux jusqu’aux versions 1.5.x
A partir des versions 1.6.x BMA ne sert plus que pour al communication avec les clients, et les communications inter-nœuds se font avec une nouvelle API nommée WS2P, le port convetionnel pour cette nouvelle APi est le 20901.
Merci pour les infos. J’ai pu reconfigurer mon noeud avec les informations correctes ! J’utilise Duniter 1.5.9 il s’agit bien de la version stable qui doit être utilisée pour Ğ1 ? Donc en attendant 1.6.x je peux communiquer avec les clients et les autres noeuds via le port 10901.
Concernant le TLS je posais la question du besoin de chiffrement : en quoi est-ce utile de chiffrer les dialogues inter-noeuds ou avec les clients?
Dans les communications via BMA qui ne sont pas toujours signés cela permet d’authentifier l’interlocuteur, le jours ou BMA sera remplacée par une API Client entièrement signée le chiffrement ne servira a rien, sauf a protéger sa vie privée (par exemple je ne veut pas qu’on sache que j’ai soumis tel requête a tel noeud du réseau)
Non nous ne sommes plus en phase béta, la 1.6 est déjà sur la réseau Ğ1 depuis un moment, mais elle est encore au statut de pré-release donc peut évoluer rapidement, doc en principe c’est seulement els membres avisés et suivant de près les livraisons qui l’utilisent.
Oui c’est ça
Le remote port doit être 443, en revanche le port d’écoute de duniter peut celui que tu veut ça on s’en fou c’est le reverse proxy qui relaie.
Bon j’ai mis mon noeud derrière nginx en reverse-proxy TLS/SSL. Par contre je ne vois plus mon noeud dans Cesium, il apparait par intermittence c’est étrange. J’utilise un certificate pour plusieurs sous-domaines et une clé ECDSA, je ne sais pas si ça joue. J’ai désactivé HTTP2 pour voir.
Oui Cesium n’affiche pas forcément toujours tout les nœuds ça dépend des aléas du réseau, l’essentiel est de t’assurer via la web-ui ou l’api BMA ou les logs que ton noeud reste synchronisé au niveau du bloc courant
Après avoir laissé tourner 3 heures le problème était toujours présent : je me suis donc résolu à refaire un certificat dédié au sous-domaine g1.melua.fr avec une clé RSA de 2048bits et ça fonctionne instantanément…
Je ne crois pas que ce soit une histoire de certificat multi-domaine car par exemple le noeud g1.monnaielibreoccitanie.org utilise un certificat multi-domaine et n’a aucun souci dans Cesium. En revanche je crois que j’étais le seul à utiliser une clé ECDSA. Un élément à peut-être prendre en compte les serveurs OCSP de Let’s Encrypt avait l’air de fonctionner moins bien ce soir.
Ha non c’est des certificats Let’s Encrypt mono domaines, c’est moi qui administre le serveur de monnaie libre occitanie donc je sais comment je l’ai configuré
ha oui c’est une cause possible, tu peut le préciser dans le ticket
Dans ce cas ça peut aussi etre un faux positif oui
Je pensais que tu parlais des certificats wilcard, si en fait ton certificat était juste une liste définie et finie de sous-domaine alors ça aurait du fonctionner en effet, tu devrais ouvrir un ticket
Des wildcard chez Let’s Encrypt, j’aimerais bien mais ils ont annoncé la disponibilité pas avant mars 2018 ! Je vais ouvrir le ticket mais j’aimerais reproduire l’anomalie avec une clé ECDSA et en avoir le coeur net
mais ils ont annoncé la disponibilité pas avant mars 2018 ! Je vais ouvrir le ticket mais j’aimerais reproduire l’anomalie avec une clé ECDSA et en avoir le coeur net 