konfedera.org

Prendre puis partager le pouvoir politique et monétaire

Réseau décentralisé avec Linux Debian

email Facebook Twitter
Màj : 24 mai 2022   –   # pages : 6 [?]

Introduction

https://konfedera.org/reseau-decentralise-debian#intro
Types de réseau

Les réseaux de télécommunication (dont Internet) sont essentiellement centralisés. Se pose alors la question : que se passerait-il si les serveurs de ces réseaux devenaient subitement inaccessibles (plus de GSM, plus d'email, plus de réseaux sociaux, plus d'accès à notre interface bancaire, etc.) ?

Pourrions-nous, à l'aide de nos seuls ordinateurs personnels, établir un réseau décentralisé (on dit également "pair-à-pair"), qui de proche en proche, permettrait de nous connecter avec des personnes éloignées, et de pouvoir au moins envoyer et recevoir des fichiers (texte, images, sons, ...) ? Et, dans une démarche plus ambitieuse, pourrions-nous ainsi poser les bases d'un futur "réseau konfédéral" ?

Pour approfondir l'anayse comparative entre réseau décentralisé et réseau centralisé (on dit également "client-serveur"), voir democratiedirecte.net/reseau-decentralise.

La réponse est oui ! Et l'objet du présent document est d'expliquer – de façon didactique, c-à-d compréhensible par tous – comment chacun de nous peut participer à la création d'un réseau décentralisé, en y joignant son ordinateur personnel. C'est également pour chacun l'occasion idéale pour sortir de l'analphabétisme digital. Pour ce faire, nous allons procéder progressivement.

LAN.jpg

