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

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 :slight_smile:

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 :slight_smile:

9 J'aime

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

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

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";
    }
}
1 J'aime

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

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:// ?

1 J'aime

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

3 J'aime

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

1 J'aime

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.

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

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 :

image

2 J'aime

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 ?

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"
}
1 J'aime

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 ?

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

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

1 J'aime

@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 :wink:

@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 :slight_smile:

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 :wink:

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 !

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

Ouvre un pont ssh puis :

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

level 1 = connexions OUTCOMING
level 2 = connexions INCOMING

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