Bitmessage/Soucis : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
m (Forward du port 8444)
m (Forward du port 8444)
Ligne 21 : Ligne 21 :
 
* il y a aussi l'éventualité qu'un firewall (ou une impossibilité technique) soit présent en amont, ie chez mon fournisseur free ?
 
* il y a aussi l'éventualité qu'un firewall (ou une impossibilité technique) soit présent en amont, ie chez mon fournisseur free ?
 
** http://forum.universfreebox.com/viewtopic.php?t=64899 , http://forum.universfreebox.com/viewtopic.php?t=67127 ... Free 4G ne permettrait pas l'ouverture de ports
 
** http://forum.universfreebox.com/viewtopic.php?t=64899 , http://forum.universfreebox.com/viewtopic.php?t=67127 ... Free 4G ne permettrait pas l'ouverture de ports
 +
** http://www.universfreebox.com/article/38490/Molotov-TV-fait-un-clin-d-il-au-forfait-4G-illimitee-de-Free-Mobile-le-jour-ou-tu-as-arrete-de-flipper
 
** c'est un peu compréhensible. Basiquement, c'est une offre pour de la téléphonie mobile, gracieusement étendue avec 100Go/mois de data (permettant de l'internet avec PC etc). Basiquement, c'est pas ciblé pour faire du serveur. Et en plus, comme l'allocation d'IPs est dynamique, ça complique techniquement la redirection de ports.
 
** c'est un peu compréhensible. Basiquement, c'est une offre pour de la téléphonie mobile, gracieusement étendue avec 100Go/mois de data (permettant de l'internet avec PC etc). Basiquement, c'est pas ciblé pour faire du serveur. Et en plus, comme l'allocation d'IPs est dynamique, ça complique techniquement la redirection de ports.
 +
** a priori, ça concerne tous les opérateurs, pas juste Free
 
** bref -> voir : [[Serveur]]
 
** bref -> voir : [[Serveur]]
  

Version du 1 janvier 2018 à 11:30

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
  • J'ai paramétré le routeur censément comme il faut pour le port 8444 (et uniquement celui-là), http://www.portchecktool.com/ me dit cependant :
    • Problem! I could not see your service on monip on port (8444). Reason: Connection timed out.
    • Problem! I could not see your service on monip on port (8555). Reason: Connection timed out.
    • a priori, cela semble signifier que le paramétrage du routeur pour le port 8444 est sans effet ?




  • à 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 ?




Fausse piste :


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 ?
  • Il faut noter que ces noeuds de bootstrap ne servent normalement qu'une seule fois, lors du 1° lancement de bitmessage. Dès ce 1° lancement, un fichier knownodes.dat est créé et copieusement garni, et c'est lui qui fournira des noeuds.

There are three mechanisms Bitmessage uses to learn of nodes.

1. about 10 are hardcoded. These are only used when you run the client the first time or when you delete your knownNodes.dat file.

2. DNS bootstrapping. On startup, Bitmessage looks up the DNS A-records for bootstrap8080.bitmessage.org and bootstrap8444.bitmessage.org and adds those to its list. This is very much like method #1 except that I don't have to update the source code to update the list of peers.

3. After the client is connected to another peer, peers share nodes using addr messages. This is continuously updated. At this point the first two methods really aren't important at all; the knownNodes list will grow plenty big using this third method. (Max 20K peers in the list).

If your client doesn't hear that a peer is active and cannot connect to it for two days then it removes it from the list until you have less than 1000 peers in your list at which point it stops removing them.