Conf reseau pour duniter sur docker

Nicolas_Markovic · 26 July 2020 14:23

Hello tout le monde ,

je cherche à savoir comment bien paramétrer mon duniter qui tourne sur container Docker

(version de l’image : Duniter-1.8.1)
j’ai un NAS Synolgy D720+, une Bbox, et un nom de domaine avec une certification « let’sEncrypt » et la meme chose sur un sous domaine

la Bbox redirige les ports 443,10901,20901 sur l’ip locale de mon serveur
j’ai donc lié les ports 9220,10901,20901 de docker pour les lié à l’exterieur du serveur

jusque là tout va bien car quand je fais 192.168.1.xx:9220 de mon serveur j’obtient bien la page html du service webstart

je me connect donc à mon serveur en ssh localement , puis à mon container duniter
et je execute la commande
duniter wizard key
j’entre mon identifiant et mon mot de passe , puis valide
premier petit problème: le premier caractère de la clef public n’est pas afficher dans le resultat
(edit: apres synchro, le premier caractere semble manqué aussi dans les logs de ws2p
et affiche des erreurs : error: WS2P >>> >>> WS ERROR: REJECTED_PUBKEY_OR_INC
ORRECT_ASK_SIGNATURE_FROM_REMOTE )

j’ignore je passe la commande duniter wizard network
j’entre les données suivante :
IPv4 interface lo 127.0.0.1
IPv6 interface None
Port 10901
Remote IPv4 None
et là deuxieme probleme: ca freeze sur le RemoteIPv4 à None

j’annule et recommence et me résigne à taper mon ip public dans RemoteIPv4
je met le même port 10901 en remote aussi
et je finis pas le DNS name de mon sous domaine: g1.nikoserveur.com

ensuite j’execute duniter config --ws2p-noupnp --ws2p-port 20901 --ws2p-host 127.0.0.1 --ws2p-remote-port 443 --ws2p-remote-host g1.nikoserveur.com
en rajoutant: duniter config --ws2p-remote-path /ws2p

je fait ensuite duniter sync g1.duniter.org:443
çà se finit au bout de 4/5 heures (accessoirement je vous invite à l’ecrire dans les tutos qu’en fonction de la machine çà peut varié de 10mn à quelques heures… çà nous évite de paniquer et de pas savoir ce qu’il se passe)

la sync ws2p ne fonctionne pas bien semble t’il dans les logs…(ws2p timeout …etc …)
et à ce moment j’ai lu ici et là sur le forum qu’il faut rediriger en reverse proxy
j’imagine que c’est sur le nginx de mon serveur qu’il faut modifier et non celui du container docker ?
j’ai donc rediriger comme indiqué le reverse proxy du https://g1.nikoserveur.com vers localhost:20901
mais vu que mon synology réécrit ma conf au redemarage du serveur , il n’est pas persistant , par ailleur j’ai actuellement l’impossibilité de rajouter un path /ws2p dans l’interface synology
est elle necessaire? ou je peux l’avoir directement sur / ?

peut etre devrai je créer un deuxieme sous domaine pour le BMA ?
c’est possible d’avoir le g1.xxx.com pour le WS2P et un bma.xxx.com pour le BMA ?
et les deux en 443 (https) ?

et finalement derniere question , la conf nginx sur docker , pas besoin d’y toucher ?

merci pour votre aide

Niko

elois · 26 July 2020 16:54

Bonjour @Nicolas_Markovic

Quelle est la clé publique en question ?

Non ça n’a rien à voir ce sont des logs qui devrait être au niveau warning, ça veut juste dire qu’un nœud distant tente de se faire passer pour qui il n’est pas, ou de communiquer dans une ancienne version des messages pas compatible, il faut l’ignorer.

Ce n’est pas normal. Après si ton ip publique est fixe ce n’est pas gênant de l’indiquée. Essaye de refaire un wizard network pour voir si tu arrives à supprimer l’ip publique (qui ne sert à rien si tu as un ndd).

Tu as également un nginx dans ton conteneur docker ? Ça fait beaucoup d’intermédiaires, plus d’erreurs possibles et de moins bonnes perfs, il faut mieux avoir un seul nginx, par exemple sur l’hôte. Duniter peut sans problème écouter en frontal dans le conteneur.

La doc pour docker est ici :

Non ce n’est pas nécessaire mais comme il y a 2 API publiques si tu ne peux pas rajouter de path il te faut utiliser 2 sous domaines différents.

