linux-debian.net

Contrôlez votre noeud dans le réseau de l'intelligence collective

Réseau décentralisé avec Linux Debian

email Facebook Twitter
Màj : 21 juin 2022   –   # pages : 13 [?]

N.B. Le présent document a été créé initié récemment, et fait l'objet de fréquents ajouts et corrections.

Introduction

https://linux-debian.net/reseau-decentralise-debian#intro
 1.1. Objectif
 1.2. Environnement
 1.3. Symétrie

Objectif

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" ou encore "distribué"), qui de proche en proche, permettrait de nous connecter avec des personnes éloignées, pour échanger des documents (fichiers texte, image, son, ...) ? 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 pratique et 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 se sortir de l'analphabétisme digital, grâce à notre méthode d'apprentissage par la pratique.

Concrètement nous voulons que :

  • notre réseau puisse fonctionner :
    • sans câbles ni relais entre les noeuds ;
    • sans les services indispensables actuellement fournis par des serveurs dédiés du web : routeurs, gestion collectives des adresses , serveurs mails, hébergement de sites web, forums ...
  • chaque membre du réseau (c-à-d chaque citoyen) puisse gérer sans intermédiaire son propre site web et service mail (boîtes in et out) ...
  • que les documents transitant par un noeud ne puisse être lus par son propriétaire que si celui-ci en est destinataire ...

Environnement

Environnement matériel et logiciel du présent apprentissage par la pratique (NB : il importe de respecter ce protocole pour garantir la reproductibilité des résultats) :

  1. Deux ordinateurs A et B équipés d'une carte wifi (ce qui est la norme aujourd'hui) ;

    La machine A pourrait être votre ordinateur habituel, et B votre ordinateur de secours. Notez que dans la pratique, ce dernier pourrait être la propriété d'un personne qui vous est inconnue, et habitant dans un autre pays.

  2. Chacun des ordinateurs A et B est équipé exclusivement du système d'exploitation Linux Debian (version la plus récente c-à-d 11) et du bureau Mate.
    • 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).
  3. NetworkManager et firewalld sont installés sur A et B. Par contre, dans un premier temps, n'installez pas openssh.
  4. Théoriquement on a plus besoin du gateway (votre boîtier de connexion à Internet), étant donné l'objectif du présent apprentissage. Cependant en pratique il vous sera évidemment utile de maintenir votre accès à Internet, ne serait-ce que pour pouvoir y faire des recherches dans le cadre du présent apprentissage. Cependant, afin d'éviter des confusions, il est vivement recommandé que la fonction wifi du routeur soit fermée, et que seul l'ordinateur A y soit connecté (donc par câble ethernet).
Réseau
élémentaire

L'approche du présent document repose sur la notion de "réseau élémentaire p2p", qui est « le plus petit réseau p2p (en nombre de noeuds) au moyen duquel on peut représenter un réseau p2p de taille quelconque ».

La fonction de cette notion de réseau élémentaire est de simplifier au maximum l'expérimentation ainsi que le présent manuel, que l'on pourrait qualifier de "théorie pratique des réseaux pair-à-pair".

En vertu du principe de simplicité, nous avons commencé à fixer à 2 la taille de notre réseau élémentaire p2p. Peut-être faudra-t-il passer à trois (voire plus ?). En vertu de ce même principe de simplicité nous n'augmenterons la taille de notre réseau élémentaire que si cela s'impose par la nature même des réseau p2p, ou pour des raisons didactiques.

Rappelons-ici au lecteur que le présent travail est une publication en édition continue (PEC), dont le rythme des mises à jour (corrections et ajouts) est quasiment quotidien.

Symétrie

Nous pouvons maintenant énoncer le premier principe du réseau décentralisé, à savoir le principe de symétrie : « les fonctions serveurs nécessaires au fonctionnement d'un réseau décentralisé sont distribuées entre les noeuds du réseau, tous les noeuds comprenant les mêmes applications clientes et serveurs, et dont les configurations par défaut sont identiques ».

  • Parmi les fonctions serveur il y a la boîte mail, un (voire des) site(s) web, ou encore un forum distribué.
  • On notera qu'une caractéristique essentielle du paradigme p2p est que la notion de serveur en tant que "machine dédiée" est remplacée par celle de "fonction distribuée sur les noeuds".

Cependant en pratique, afin de conserver le niveau de sécurité de votre machine habituelle (A), la plupart des serveurs étudiés ne seront installés que sur la machine B. Ainsi pour notre réseau élémentaire (deux noeuds), la plupart des tests d'accès aux serveurs ne seront donc réalisés que dans le sens AB (et les downloads dans le sens AB).

