Manque de places WS2P sur le réseau Ğ1!

elois · 7 March 2018 00:56

La grande majorité des nœuds WS2P public sont plein, donc soit leurs quotas de connexions publiques sont trop faibles, soit c’est les quotas de connexion privés des autres qui sont trop fort (trop de demandes de connexion) !

J’invite les membres suivant a augmenter votre quota WS2P public car vous n’avez plus de place : Augmentez au moins à 25 voir 30 : Felipe @Vortex @Inso @aeris @Pafzedog @hacky @oaktree @myckeul @kimamila @Spyou @Patrice_F @Moul @nay4 @charles @Roco @binuts @sveyret.

*Si vous êtes sur arm ou/et en connexion très bas débit ne le faite pas, trop d’activité réseau pourrait vous empêcher de calculer dans le 1 er cas ou saturer votre ligne dans le 2ème cas.

J’invite également les membres qui ne font pas de WS2P Public, donc qui ne contribuent pas au réseau, a le faire, je pense notamment à MAximeGhesquiere (c quoi son compte forum?) @nanocryk @Paidge @jeanferreira @1000i100 si vous pensez avoir activé ws2p public ça ne fonctionne pas, revoyez votre config et demandez de l’aide ici si besoin

Pour tous ceux qui ont un noeud Duniter sur le réseau Ğ1 (cités comme non-cités) : Merci de réduire votre quota WS2P privé à 4 puis a redémarrer votre noeud. 4 c’est amplement suffisant pour avoir un noeud fonctionnel, et ça vous évite de prendre « trop de place sur le réseau ».

Je vois le nombre de nœuds Duniter augmenter, c’est bien, mais je vois en même temps le réseau WS2P ce saturer de plus en plus, il deviens de plus en plus difficile de se faire une place, je me permet donc de solliciter le plus grand nombre pour que la situation soit résolue bien avant que l’on ne se retrouve dans une situation de blocage.

Des conseils généraux pour tous :

Chaque fois que vous mettez en place un nouveau noeud Duniter sur le réseau, faites votre possible pour activer et faire fonctionner WS2P Public, je vois trop de nœuds en mode WS2P privé seulement, or tout le réseau repose sur WS2P Public !
Fixez un quota de WS2P Privé à 4. Car 3 ou moins peut vous désynchroniser, et plus c’est prendre de la place dont vous n’avez pas besoin.
Pour les nœuds WS2P publics fonctionnels depuis un certain temps (cad que vous voyez plein de connexions INCOMING dans votre vue réseau) : vous pouvez passer votre quota OUTCOMING a zéro, je l’ai fait pour mes 2 nœuds WS2P public en clair (1membre+1miroir), ça marche très bien, les connexions entrantes suffisent. En revanche, le jours ou vous modifiez votre endpoint il faudra repasser votre quota privé à 4 le temps que le réseau reçoive votre nouvelle fiche de peer.
Si vous avez des machines ou serveurs de dispo : Mettez en place un noeud mirroir acceptant beaucoup de connexions WS2P public, 30 voir plus, ça aide énormément le réseau !

J’aimerais bien trouver une solution a ce problème pour Duniter 1.7 : des idées ?

Déjà je propose de fixer dans le code la limite max de quota privé a 5, car plus c’est prendre une place non nécessaire.
Aussi je pense qu’il faut fixer le quota de connexions publiques par défaut à au moins 30 (sauf pour la release arm ou ça peut être moins).

Pour l’instant ça va encore, mais je préfère anticiper pour assurer la stabilité du réseau Ğ1

1000i100 · 7 March 2018 07:19

En effet, je pensais que ma config marchait en WS2P public.

Mes spécificités :
Duniter tourne derrière un reverse proxy nginx configuré comme suit :

server {
        listen 443 ssl http2;
        server_name duniter.g1.1000i100.fr;
        root /nowhere;
        location '/.well-known/acme-challenge' {
                root /var/www/demo;
        }
        location '/ws2p' {
                proxy_pass http://localhost:20801/;
        }
        location '/' {
                proxy_pass http://localhost:10900/;
        }
        ssl_certificate /etc/letsencrypt/live/future.agatas.org/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/future.agatas.org/privkey.pem; # managed by Certbot
        if ($scheme != "https") {
                return 301 https://$host$request_uri;
        } # managed by Certbot
}

Et le tout se trouve derrière un double NAT IPv4 avec le porte 443 redirigé pour pointer sur nginx au travers des 2 NAT.

PS : mon log Duniter : https://hastebin.com/ludeteqeqe

hacky · 7 March 2018 07:44

Hello.

Normalement c’est OK de mon côté pour g1.si7v.fr
J’ai passé le nombre de connexions publiques à 30, privées à 4 et j’ai configuré le ws2p public via mon reverse proxy.

Pierre

nanocryk · 7 March 2018 08:21

Er c’est bizarre on l’avait fait ensemble et je pensais que c’était bon. Je vais regarder ça.

Edit: Serieux je comprends pas, c’est la partie ou on a passé un bon moment dessus et ça marchait.

entropy :: ~/duniter % ./g1 ws2p show-conf                                                                                                                                                                                                                                    
{
 "uuid": "1152e46e",
 "privateAccess": true,
 "publicAccess": true,
 "upnp": false,
 "host": "127.0.0.1",
 "port": 20901,
 "remoteport": 443,
 "remotehost": "g1.duniter.nanocryk.fr"
}

