Bitmessage/Soucis : Différence entre versions
De WikiOpenTruc
(→Forward du port 8444) |
m (→Forward du port 8444) |
||
Ligne 18 : | Ligne 18 : | ||
... | ... | ||
udp 0 0 0.0.0.0:8444 0.0.0.0:* | udp 0 0 0.0.0.0:8444 0.0.0.0:* | ||
− | |||
</pre> | </pre> | ||
− | |||
Ligne 36 : | Ligne 34 : | ||
* même passer, via les paramètres du routeur, l'adresse IP du raspberry concerné en DMZ (https://fr.wikipedia.org/wiki/Zone_d%C3%A9militaris%C3%A9e_(informatique)), ne change rien | * même passer, via les paramètres du routeur, l'adresse IP du raspberry concerné en DMZ (https://fr.wikipedia.org/wiki/Zone_d%C3%A9militaris%C3%A9e_(informatique)), ne change rien | ||
− | + | * https://bitmessage.org/forum/index.php?topic=3658.msg7636#msg7636 suggère de vider et/ou recopier knownnodes.dat | |
Version du 31 décembre 2017 à 13:10
Forward du port 8444
- a yellow light would mean that you only have outgoing connections, but no incoming.
- ce qui signifie aussi que BM fonctionne uniquement en mode client, ie n'est de facto pas un noeud
- you may have to configure port-forwarding on your router, to forward port 8444 from wan to port 8444 on the computer running the bitmessage-client.
- https://portforward.com/huawei/e5573s/ a priori indique la bonne démarche ... mais le voyant reste jaune
- http://openmyip.com/Huawei-E5573-router-setup idem
- http://www.portchecktool.com/ me dit cependant Problem! I could not see your service on monip on port (8444). Reason: Connection timed out.
- cela veut dire que le port n'est pas ouvert/forwardé ?
- à noter que, après avoir réalisé le forward du port 8444 sur le routeur, cela n'apparait pas sur le RPI avec netstat -a. Je dois lancer le service (ie python bitmessagemain.py) pour que les lignes suivantes apparaissent :
# netstat -a | grep 8444 tcp 0 0 0.0.0.0:8444 0.0.0.0:* LISTEN ... udp 0 0 0.0.0.0:8444 0.0.0.0:*
- est-ce que les ports sont fermés par défaut sur raspberry ?
- si oui, comment ?
- Vous pouvez vous servir de gufw pour configurer vos ports (transmission). https://packages.debian.org/fr/stretch/gufw gufw pourrait-il être utile ?
- https://doc.ubuntu-fr.org/iptables
- semble dire qu'il faut encore maniper sur le raspberry pour autoriser le trafic
- uPnP coché ou pas, ça ne change rien
- lancer bitmessagemain.py en su ne change rien
- même passer, via les paramètres du routeur, l'adresse IP du raspberry concerné en DMZ (https://fr.wikipedia.org/wiki/Zone_d%C3%A9militaris%C3%A9e_(informatique)), ne change rien
- https://bitmessage.org/forum/index.php?topic=3658.msg7636#msg7636 suggère de vider et/ou recopier knownnodes.dat
Fausse piste :
- a priori, IP fixe ou dynamique, BM s'en fout
- a priori, avant de vouloir faire du port forwarding, il faudrait (à vérifier ?) déjà que la machine concernée ait une adresse IP fixe, et a priori ce n'est pas le cas
- https://raspberrypi.stackexchange.com/questions/37920/how-do-i-set-up-networking-wifi-static-ip-address/74428#74428
- https://www.modmypi.com/blog/how-to-give-your-raspberry-pi-a-static-ip-address-update
- https://thepihut.com/blogs/raspberry-pi-tutorials/16683276-how-to-setup-a-static-ip-address-on-your-raspberry-pi
mode portable
Je fais tourner BM sur clé USB. Et j'ai bien coché le mode portable dans les paramètres. Tous les fichiers de travail vont bien dans /PyBitmessage/src, sauf pybitmessage.conf qui persiste à rester dans ~/.config/pybitmessage
IPs en clair dans le code source
- il y a des IPs en clair dans le code source. a priori il s'agirait des noeuds de bootstrap. Un attaquant du réseau Bitmessage pourrait cibler ces IPs (attaque DoS ou autre).
- NB : Les IPs 2017 ne sont pas les mêmes qu'en 2013.
- on ne peut pas exclure que ces IPs soient des honey pots ?
- comment pourrait-on contourner ce souci ?