La première étape de notre aventure consiste à configurer le pare-feu.

Pare-feu

https://linux-debian.net/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 :

  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>

Infos sur les zones :

Il est possible de modifier la configuration d'une zone, et d'en créer de nouvelles. Cette utilisation avancée du pare-feu n'est pas abordée dans le présent document (pour cela voir la page de manuel firewalld.zones). On considère donc que les configurations des zones de firewalld sont celles présentent à l'installation de firewalld.

Quelques applications très utiles de la commande firewall-cmd :

  • # firewall-cmd --set-default-zone=votreZone
  • # firewall-cmd --get-default-zone
  • # firewall-cmd --get-active-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.
  • Il n'existe pas de configuration standard d'un pare-feu : celle-ci doit être adaptée au type de programme utilisé.

Il résulte de ces deux principes que le pare-feu doit être configuré par défaut au niveau de protection maximale ("drop"), et abaissé lorsqu'on utilise une fonction requérant plus de permissivité (par exemple la suppression d'un paquet requiert la zone "public"). Pour trouver la zone de protection optimale d'une fonction, c-à-d la zone lui assurant une protection maximale sans la bloquer, il faut donc commencer avec le niveau de protection maximale (drop), puis le diminuer progressivement jusqu'à la zone qui ne la bloque pas.

Nous allons donc ajouter un élément dans notre environnement d'apprentissage (cf. supra "#environnement") : configurer la zone par défaut des deux pares-feu sur "drop". 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.

firewall-router.jpg

Fonction et méthodes d'un pare-feu

Fonction

La fonction d'un logiciel de "pare-feu" ("firewall" en anglais) est de filtrer les flux de communication entre une machine et l'extérieur (Internet).

Pour interpréter l'illustration ci-jointe dans le cadre du paradigme pair-à-pair, il faut voir les surfaces "firewall", "router" et "web site" comme des fonctions dont les logiciels sont installés sur un même noeud.

Méthodes

Ce filtrage peut opérer simultanément sur divers éléments : adresses IP, port (exemples : HTTP ⇒ port 80 ; FTP ⇒ ports 20/21 ; mail-out ⇒ port 465 ; mail-in ⇒ port 110 ; etc), ...

Ainsi le lecteur attentif aura compris que l'illustration concerne le filtrage de paquets du protocole HTTP.

N.B. Le pare-feu n'est qu'un élément de la politique de sécurisation de votre ordinateur. D'autres éléments sont la formation des utilisateurs, la gestion des mots de passe, ou encore la mise à jour des logiciels. Approfondir : 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 ...

Wi-fi adhoc

https://linux-debian.net/reseau-decentralise-debian#wifi-adhoc

Nous allons maintenant connecter A et B en mode Adhoc. Nous montrons ici deux méthodes : via NetworkManager et via le terminal.

Réseau Wifi ad hoc

Un réseau Wifi ad hoc (ou WANET pour "wireless ad hoc network") est un type décentralisé de réseau sans fil. Le réseau est ad hoc car il ne repose pas sur une infrastructure préexistante, comme des routeurs dans les réseaux câblés ou des points d'accès dans les réseaux sans fil. Au lieu de cela, chaque nœud participe au routage en transmettant des données à d'autres nœuds, de sorte que la détermination des nœuds qui transfèrent les données est effectuée dynamiquement sur la base de la connectivité réseau et de l'algorithme de routage utilisé.

NetworkManager

Via nm-connection-editor (Système > Préférences > Internet & Réseau > Configuration réseau avancée), ajoutez une connexion Wi-Fi ⇒

  • Nom de la connexion : nomConnexion ;
  • Wi-Fi : SSID=nomReseau ; Mode= Adhoc ;
  • Sécurité Wi-Fi : Sécurité=WPA et WPA2 personnel ;
  • Paramètres IP4 : Méthode=Manuel ; Adresse=AdresseIP ; Masque=255.255.255.0

où (par exemple) :
nomConnexion=kn
nomReseau=kfnet
AdresseIP(A)=10.42.0.1, adresseIP(B)=10.42.0.2

Une fois cela fait, il vous suffira désormais, pour vous connecter à votre réseau kfnet, de cliquer sur l'icône de NetworkManager dans la barre des icônes du bureau Mate > "Se connecter à un réseau Wi-Fi invisible" > "Connexion" > "kn". Faites-le sur les machines A et B.

Voilà ! Les machines A et B sont maintenant connectées au réseau kfnet, et peuvent ainsi communiquer.