Alors l’inverse serait plus logique, car c’est le endpoint de l’api BMA qui est susceptible d’être saisi par l’utilisateur (dans les paramètres de Cesium par exemple). Alors que le endpoint de l’API WS2P n’est jamais saisi, ce sont les nœuds qui se contactent entre eux automatiquement.

Donc il vaut mieux utiliser g1.xxx.com pour BMA et ws2p.xxx.com pour WS2P

Je ne comprends pas ce que tu nommes “nginx sur docker” ? L’image docker officielle de Duniter ne contiens pas nginx.

Nicolas_Markovic · 26 July 2020 17:04

merci pour tes reponses çà m’aide en parti
ma clef public est la suivante :
1RcFajMmNL5m4Gfx2ketJwsssuvYUfFSkRwXu6qoNnf
et le « 1 » est manquant sur les logs
et sur le wizard key

pour le freeze sur remoteIpv4 à none rien ne change

non effectivement mon docker n’as pas de nginx , c’etait pour etre sur
par contre pour les conf ws2p config --ws2p-noupnp --ws2p-port 20901 --ws2p-host 127.0.0.1 --ws2p-remote-port 443 --ws2p-remote-host g1.nikoserveur.com
çà pose pas de pb , pour la redirection ?
j’ai aucune donnée dans mon navigateur avec l’ip local de mon serveur avec les ports 10901 et 20901
je recoit des connection_reset

elois · 26 July 2020 17:21

Cool bonne nouvelle, ce qui est donc tout a fait normal. Les clés publiques sont affichées en base58, et en base58 le zéro correspond au caractère “1”. En réalité, une clé publique est un très grand nombre, pas une chaine caractère.

C’est comme si tu saisissait le nombre “042” et que tu t’étonnais que l’ordinateur te dise qu’il s’agit du nombre “42”

Tu peut aussi choisir l’interface locale, vu que Duniter écoute en local.

Quand Duniter est dans docker il doit écouter sur 0.0.0.0. Il faut donc changer le ws2p-host.

C’est vrai que ce n’est pas signalé dans la doc de docker, je vais l’ajouter.

Aussi il faut que ton nginx sur l’hôte soit correctement configuré pour gérer les websoket.

Nicolas_Markovic · 26 July 2020 18:12

il devrait pas plutot ecouter sur l’interface eth0 (172.17.0.2) le bridge docker ?

pour le nginx voici la conf :