Ma config nginx

server {
    #listen 80;
    listen 443 ssl;
   
    server_name g1.duniter.nanocryk.fr;
    
    ssl_certificate /etc/letsencrypt/live/g1.duniter.nanocryk.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/g1.duniter.nanocryk.fr/privkey.pem;
    ssl_stapling on;
    ssl_stapling_verify on;

    location /.well-known {
        alias /var/www/g1.duniter.nanocryk.fr/.well-known;
    }

    location / {
        proxy_pass http://127.0.0.1:10901;
        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:20901;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Inso · 7 March 2018 08:24

@moul, tu as pu valider le paquet yunohost pour la V1.6.21 ?

nanocryk · 7 March 2018 08:31

Ton

        if ($scheme != "https") {
                return 301 https://$host$request_uri;
        } # managed by Certbot

ne pourrait pas géner avec ws2p qui utilise le schema ws:// ou wws:// ?

Moul · 7 March 2018 08:37

Oui, c’est publié sur le dépôt et dans la liste des apps communautaires de YunoHost.

Inso · 7 March 2018 08:41

@elois : Je crois qu’on se demandent tous comment vérifier que WS2P est correctement configuré J’ai meme eu la question hier soir.

vincentux · 7 March 2018 08:48

Dans la vue réseau de Duniter-ui, on peut voir ça :

Et les détails API :

We have 4 types of WS2P Private:
CA : clear all
TM : tor mixed
TA : tor all
TS : tor strict

And two types of WS2P Public :
C clear endpoint
T tor endpoint

The WS2P Private is prefixed with an O and the ws2p public with an I, so the classic nodes will be of type WS2POCAIC.

Melua · 7 March 2018 09:35

Je pensais que c’était un maximum, mais ça veut dire que dans les fait cette valeur est toujours maintenue ?

cgeek · 7 March 2018 12:10

Un moyen simple : installer le plugin Simple WebSocket client pour Firefox/Chromium, entrer l’URL attendue. Par exemple, wss://g1.duniter.nanocryk.fr/ws2p, dont on peut voir après clic sur “Open” la réponse “CONNECT” de Duniter indiquant qu’on a bien réussi à joindre le noeud via WS2P :

nanocryk · 7 March 2018 12:16

Du coup il était bien config ? Je comprends plus rien x)

Sinon j’ai monté mon nombre de connexions à 50, ça devrait suffir ou je met plus ?

cgeek · 7 March 2018 12:36

D’un point de vue réseau oui, mais d’un point de vue déclaration non, il manque le paramètre de chemin “/ws2p” :

"endpoints": [
    "BASIC_MERKLED_API g1.duniter.nanocryk.fr 163.172.219.69 443",
    "WS2P 1152e46e g1.duniter.nanocryk.fr 443"
]

Pour corriger cela il te faudrait ajouter :

"remotepath": "/ws2p"

Dans la partie “ws2p” du fichier conf.json. Autrement dit, tu devrais avoir :

entropy :: ~/duniter % ./g1 ws2p show-conf                                                                                                                                                                                                                                    
{
 "uuid": "1152e46e",
 "privateAccess": true,
 "publicAccess": true,
 "upnp": false,
 "host": "127.0.0.1",
 "port": 20901,
 "remoteport": 443,
 "remotehost": "g1.duniter.nanocryk.fr",
 "remotepath": "/ws2p"
}

nanocryk · 7 March 2018 13:05

Ce qui est bizarre c’est que je l’avais fait avec elois et que ça marchait. Est-ce que les dernieres versions n’auraient pas reset certains paramètres ?

C’est bon maintenant ?

Eric1212 · 7 March 2018 13:19

Merci, c’est mis à jour de mon coté.

cgeek · 7 March 2018 13:29

Ça semble beaucoup mieux oui, des nœuds se connectent à toi :

elois · 7 March 2018 14:15

@1000i100 ça ne marche pas car tu traite ws2p comme si c’était du http:// alors que c’est du ws://, regarde la congif nginx de @nanocryk elle est bonne

@vincentux alors attention les infos de la colonne API ne font pas foi pour vérifier que WS2P fonctionne, comme @cgeek j’utilise l’extension firefox Simple Websocket Client, et je vous invite a faire de même

En revanche la colonne Free Rooms est un bon indicateur : si les 2 nombres sont différents c’est que ws2p public fonctionne, et s’il sont identiques et égaux au quota public c’est que ws2p public ne fonctionne pas, c’est comme ça que j’ai détecter qui a ws2p public qui ne fonctionne pas

Oui le noeud tente d’atteindre son quota maximal de connexions privés dans tout les cas.

Il est possible que le paramètre remotepath est été réinitialisé chez toi, il faudrait qu’on arrive a reproduire pour vérifier ça !

nanocryk · 7 March 2018 14:16

Comment je peux voir ça sans le webui ? sachant que mon noeud est sur une machine distante accédée en SSH.

elois · 7 March 2018 14:17

Ouvre un pont ssh puis :

curl localhost:9220/webmin/network/ws2p/info

level 1 = connexions OUTCOMING
level 2 = connexions INCOMING

nanocryk · 7 March 2018 14:20

Un pont ssh ? Cad me connecter ? En tout cas sur mon serveur ça me dit que la connection est refusée.