ISP ("Internet Service Provider") ≡ FAI (Fournisseur d'Accès à Internet).

Protocole
expérimental

Environnement matériel et logiciel du présent apprentissage, à respecter pour garantir la reproductibilité des résultats :

  1. deux ordinateurs A et B (équipés d'une carte wifi), ainsi qu'un gateway (votre box de connexion à Internet) ;
  2. aucun câble ethernet ou DSL n'est branché sur les trois machines (A, B, gateway) ;
  3. chacun des ordinateurs A et B est équipé exclusivement du système d'exploitation Linux Debian (version la plus récente c-à-d 11).
    • Le choix de Debian se justifie par le fait que dans un réseau décentralisé, chaque noeud fonctionne à la fois comme client et comme serveur. Or Debian est précisément conçu dans cette optique.
    • Si vous n'avez pas encore libéré votre ordinateur, ne tardez par à le faire, car en cas de guerre mondiale ce pourrait être le seul moyen de télécommunication subsistant. Voici comment procéder : democratiedirecte.net/installer-linux-debian (voir également democratiedirecte.net/utiliser-linux-debian).
  4. NetworkManager et firewalld sont installés sur A et B.

Dans la suite du présent document certaines sections commenceront par mentionner des points à ajouter à ce protocole.

Notez enfin que le présent document a été créé récemment, et fait l'objet de fréquents ajouts et corrections. Consultez-le donc régulièrement (par exemple une fois par semaine).

Avant d'entrer dans le vif du sujet il reste à approfondir votre maîtrise du pare-feu.

Pare-feu

https://konfedera.org/reseau-decentralise-debian#pare-feu

Le pare-feu firewalld comprend neuf configurations de base, appelée "zones" et classées par ordre de sécurisation [source] :

  1. drop (protection "maximale")
    <zone target="DROP">
        <short>Drop</short>
        <description>Unsolicited incoming network packets are dropped. Incoming packets that are related to outgoing network connections are accepted. Outgoing network connections are allowed.</description>
    </zone>
  2. block
  3. public (configuration standard)
    <zone>
        <short>Public</short>
        <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
        <service name="ssh" />
        <service name="dhcpv6-client" />
    </zone>
  4. external
  5. dmz
  6. work
  7. home
  8. internal
  9. trusted (aucune protection)
    <zone target="ACCEPT">
        <short>Trusted</short>
        <description>All network connections are accepted.</description>
    </zone>

Deux commandes très utiles de firewalld sont :

  • # firewall-cmd --set-default-zone=votreZone
  • # firewall-cmd --get-default-zone

Deux principes de base de la gestion d'un pare-feu :

  • Il y a arbitrage entre sécurisation et permissivité : plus on augmente la permissivité du pare-feu, plus basse est la protection du système (PS : il résulte de ce même principe d'arbitrage, qu'il faut installer le moins de programmes possibles, voire n'installer les programmes peu utilisés que pour la durée de leur utilisation).
  • Il n'existe pas de configuration standard d'un pare-feu : la configuration doit être adaptée au profil de l'utilisateur du système. Idéalement, il faut donc commencer avec le niveau de protection maximale (drop) et le diminuer (le moins possible) si l'on voit que la zone courante est trop restrictive (c-à-d bloque certaines fonctions).

Il faut donc ajouter un élément dans notre protocole d'expérimentation de base (cf. section "#intro") : configurer la zone par défaut du pare-feu sur "drop". Notez que dans la suite du présent document certaines sections commenceront par mentionner la zone par défaut à utiliser dans le cas particulier de la section.

N.B. Le pare-feu n'est qu'un élément de la politique de sécurisation de votre ordinateur. Voir : democratiedirecte.net/utiliser-linux-debian#securisation

Nombreux sont les utilisateurs d'un pare-feu qui n'en ont jamais vu la preuve du fonctionnement. Les sections suivantes vont y remédier ...

Routeur

https://konfedera.org/reseau-decentralise-debian#routeur

Protocole expérimental supplémentaire pour cette section :

  1. installez le serveur web apache sur la machine A ;
  2. configurez la zone par défaut du pare-feu de A en "trusted" ;
  3. redémarrer A, et ensuite le gateway.

Soulignons qu'en raison de second point du protocole de base (cf. section "#intro"), vous n'avez pas accès à Internet. Votre gateway n'est donc plus qu'un simple routeur wifi (cf. illustration ci-dessous). Le système réseau qu'il forme avec A et B est appelé LAN ("local area network).

routeur.jpg

Vérifiez la présence du site web de A, en y accédant via le navigateur de A (NB : ce faisant vous visitez le site web de A, localement) :

  • soit via l'adresse IP de A associée à l'interface wifi, donnée par $ hostname -I ou encore $ /sbin/ifconfig ;
  • soit via le nom de domaine de A, donné par $ hostname -f.
  • Équivalent du navigateur en ligne de commande : $ wget.
  • L'adresse (IP ou nom de domaine) doit être précédée de http://. La commande wget l'ajoute automatiquement, tandis que certains navigateurs ajoutent https://, ce qui dans notre cas aura pour effet que la connection ne se fait pas (sauf à décocher cette option dans la configuration du navigateur).

Après avoir vérifié que chacune des machines A et B est connectée en wifi au routeur, constatez que :

  • vous pouvez visiter le site de A à partir de B ;

    Si l'accès en nom de domaine ne fonctionne pas, vérifiez que le pare-feu de A est bien en zone par défaut "trusted", puis rédémarrez A et ensuite le gateway.

  • il suffit d'augmenter le niveau de protection du pare-feu de A à la zone située juste au-dessus de "trusted" (soit "internal") pour que l'accès au site web soit rendu impossible à partir de l'extérieur de A (PS : rappelons cependant que pour maximiser la protection du système il faut préférer "drop" plutôt que "internal").

Focus sur le gateway

Deux fonctions serveur importantes de notre "routeur" sont :

  • la fonction de pare-feu entre le LAN et Internet (NB : le pare-feu du routeur ne protège que des connexions de l'extérieur qui passent par lui ⇒ tout ordinateur équipé d'une carte wifi doit donc impérativement comporter son propre pare-feu !).
  • la fonction DNS, qui consiste à associer un nom de domaine à une adresse IP. Sans cette fonction, dite de résolution de nom de domaine, la connexion au site de A ne serait possible qu'avec la seule adresse IP.

Un gateway est un ordinateur serveur assez simple, sans écran ni clavier. Il dispose d'un site web qui permet d'accéder à sa configuration via le navigateur de A ou de B. On peut trouver son adresse (souvent 192.168.1.1.) via la commande $ cat /etc/resolv.conf.

La page d'accueil du site web du routeur présente un formulaire d'accès, dans lequel il faut mentionner le mot de passe affiché sur le routeur.

Constatez enfin que, même en zone=drop (protection maximale), vous continuez d'accéder au site de A à partir de A, et au site du routeur à partir de A et B. Tout cela est logique puisque la fonction d'un pare-feu est de protéger l'accès à tout ou partie d'un machine, à partir de l'extérieur.

Ok, c'est très bien tout ça, mais nous sommes toujours ici dans le modèle client-serveur c-à-d centralisé. Cependant pour décentraliser un réseau, "il suffit" que chacun de ses noeuds soit à la fois client et serveur. Voilà qui nous conduit à la première étape de notre chemin vers la décentralisation : le wifi ad-hoc.

Wifi ad-hoc

https://konfedera.org/reseau-decentralise-debian#wifi-ad-hoc
wifi-ad-hoc

Adaptation du protocole expérimental : rétablissez la zone par défaut des deux pare-feu sur "drop" (protection maximale).

Passons donc maintenant à un stade basique de décentralisation : le wifi ad-hoc. Pour ce faire coupez le gateway ⇒ il n'existe plus. Vos deux ordinateurs sont donc maintenant (apparement) isolés (cf. ligne hachurée dans l'illustration ci-contre).

Et pourtant vous allez voir qu'il est très facile de les connecter, même sans câble (pour autant évidemment qu'ils soient équipés d'une carte wifi, ce qui est aujourd'hui la norme).

Pour ce faire, sur chacune des machines, installez dans /user/local/bin un fichier nommé par exemple kfnet, et comprenant le code suivant [source] :



#!/bin/sh
read -p  "Choisissez un numéro de canal entre 1 et 14 (de préférence 1, 6 ou 11) : " canal
ifconfig nomIfWifi down
iwconfig nomIfWifi channel $canal essid kfnet mode ad-hoc
ifconfig nomIfWifi up
ifconfig nomIfWifi adresseIP netmask 255.255.255.0 

NB : barre de défilement horizontal !

... ou vous aurez remplacé :

  • nomIfWifi par le nom de votre interface wifi, de type wlan0 ou wlp3s0, et que vous trouverez par $ /sbin/iw dev (NB : nomIfWifi peut varier selon la carte wifi) ;
  • adresseIP par 192.168.1.1 sur A, et par 192.168.1.2 sur B.

Enfin sur A et B activez le script kfnet : # kfnet (il vous sera demandé de spécifier un numéro de canal, comme vous pouvez le constater en lisant le script).

Voilà ! Essayons maintenant de nous connecter à la machine 192.168.1.1, en faisant $ ping 192.168.1.1 à partir de la machine 192.168.1.2 : ça ne fonctionne pas, le terminal semble "bloqué" (ctrl+c pour rétablir l'invite de commande). C'est donc que la configuration du firewall en zone=drop est trop restrictive ⇒ on essaie avec le niveau inférieur (zone=block), mais ça ne marche pas non plus (ping n'est pas "bloqué" mais le résultat affiché en faisant ctrl+c indique que zéro paquets ont été transférés) ⇒ on essaie avec le niveau encore inférieur (zone=public), et là ça marche : ping n'est pas bloqué, et le résultat du scan affiche un nombre de paquets reçus supérieur à zéro. On a donc ainsi trouvé la zone de protection optimale pour l'application ping.

N.B. Il arrive fréquemment qu'un canal soit saturé par d'autres utilisateurs (pour en voir la liste : $ /sbin/iwlist scan). Dans ce cas le résultat affiché après ctrl+c mentionnera que zéro paquets ont été reçus (malgré que la configuration du pare-feu est optimale). Dans ce cas relancez kfnet sur les deux machines, en spécifiant un autre (et identique) canal. Généralement, plusieurs tentatives sont requises avant de trouver un canal non saturé ...

ssh

Vérifions maintenant le bon fonctionnement du protocole ssh, qui permet de prendre le contrôle d'une machine A (sur laquelle est installé openssh-server), ... via une machine B (sur laquelle est installé openssh-client). Nous installerons cependant les versions client et serveur sur A et B, puisque notre objectif est de réaliser un réseau pair-à-pair, c-à-d où la situation des machines est symétrique, de sorte qu'elles constituent des noeuds.

Sur le terminal de B, l'utilisateur demande de prendre le contrôle de A :


B:~$ ssh 192.168.1.1
# il est demandé de mentionner le mot de passe d'utilisateur de A -->
A:~$ 

Domaine

Vérifions maintenant le fonctionnement de ping, wget et ssh en utilisant le nom de domaine au lieu de l'adresse IP. On constate alors que ça ne fonctionne pas : "Échec temporaire de la résolution de nom". Normal, puisque, comme évoqué dans la section précédente, la résolution de nom était assurée par le routeur, or celui-ci a été éteint. Nous devons donc gérer la résolution de noms sur A et B, en ajoutant dans /etc/hosts :

  • Sur A : 192.168.1.2 nomDomaineB
  • Sur B : 192.168.1.1 nomDomaineA
Stopper
ad-hoc

Soulignons enfin qu'il n'était pas nécessaire de fermer le gateway, c'était juste pour montrer qu'il ne joue ici aucun rôle. Si vous refaites l'expérience ci-dessus avec le gateway allumé (et le câble DSL branché), vous constaterez cependant que la dernière ligne du script kfnet a pour effet de couper les autres connexions (web, mail, ...). Pour rétablir la situation : # systemctl restart NetworkManager.

Bilan intermédiaire

https://konfedera.org/reseau-decentralise-debian#bilan-intermediare

Dans les sections précédentes, nous n'avons pas testé toutes les possibilités (six), que le tableau suivant énumère dans ses deux dernières colonnes.

ApplicationZone (*)routeurad-hoc
pingpublic
wgettrusted
sshpublic

(*) zone optimale pour l'application considérée.

Rappel : comme expliqué dans la section consacrée au pare-feu, en dehors de vos expérimentations de réseau décentralisé, configurez la zone par défaut de firewalld sur "drop" (protection "maximale").

Comme exercice de révision, le lecteur est vivement invité à (re)tester un par un ces six cas de figure (rappel : veillez à respecter le protocole expérimental !).

Applications

https://konfedera.org/reseau-decentralise-debian#applications

Cette section est probablement vouée à constituer la section finale du présent document. D'autres sections viendront s'intercaler avant.

 6.1. Prise de décision
 6.2. Monnaie libre

Prise de décision

https://konfedera.org/reseau-decentralise-debian#prise-de-decision

Focus sur Diaspora :

Monnaie libre

https://konfedera.org/reseau-decentralise-debian#monnaie-libre
Duniter

Je n'ai pas encore testé Duniter, système le plus abouti en matière de monnaie libre. Je l'ai cependant étudié de près à ses débuts : allocation-universelle.net/monnaie-libre.

J'encourage vivement les développeur de Duniter à entreprendre les démarches pour intégrer leur logiciel dans la distribution Linux Debian (voir wiki.debian.org/HowToPackageForDebian). À cet égard – et constatant que la carte d'identité électronique belge est déjà intégrée dans Debian [BeID] – espérons que des développeurs vont créer un module pour Duniter (voire, si nécessaire, un fork) afin de réaliser un système de monnaie directe qui pourra facilement être utilisable dans d'autres pays où la carte d'identité est déjà électronique.

n_check

Contact


konfedera.org

top-of-page.png