Terminal

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 10.42.0.1 sur A, et par 10.42.0.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à ! Les machines A et B sont maintenant connectées au réseau kfnet, et peuvent ainsi communiquer.

Test

Un moyen simple de vérifier que le réseau est opérationnel consiste à scanner les ports d'une machine à partir de l'autre. On peut le faire au moyen de la commande ping. Scannons A à partir de B : $ ping 10.42.0.1. Si vous avez bien respecté notre protocole, vous constatez que ç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.

  • Échec. 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. 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é. Ce problème n'existe pas en cas de connexion via NetworkManager (c'est évidemment l'intérêt d'un tel programme sophistiqué que de gérer efficacement ce type de problème, et bien d'autres).

  • Confusion. Lorsque vous êtes connecté à un réseau (kfnet ou Internet), il n'est plus possible d'accéder à l'autre (sauf, probablement, si votre machine est équipée d'une seconde carte wifi). Pour éviter toute confusion pendant le présent apprentissage, décocher la case "Général" > "Se connecter automatiquement" dans la configuration NetworkManager de votre connexion ethernet à Internet.

Bilan

Nous venons de réaliser un grand pas vers la décentralisation, mais il reste encore quelques étapes majeures avant d'obtenir un réseau décentralisé. En effet, l'utilisateur de A et celui de B (rappel : A et B sont théoriquement deux personnes différentes, et ne se connaissant pas nécessairement) ont du convenir de leurs adresses IP respectives. Cela n'est évidemment pas réaliste dans un grand réseau dont les membres ne se connaissent pas nécessairement à priori. La solution consiste à fournir aux noeuds un service de gestion collective des adresses IP (il s'agit notamment d'éviter qu'une même adresse soit utilisée par différents noeuds). En outre, ce service devra être distribué sur l'ensemble des noeuds (puisque nous souhaitons éviter toute forme de centralisation). Cette distribution étant complexe à gérer, nous n'allons pas développer maintenant la question de la gestion des adresses IP. Avant cela il nous faut présenter des notions préalables ...

Site web

https://linux-debian.net/reseau-decentralise-debian#site-web

Environnement :

  1. installez le serveur web apache sur la machine A ;
  2. configurez la zone par défaut du pare-feu de A en "trusted" ;

    N.B. Nous vous avons donc mâché le travail : en effet, il faut commencer le test d'un nouveau service au niveau de protection maximale du pare-feu (zone par défaut : "drop") ⇒ si le service est bloqué par le pare-feu ⇒ abaissez le niveau jusqu'à la zone optimale pour ce service.

  3. connectez les deux machines en wifi adhoc.

Une fois cela fait, vérifiez localement la présence du site web de A, en y accédant via le navigateur de A :

  • 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).

Domaine

Mais ce que nous visons c'est évidemment de pouvoir visiter le site web d'un noeud à partir d'une autre noeud. On peut vérifier qu'il est possible de visiter le site web de B à partir de A, du moins en utilisant l'adresse IP (de B). Pour que cela fonctionne également au moyen du nom de domaine, il nous faut "résoudre le nom de domaine" de B (c-à-d l'associer à son adresse IP) sur la machine A. Pour cela il suffit d'ajouter la ligne 10.42.0.2 nomDomaineB dans le fichier /etc/hosts de A (NB : remplacez nomDomaineB par sa valeur).

Fonction DNS

La fonction "Domain Name Server" (DNS) assure la résolution de nom de domaine, qui consiste à associer un nom de domaine à une adresse IP (PS : ce sont les adresses IP que les machines utilisent, mais les humains mémorisent plus facilement des noms de domaines).

Dans notre réseau élémentaire à deux machines, la fonction DNS est assurée de façon basique par le fichier /etc/hosts, dont le tableau suivant montre le contenu pour chacune des machines A et B de notre réseau élémentaire.

Machine AMachine B
127.0.0.1localhost
127.0.1.1nomDomaineA
adresseIpBnomDomaineB
127.0.0.1localhost
127.0.1.1nomDomaineB
adresseIpAnomDomaineA

nomDomaineX (FQDN) est : défini à la ligne 127.0.1.1.

Il suffit donc d'ajouter la troisième ligne : # nano /etc/hosts.

Pare-feu

