Tous mes serveurs duniter-v2s fonctionnent bien, mais il reste un point que je n’arrive pas à régler.
Pour les noeuds Validator; dans la documentation il est marqué de ne pas utiliser WebSocket pour le port libp2p 30333 - et quand je tente de mapper sans web-socket, le Reverse Proxy https ne fonctionne pas (pas moyen d’arriver à avoir une connection ipfs et le serveur ne mentionne pas de découverte d’adresse correcte disponible)
Si je configure le noeud avec WebSocket (listen sur son port container 30333 en WebSocket et déclare adresse publique du reverse proxy sur port 443 en WebSocketSecured)
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443/wss
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws
=> le serveur découvre une adresse publique avec la même adresse et ipfs passe bien
Si je configure le noeud sans WebSocket; j’ai tenté plusieurs multiaddr différentes, je n’ai pas réussi à faire fonctionner:
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443/tls
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443/https
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/443/tls/http
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
Aucune de ces options ne découvre une adresse publique et pas moyen de connecter avec ipfs
Du coup, pour le moment, je me suis résigné à ne pas faire de reverse proxy pour le noeud Validator et juste exposer en http; mais si quelqu’un à une manière de le configurer correctement; je suis preneur.
# (Dans ce cas-ci, j'expose publiquement le port avec 0.0.0.0:30334:30333)
DUNITER_PUBLIC_ADDR=/dns/smith.gdev.de.brussels.ovh/tcp/30334
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333
Et autre question, il y a une raison pour laquelle on ne peut pas utiliser WebSocket pour les noeuds Validator ?
On déconseille d’exposer l’API RPC des nœuds validateurs pour réduire la surface d’attaque et leur charge de travail, et surtout parce que leur administration (rotate keys) nécessite d’autoriser les appels RPC unsafe. Alors un moyen simple pour établir une connexion sécurisée est un tunnel SSH.
Si ton reverse proxy ajoute une authentification c’est envisageable, et la configuration est identique à celle d’un miroir.
Dans Apache le reverse proxy se configure de la même manière pour HTTP/WS et pour HTTPS/WSS :
<Location /http>
ProxyPass http://127.0.0.1:9933/
</Location>
<Location /ws>
ProxyPass ws://127.0.0.1:9944/
</Location>
Je parle ici du reverse proxy pour le port libp2p 30333; pour le nœud validator je n’expose effectivement pas le port RPC 9944.
Aussi, je ne pense pas que ce soucis-ci soit dû à ma configuration du reverse proxy dans NGinx; vu que la même configuration fonctionne si je configure en WebSocket (et NGinx supporte les 2)
Peux tu citer ? Moi la seule occurrence de “websocket” que je vois dit l’inverse :
The libp2p listen address. See libp2p documentation. This variable is useful when running a validator node behind a reverse proxy, to force the P2P end point in websocket mode with:
DUNITER_LISTEN_ADDR=/ip4/0.0.0.0/tcp/30333/ws
Certes, mais là il ne parle pas de l’API RPC, il parle de l’API p2p.
Comment faire passer la connexion p2p en https sans WebSocket?
À mon avis la réponse est : ce n’est pas possible.
Websocket permet de recycler un socket de connexion http pour y faire passer des données brutes, mais ne permet pas d’avoir une connexion TCP brute. En effet, la connexion TCP dans ce cas est “utilisée” pour la première requête http.
Donc si tu ne veux pas écouter directement sur TCP (pourquoi ?), il faut que tu spécifies que tu veux gérer du websocket. Et il y avait au début une contre-indication pour les nœuds validateur, mais finalement ils se sont rendus compte que c’était bien géré et n’induisait pas de problème de perf. Par contre si tu fais ça, il faut avoir en tête que toute interruption nginx risquera de causer l’injoignabilité de ton validateur, ce qui n’est pas souhaitable.
Effectivement, je n’avais pas lu en détail cette partie là, mais juste à côté, dans la colonne “Default” il y a:
Non validator node: /ip4/0.0.0.0/tcp/30333/ws
Validator node: /ip4/0.0.0.0/tcp/30333
Du coup il faudrait peut-être corriger cette partie là, et je peux donc utiliser WebSocket également pour le noeud Validator 
1 Like
C’est ça, la colonne “default” indique le comportement par défaut. L’idée est qu’un light client p2p dans le navigateur pourra se connecter à tous les nœuds websocket (par défaut uniquement les nœuds miroir), mais que si on veut rendre son nœud validateur accessible via websocket, il faut le préciser explicitement.
1 Like