server {

listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name g1.nikoserveur.com;
ssl_certificate /.../fullchain.pem;
ssl_certificate_key /.../privkey.pem;
add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload" always;

location / {
    proxy_connect_timeout 60;
    proxy_read_timeout 60;
    proxy_send_timeout 60;
    proxy_intercept_errors off;
    proxy_set_header        X-Real-IP            $remote_addr;
    proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto            $scheme;
    proxy_pass http://127.0.0.1:10900;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}

location /ws2p {
    proxy_pass http://127.0.0.1:20900;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

error_page 403 404 500 502 503 504 @error_page;
location @error_page {
    root /usr/syno/share/nginx;
    rewrite (.*) /error.html break;
    allow all;
}

}

ah en ecrivant je viens de m’appercevoir que les ports etaits pas bon (un vieux copier coller d’ailleur :/)
les ports sont bien 10901 et 20901

Nicolas_Markovic · 26 July 2020 18:20

apres avoir utiliser le bridge (eth0) plutot que localhost et 0.0.0.0
çà fonctionne de nouveau et là magie g1.nikoserveur.com/network/peering fonctionne

par contre j’ai un « upgrade Required » sur la page 192.xxx.xxx.xxx.:20901 du serveur
c’est normal ?

elois · 26 July 2020 18:25

En théorie oui, en pratique ça ne fonctionne pas chez moi.

Ok,en 1ère lecture je ne vois rien qui pourrait poser problème, après je ne suis pas expert nginx.
Mais je pense que le soucis viens du fait que Duniter n’écoute pas sur 0.0.0.0.

elois · 26 July 2020 18:29

Nickel

Oui c’est normal c’est du websocket.
Je viens de tester, ton endpoint WS2P fonctionne bien :

Pour tester le fonctionnement d’une API en websocket j’utilise l’extension firefox “Simple Websocket Client”

Nicolas_Markovic · 26 July 2020 18:38

super merci de ton aide
c’est quoi ta clef public que je te paye un peu en june histoire de tester cesium sur mon noeud

elois · 26 July 2020 18:49

D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx

Nicolas_Markovic · 26 July 2020 18:51

yes t’as recu du coup ?

c’est normal que lors qu’on fait une connexion en wss:// avec l’extension que tu m’as dit
çà clos direct tout les autres personnes qui sont connecté ? (je regarde sur l’interface webstart)
j’ai remarqué quand t’as fait ton test et je l’ai fait aussi de mon coté et c’est direct
çà veux dire qu’il suffit de spammer le webSocket et clore toute les communications ?
c’est pas un peu un DDOS dangereux çà ? en prenant tout les ws2p public et tu les spam tous en meme temps

elois · 26 July 2020 19:38

Oui bien reçu tes 2 DU merci Je les ai transféré sur la clé 78ZwwgpgdH5uLZLbThUQH7LKwPgjMunYfLiCfUCySkM8, c’est la caisse de rémunération des contributeurs techniques, c’est mieux de donner à cette caisse

~~Non c’est un bug.~~

EDIT: a priori ce n’est pas un bug de Duniter, voir plus bas.

Après je n’ai pas envie d’améliorer WS2P car je compte remplacer entièrement cette API par WS2Pv2 qui a déjà été en grande partie implémentée par @HugoTrentesaux dans Dunitrust.
Donc je n’ai pas envie de corriger ce bug, je ne suis pas sûr qu’il soit exploitable si facilement en plus, mais si quelqu’un veut se pencher sur ce bug a ma place le code est là : app/modules/ws2p · dev · nodes / typescript / duniter · GitLab

elois · 26 July 2020 19:43

Je viens de tester sur mon noeud et je ne reproduis pas. Lorsque je requête wss://g1.librelois.fr/ws2p avec l’extension “Simple Websocket Client” ça ne coupe aucun connexion WS2P sur mon noeud.
Donc a priori ce n’est pas un bug de Duniter mais un problème dans ta conf réseau (ça peut-être nginx ou docker ou la conf duniter).

Après réflexion, depuis le temps que le code de WS2p n"a pas bougé, j’ai reployé ou migré plusieurs noeuds Duniter depuis et je n’ai jamais remarqué ce comportement, ça m’aurais sauté aux yeux comme toi @Nicolas_Markovic, donc je pense que c’est un comportement spécifique à ta conf, après pourquoi ? le mystère reste entier !

hexdump · 27 July 2020 17:29

Salut, je rebondis sur le sujet parce que j’ai des doutes sur la conf réseau. Comment je peux la tester ? Comment m’assurer globalement que mon nœud est fonctionnel ? En particulier, comment savoir si j’accepte bien les connexions WS2P ? J’essaie de connecter un client dessus ?

Merci !

Nicolas_Markovic · 27 July 2020 17:35

t’as quoi comme conf sur cette adresse :
http://192.168.xxx.xxx:9220/webmin/network/interfaces

voilà la mienne :

vit · 27 July 2020 19:17

Pour savoir si tu as activé le WS2P publique, tu regardes dans l’interface d’admin sur la page réseau si tu as des connections entrantes (incoming).

Pour savoir si ton nœud se connecte en WS2P à d’autres nœuds, tu regardes si tu vois des connections sortantes (outgoing ou outcoming).

WS2P est un protocole de connexion entre les nœuds qui n’est pas destiné aux clients.

Pour les clients, il faut :

Faire une synchro en ligne de commande en incluant les transactions. (--store-txs)
Activer l’API BMA sur un port publique
Pour tester, se connecter sur http://hostname:port/node/summary et admirer la réponse json.

Puis enfin :

Paramétrer Cesium pour utiliser ce noeud sur le port BMA.

hexdump · 27 July 2020 20:17

Ok, dans Accueil -> Réseau, je suppose que les connexions s’affichent entre pubkey et Legend ? C’est vide, 0 connexion. Pas terrible

Avec l’interface /webmin/network/interfaces, il y a des mentions d’un port 33316 (https://pastebin.com/e70CKtws). Mais mon fichier de conf (duniter_default/conf.json) contient

 "ws2p": {
  "uuid": "95c0c71b",
  "privateAccess": true,
  "publicAccess": true,
  "preferedOnly": false,
  "privilegedOnly": false,
  "upnp": false,
  "host": "0.0.0.0",
  "port": 20901,
  "remoteport": 20901,
  "remotehost": "hexdump.fr"
 }

J’ai fait la conf avec wizard network.
Je ne comprends pas pourquoi il y a une différence. J’ai déjà fait un restart, sans changement.

Au niveau logs, j’ai :

2020-07-27T19:57:08+00:00 - info: WS2P: Could not connect to peer 8iVdpXqF using `WS2P g1.duniter.org 443: WS2P connection timeout` 
2020-07-27T19:57:08+00:00 - debug: WS2P: init: failed connection
2020-07-27T19:58:46+00:00 - error: Error: timeout
at Timeout._onTimeout (/duniter/duniter/node_modules/nat-upnp/lib/nat-upnp/client.js:187:14)

Pourtant la sync sur g.duniter.org 443 a l’air de fonctionner.

vit · 28 July 2020 07:37

Comme je n’ai jamais réussi à faire fonctionner l’image docker officielle de Duniter correctement (méconnaissance de la conf réseau), et que je ne maîtrisais pas trop le réseau docker, je ne peux pas t’aider plus.

Ta conf Duniter semble bonne en tout cas…

Je te conseille de ne pas affronter deux problèmes à la fois (conf Duniter et conf docker) et d’installer Duniter avec le paquet Debian ou autre mais sans docker. Une fois ta conf Duniter fonctionnelle, tu sauras à quoi ressemble un nœud Duniter qui fonctionne.

Ensuite tu reprends Duniter dans docker et tu te concentres sur la conf docker pour arriver au même résultat. Une fois cela réussi, tu partages ici ta procédure Docker pour une installation plug’n play, ce sera une belle contribution !

Nicolas_Markovic · 29 July 2020 10:00

Avec l’interface /webmin/network/interfaces, il y a des mentions d’un port 33316 (https://pastebin.com/e70CKtws ). Mais mon fichier de conf (duniter_default/conf.json) contient

alors oui apres avoir vu ta conf , le port 33316 est pas bon
je crois que par defaut que l’image du container est definit pour ouvrir uniquement les port 9220 10901(bma) et 20901(ws2p)
donc tu doit te restreindre à ceux là (si je me trompe faut me le dire hin)
puis aussi donner l’acces local par le bridge docker donc via le eth0 du container docker (172.17.0.4)
parceque si tu garde localhost (127.0.0.1) dans la conf docker tu reste en local et çà boucle dans le container , donc inaccessible dans ton reseau local.

par contre sur ton serveur qui heberge le container tu peux faire un reverse proxy
pour faire correspondre les ports si tenté que tu souhaite garder le 33316 depuis l’exterieur

pour synthétisé
depuis internet port public que tu souhaite utiliser (pour moi 10901,20901,443) => dans ta box internet le routeur redirigé vers ton serveur (ip local de type 192.168.xxx.xxx) => ton serveur doit avoir un reverse proxy (nginx) qui redirige les ports recu vers localhost du serveur, et donc de fait vers docker, avec un nouveau port (ici on garde les meme : 10901,20901, j’ai en plus redirigé le 443 (https) vers 20901) => c’est donc mon serveur qui gere le https et non docker et renvoie en claire vers 20901 (http)

ou encore plus simple :(les ports public doit correspondre au serveur, qui doit correspondre au nginx qui doit correspondre aux ports du container docker)
c’est un tuyau quoi

hexdump · 29 July 2020 20:05

Ça, c’est que j’ai essayé de faire. En fait j’ai même essayé de me passer de nginx, j’ai mappé les ports 10901 et 20901 sur les mêmes de l’hôte. (et 9920 sur 127.0.0.1:9920).
Moi je ne comprends pas d’où sortent ces ports 33316. Je n’en veux pas, je n’ai rentré cette valeur nul part.

Pour être bien clair : dans ma box, j’ai mappé 10901 et 20901 sur server:10901 et server:20901. Dans server, j’ai lancé le docker comme suit :

docker run -d -p127.0.0.1:9220:9220 -p10901:10901 -p20901:20901 -v /srv/duniter/conf:/etc/duniter -v /srv/duniter/data:/var/lib/duniter --restart always --name duniter duniter/duniter

Enfin, j’ai (voulu) configurer les ports :

docker exec -it duniter duniter wizard network
? IPv4 interface eth0 172.17.0.4
? IPv6 interface None
? Port 10901
? Remote IPv4 Enter new one
? Remote IPv4 78.xxx.xxx.xxx
? Remote port 10901
? Does this server has a DNS name? Yes
? DNS name: monsite.fr.qui.resoud.en.78.xxx.xxx.xxx
2020-07-26T20:03:38+00:00 - debug: Configuration saved.

docker exec -it duniter duniter config --ws2p-public
docker exec -it duniter duniter config --ws2p-noupnp --ws2p-port 20901 --ws2p-host 0.0.0.0 --ws2p-remote-port 20901 --ws2p-remote-host monsite.fr

docker exec -it duniter duniter sync g1.duniter.org 443

Je pense que je fais refaire un essai de zéro. Ca c’est l’avantage de docker