Si l'on se connecte à notre réseau élémentaire via NetworkManager plutôt que via le terminal (script kfnet), alors l'accès au site web est bloqué (wget donne "Connexion refusée"). La raison en est la zone spéciale de firewalld /usr/lib/firewalld/zones/nm-shared.xml dont le descriptif est « This zone is used internally by NetworkManager when activating a profile that uses connection sharing and doesn't have an explicit firewall zone set. Block all traffic to the local machine except ICMP, ICMPv6, DHCP and DNS. Allow all forwarded traffic ». Il faut donc, dans NetworkManager de la machine hébergeant le site web, configurer la connexion wifi ad-hoc en zone "trusted" de façon explicite plutôt que par défaut (la zone par défaut de firewalld pouvant alors être laissée sur "drop", zone de protection "maximale") :

  • via l'interface graphique : Système > Internet et réseau > Configuration réseau avancée > double-cliquez sur le nom du réseau wifi ad-hoc (pour sa création, voir supra #wifi-adhoc) > Général > Zone du pare-feu ;
  • en ligne de commande : # nmcli connection modify nomConnexion connection.zone trusted

Exercice pour comprendre la différence entre zone "par défaut" et zone "active" (NB : une seule connexion possible par carte réseau). Configurez votre connexion à notre réseau élémentaire en zone du pare-feu égale à "Par défaut" puis "trusted". Pour chacune de ces configurations, comparez le résultat de # firewall-cmd --get-active-zone. Constatez que ces informations peuvent également être obtenues par # nft list ruleset.

Insuffisant. Il faut cependant souligner que cette configuration est insuffisante pour un réseau p2p en wifi. Nous voudrions que le site web de chaque machine de notre réseau p2p en wifi ad-hoc soit librement accessible (en lecture seulement) par n’importe quel noeud de ce réseau ... mais tout en bloquant l’accès à tout le reste de la machine. Il faudrait donc une DMZ au sein de chaque machine. Nous développerons plus loin ce point très important. Mais avant il nous faut d'abord traiter un autre protocole qui, avec http, constitue l'un des principaux services finals d'un réseau : le mail.

Courriel

https://linux-debian.net/reseau-decentralise-debian#mail

Le courriel est fondé sur deux protocoles :

  • SMTP pour l'envoi des messages vers un serveur mail,
  • POP ou IMAP pour la réception à partir du serveur mail.

Comment installer et configurer un système email entre A et B. Le graphique suivant – qui représente le fonctionnement du système sur Internet – suggère qu'il "suffit" d'installer un MTA sur A et B, puis de les configurer symétriquement.

Principes du fonctionnement de l'email (4 étapes)

email-schema.jpg

MUA : "Mail User Agent" ; MTA : "Mail Transfert Agent" ;
• "expéditeur" loue son adresse email à domaine1.com ; "destinataire" loue son adresse email à domaine2.org.

Chaque MTA, ou serveur des messagerie, serait donc à la fois serveur de boîte sortante (SMTP) et de boîte entrante (POP ou IMAP).

Pour vérifier si cette voie est pertinente on installe exim4 sur A et B, puis on y configure /etc/exim4/update-exim4.conf.conf en mode "Envoi par relais (smarthost) — réception SMTP ou fetchmail" au moyen de # dpkg-reconfigure exim4-config. Les machines A et B sont configurées symétriquement. Voici la config de A :

Après avoir vérifié au moyen de ping que les deux machines sont bien connectées à notre réseau wifi ad-hoc, envoyons un message de A vers B : A:$ echo "Salut" | mail utilisateurB@nomDomaineB.

Malheureusement, sur B, aucun mail n'arrive ⇒ vérifions le log d'exim4 sur A :

Si j'envoie le mail à l'adresse utilisateurB@adresseIpB (au lieu de utilisateurB@nomDomaineB), le log d'exim4 est de même type (nomDomaineB étant remplacé par adresseIpB).

Bonne nouvelle : les deux MTA se parlent. Mauvaise nouvelle : le log d'exim4 de A indique qu'il y a un problème de routage au niveau de B ⇒ vérifions le log d'exim4 sur B :

Pourtant la machine B dispose de toute l'information requise pour opérer correctement le routage...

À SUIVRE...

Applications

https://linux-debian.net/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. Réseau pair-à-pair et serveur domestique
 6.2. Monnaie libre

Réseau pair-à-pair et serveur domestique

Je n'ai encore testé aucun des deux systèmes répertoriés ci-dessous. Le but du présent document est d'établir une connaissance pratique des principes élémentaires des réseaux décentralisés. C'est sur base de cette compréhension que l'on pourra exploiter pleinement de tels systèmes.

SiteWikipediaDebian
Réseau pair-à-pair GNUnet GNUnet GNUnet
Seveur domestique FreedomBox FreedomBox FreedomBox

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

linux-debian.net
menu.jpg

Une publication de François Jortay

top-of-page.png