linux-debian.net

R&D : wifi p2p wan

Introduction

 1.1. Objectif
 1.2. Public
 1.3. Principes
 1.4. Environnement expérimental
 1.5. Défis

Objectif

Recherche expérimentale. Le présent document est un travail en cours, qui présente – de façon didactique – le résultat de mes expérimentations dans le domaine de la téléinformatique, et en particulier des réseaux wifi décentralisés (on dit aussi "distribués" ou encore "pair-à-pair", souvent noté par l'acronyme anglais "p2p").

Wi-Fi est le nom de la norme IEEE 802.11, la plus utilisée actuellement pour les réseaux sans fil.

Cette R&D s'inscrit dans mes travaux sur la théorie pratique de la démocratie directe, et en particulier la notion de DD "noire", c-à-d résolument fondée sur les technologies de l'information (et constituant ainsi une alternative à la DD "blanche" c-à-d sans informatique).

Public

Ce travail s'adresse aussi bien aux informaticiens qu'au citoyen lambda :

• les informaticiens sont invités à développer et perfectionner le présent travail initiateur ;
• le citoyen lambda est invité à participer à ce travail de R&D pour (i) développer sa culture générale de l'informatique et (ii) aider les informaticiens à concevoir l'infrastructure d'un système de DD adapté aux besoins de tous.

Apprentissage par expérimentation. Le lecteur non informaticien est vivement invité à reproduire les expérimentations exposées dans le présent document (et qui fonctionnent toutes, sauf mention contraire). Après la libération de votre ordinateur, c'est la meilleure autoformation que l'on puisse imaginer pour se libérer de l'analphabétisme informatique.

Principes

Méthode. Dans un premier temps, il ne s'agit pas de créer de nouveaux protocoles et programmes (développement), mais de vérifier par expérimentation s'il est possible de constituer une réseau décentralisé, par une configuration symétrique des programmes clients/serveurs installés sur tous les noeuds (site web, mail, etc).

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 serveur, distribuée sur chaque noeud".

Concrètement nous voulons que :

1. notre réseau puisse fonctionner :
   • sans câbles ni relais entre les noeuds ;

     Chaque noeud est donc un relais wifi. Il en résulte que la valeur de ce réseau (son utilité comme moyen de communication) augmente avec le nombre des noeuds connexes.

   • en distribuant sur les noeuds 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 ...
2. 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) ...
3. les messages transitant par un noeud ne puissent être lus par son propriétaire que s'il y est autorisé ...
4. chaque noeud soit mobile.

Le business modèle derrière ces objectifs est donc de privilégier la décentralisation du réseau plutôt que son étendue. Celle-ci étant fonction du rapport entre puissance des noeuds-bornes et distance entre ceux-ci, l'étendue de ce réseau wifi augmentera non seulement avec le nombre de noeuds, mais également avec le progrès technologique en matière de puissance (et de coût) des noeuds-bornes.

Symétrie. Nos expérimentations vont donc vérifier la pertinence de ce que nous appelons « 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 identiquement sur chaque noeud du réseau. Par identiquement, ou symétriquement, on entend que tous les noeuds comprennent les mêmes applications clientes et serveurs (pour ce qui est commun au réseau wifi p2p), et dont les configurations par défaut sont identiques. ».

Réseau d'individus ("une personne = un noeud"). Nous considérons ici le cas d'un réseau dont chaque noeud correspond à une seule personne physique. Ainsi soit deux ménages voisins : l'un est composé d'un couple avec deux enfants, l'autre d'une seule personne. Le réseau qu'ils constituent est donc composé de cinq personnes.

On voit ici qu'une propriété corollaire, et essentielle, de notre réseau est la totale mobilité de chacun de ses noeuds.

D'autre part, il résulte du principe de symétrie, que les clients se contactent via leurs serveurs respectifs. Enfin, pour maximiser la sécurité, sur chaque noeud du réseau décentralisé, le serveur-noeud est préférablement séparé physiquement du client-noeud (ce qui par ailleurs permet la mobilité de ce dernier).

Les principaux services gérés par le serveur sont notamment : boîte email, site web, pare-feu, DNS, routeur (nous étudierons et installerons chacun de ces services dans les sections suivantes).

Environnement expérimental

Environnement matériel et logiciel de nos expérimentations (NB : il importe de respecter ce protocole pour garantir la reproductibilité des résultats présentés ici) :

1. Deux ordinateurs A et B équipés d'une carte wifi (ce qui est la norme aujourd'hui) ;
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.

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 par expérimentation.

Conseils sécurité. Si, pour reproduire les expérimentations du présent document, vous utilisez votre machine habituelle (A) et une machine de réserve (B), n'installer des serveurs sur votre machine habituelle (A) que si cela est expressément demandé dans notre protocole.

Vous augmenterez encore d'un cran la sécurisation de votre système expérimental en fermant la fonction wifi de votre boîtier de connexion à Internet, et en n'y connectant que la machine A (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 wifi 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.

J'en profite pour souligner un fait important : si en pratique (c-à-d dans le cadre de cette expérimentation), les machines A et B de notre réseau élémentaire sont la propriété d'une même personne (l'expérimentateur), par contre, en théorie, chaque noeud est supposé être la propriété de personnes distinctes, et dont aucune ne connaît personnellement l'intégralité des autres. Les implications de ces faits, en matière de gestion du réseau (notamment la sécurisation), sont évidemment fondamentales.

Défis

Dans un réseau P2P les noeuds sont à la fois client et serveur. Or, dans un réseau centralisé, un serveur est par nature supposé vérifier les propriétés suivantes :

• fonctionnel en permanence ;
• son adresse IP est fixe ;
• son adresse est routable (adresses dites NAT) ; ... ;

Dans un réseau décentralisé, il faudrait que, même si ces propriétés ne sont pas vérifiées, chaque nœud puisse malgré tout :

• être à la fois client et serveur ;
• communiquer directement deux à deux ;
• contribuer, en fonction de ses capacités, au fonctionnement général de l’infrastructure P2P ;
• découvrir les noeuds dont ils recherche les ressources ; ... ;

Pour ce faire, un système P2P devrait comporter quatre composants fondamentaux [source p.219] :

1. une passerelle, qui publie l’adresse IP d’autres nœuds ;
2. un protocole réseau pour l’établissement des connexions et l’exécution des opérations de transport de données (NB : un élément crucial de ce protocole sera son aptitude au franchissement de coupes-feux) ;
3. un système d’annonces de ressources ;
4. un système symétrique du précédent, de recherche de ressources.

Pare-feu

Commençons par vérifier que firewalld fonctionne : # firewall-cmd --state

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>Les paquets réseau entrants non sollicités sont supprimés. Les paquets entrants liés aux connexions réseau sortantes sont acceptés. Les connexions réseau sortantes sont autorisées.</description>
   </zone>
2. block
3. public (configuration standard)
   <zone>
       <short>Public</short>
       <description>Pour une utilisation dans les espaces publics. Vous ne faites pas confiance aux autres ordinateurs sur les réseaux. Seules les connexions entrantes sélectionnées sont acceptées.</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>Toutes les connexions réseau (entrantes et sortantes) sont acceptées.</description>
   </zone>

Infos sur les zones :

• détaillée : manpages.debian.org ;
• résumé : # firewall-cmd --list-all-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 à utiliser impérativement, pour vérifier que vous avez configuré correctement votre pare-feu. N.B. Pour changer le niveau de protection d'une connexion, il faut passer par NetworkManager (qui gère les connexions) :
  • soit via l'interface graphique : Système > Internet et réseau > Configuration réseau avancée (ou $ nm-connection-editor) > sélectionnez la connexion > Général > Zone du pare-feu ;
  • soit en ligne de commande : # nmcli connection modify nomConnexion connection.zone votreZone

• Firewalld permet des réglages fins de sa configuration, notamment à la volée comme l'illustre cet exemple : # firewall-cmd --zone=public --add-service=ssh --timeout=5m. Pour approfondir : firewalld.org/documentation et fedoraproject.org/wiki/Firewalld.
• Résolution de problème : la commande suivante peut livrer des informations utiles : # nft list ruleset

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

• Tout ce qui n’est pas autorisé est interdit.
• 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é.
• Un pare feu doit être suivi et mis à jour (« Un pare-feu est configuré pour repousser certaines attaques en rejetant des paquets appartenant à des connexions suspectes. Ce faisant, il produit des fichiers de comptes rendus (logs) qui relatent les incidents. Il indispensable d’analyser le contenu de ces fichiers et de les confronter avec les avis publiés par les CERT. Ceci suppose des ingénieurs compétents pour ce faire, ce qu’oublient certaines entreprises qui se croient protégées en achetant (fort cher) un coupe-feu clés en mains, configuré avec des filtres pertinents à un instant donné mais périmés quinze jours plus tard, et qui se retrouvent ainsi dotés d’une magnifique ligne Maginot ») [source, p.255, édition 2024].

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é. 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'expérimentation (cf. supra "#environnement-experimental") : 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 active à utiliser dans le cas particulier de la section (la zone par défaut restant au niveau maximal Drop).

Wi-fi adhoc

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é.

Au moyen de NetworkManager nous allons configurer un réseau Adhoc entre A et B : Système > Préférences > Internet & Réseau > Configuration réseau avancée (ou $ nm-connection-editor) > cliquez sur le bouton + > sélectionnez un type de 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=adrX
• Paramètres IP6 : Méthode=Automatique

où (par exemple) :
• nomConnexion=wifip2p
• nomReseau=resexp
• adrA=10.42.0.1 (sur machA), adrB=10.42.0.2 (sur machB)

Une fois cela fait, il vous suffira désormais, pour vous connecter à votre réseau wifi ad-hoc, 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" > "wifip2p". Faites-le sur les machines A et B.

Voilà ! Les machines A et B sont maintenant connectées à notre réseau wifi ad-hoc, 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 B à partir de A : userA@machA:~$ ping 10.42.0.2. Si vous avez bien respecté notre protocole "pare-feu" de départ (zone="drop", soit la protection maximale), vous constatez que ça ne fonctionne pas : le terminal semble "bloqué" (ctrl+c pour rétablir l'invite de commande). C'est parce que la zone "drop" bloque toutes les connexions entrantes, comme le confirme l'analyse des ports :
root@machA:~# nmap -sV 10.42.0.2
(...)
Nmap scan report for machB.home (10.42.0.2)
All 1000 scanned ports on machB.home (10.42.0.2) are filtered .

On essaie alors avec le niveau de protection inférieur (zone=block) sur la machine B, mais ça ne marche pas non plus (ping n'est pas "bloqué" maOn essaie alors avec le nivis 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. Observons le changement dans l'analyse des ports :
root@machA:~# nmap -sV 10.42.0.2
(...)
Nmap scan report for machB.home (10.42.0.2)
Not shown: 999 filtered ports
PORT STATE SERVICE VERSION
22/tcp closed ssh .

DNS : Noms et adresses

Le DNS ("Domain name system" en anglais) est l'annuaire d'Internet. Comment allons-nous appliquer ce concept à notre réseau wifi p2p ?

Dans la section précédente, nous avons vu que, pour communiquer entre eux, les ordinateurs utilisent les adresses IP .

Cependant toutes les procédures ne sont pas automatiques : à un moment ou l'autre, un utilisateur humain doit mentionner une adresse. Or les humains mémorisent plus facilement des adresses alphabétiques, qui peuvent avoir une signification sémantique. Ce sont les noms de domaine (exemple : debian.org).

Pour ce faire il faut un système (appelé "Domain Name Server" ou DNS) qui associe chaque adresse IP à un nom de domaine (ou à plusieurs noms, via des alias), de sorte que lorsque l'utilisateur A veut aller sur le site nomB, le navigateur de A interroge automatiquement le DNS afin de connaître l'adrB associée à nomB.

On appelle "résolution de nom" le fait de déterminer l'adresse correspondant à un nom donné [source].

Dans Linux Debian la fonction DNS de base est assumée par le fichier /etc/hosts. Le tableau ci-dessous montre son contenu :

• en vert, la chaîne de caractère qui détermine le nom de domaine complet (FQDN) ;
• en rouge, la ligne que vous allez devoir ajouter pour pouvoir utiliser les noms de domaine au lieu des adresses IP dans notre réseau wifi p2p.

Machine A
127.0.0.1 localhost 127.0.1.1 nomA adrB nomB

Machine B
127.0.0.1 localhost 127.0.1.1 nomB adrA nomA

Avant de modifier /etc/hosts – pour vous faciliter la présente expérimentation – je vous invite à remplacer, sur chacune des deux machines A et B, le "nom d'hôte" (ou encore "nom de machine"), qu'il vous avait été demandé de mentionner lors de l'installation de Debian, et que vous pouvez vérifier par $ hostname.

Pour ce faire, dans /etc/hostname remplacez votre nom de machine par machX où X={A,B} : # nano /etc/hostname, puis redémarrez la machine. Ensuite modifiez les deux fichiers /etc/hosts afin d'obtenir le résultat suivant :

Machine A
127.0.0.1 localhost 127.0.1.1 machA.home   machA 10.42.0.2 machB

Machine B
127.0.0.1 localhost 127.0.1.1 machB.home   machB 10.42.0.1 machA

Rappel : c'est dans NetworkManager qu'est mentionnée l'adresse IP de chaque machine de notre réseau adhoc. Avec l'augmentation du nombre de noeuds, c'est donc le nombre de lignes rouges qui augmentera sur chaque machine.

Vérifiez maintenant les résultats suivants :

$ hostname
nomX
$ hostname -d
home
$ hostname -f
nomX.home

Remarques :

• Nous avons donc la chaîne causale suivante :
  /etc/hostname (définition du nom d'hôte) > /etc/hosts (association d'une adresse IP au nom complet).
  Ainsi nous aurons :
  $ hostname -i
  adrX

Sources :
• manpages.debian.org/.../hostname
• debian.org/.../handbook/sect.hostname-name-service
• debian.org/.../reference/ch05#_the_hostname_resolution

Une configuration plus simple (mais non recommandée par debian.org) permet de mieux comprendre le principe. Il s'agit de définir de nom de domaine complet dans /etc/hostname, et de ne pas faire suivre le nom complet par le nom d'hôte dans la ligne rouge de /etc/hosts

Réseau non
élémentaire

Dans un réseau p2p réel, le nombre d'utilisateurs peut être potentiellement très élevé (des milliards). Il faudra donc veiller à ce que soit assurées les fonctions nécessaires à la gestion d'un grand nombre d'utilisateurs. Nous traiterons ces problématiques "back end" après avoir vu les deux principales fonctions "front end" de notre réseau wifi p2p : site web et email.

La nature élémentaire de notre réseau expérimental apparaît dans le résultat de la commande traceroute :
userA@machA:~$ traceroute machB.home
traceroute to machB.home (10.42.0.2), 30 hops max, 60 byte packets
1 machB.home (10.42.0.2) 6.326 ms 7.400 ms 10.898 ms

Des entreprises telles que dyn.com fournissent un service de noms de domaines dynamiques, qui ajuste périodiquement l’adresse IP correspondant à votre nom de domaine.

Site web

Une fois le serveur web installé, il reste à y "placer" – virtuellement c-à-d via un lien – vos fichiers (html, css, js, php, ...), de sorte que vous pourrez les éditer dans /home/utilisateur/public_html/ :

1. faire de utilisateur le propriétaire du répertoire /var/www :
   # chown -R utilisateur:utilisateur /var/www
2. ajouter le droit x à l'utilisateur sur /var/www :
   # chmod -R u+x /var/www
3. création d’un lien symbolique (-s), sur /var/www, vers la cible /home/utilisateur/public_html :
   $ ln -s /home/utilisateur/public_html /var/www/html

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

• soit via l'adresse IP de B, donnée par $ hostname -i
• soit via le nom de domaine de B, donné par $ hostname -f

• Équivalent du navigateur en ligne de commande : $ wget.
• N.B. L'adresse (IP ou nom de domaine) doit être précédée de http://. Si vous ne le faites pas, 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.

Essayez maintenant d'aller sur le site de B à partir de la machine A, via $ wget et via le navigateur. Constatez que l'accès au site web de l'autre machine n'est pas possible si le pare-feu de cette dernière est configuré à un niveau de protection supérieur à "trusted" (le plus bas...). En effet, depuis notre ping de la section #wifi-adhoc, nous avions du abaisser la zone du pare-feu de B à "public", mais cela est encore trop restrictif ⇒ il faut abaisser la zone du pare-feu de B à "trusted".

Si A est votre machine habituelle, laissez la zone de son pare-feu sur "drop" (protection maximale). On n'expérimentera que sur la machine B.

Notez que si l'extension .home n'est pas indispensable pour visiter le site de la machine locale, il l'est pour visiter une autre machine. Cela vaut évidemment aussi bien pour le shell graphique (le navigateur) que pour le shell texte (wget).

Observons enfin l'analyse des ports :
root@machA:~# nmap -sV 10.42.0.2
(...)
Nmap scan report for machB.home (10.42.0.2)
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.54 ((Debian)) .

Insuffisant. Au niveau sécurité il faut souligner que cette configuration est insuffisante, surtout pour un réseau wifi p2p . Nous voulons certes que le site web de chaque machine de notre réseau 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 une chose à la fois ...

Courriel

Commençons par un peu de théorie. Le système de messagerie sur Internet est fondé sur deux types de protocole :

• 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 ? Pour répondre à cette question, observons le schéma suivant, qui représente en détails le fonctionnement traditionnel (client-serveur) du système email sur Internet. Il repose sur quatre fonctions, (... dont la plupart se retrouvent dans tout système postal) :

• Mail User Agent (MUA) : l'interface client pour lire et écrire le courrier ;
  • shell graphique : Evolution, Thunderbird, ... ;
  • shell texte : mutt
• Mail Submission Agent (MSA) : la boîte à lettres d'une agence postale ;
  • fonction généralement assurée par le MTA
• Mail Transfert Agent (MTA) : le réseau postal ;
  • exim, sendmail, xim4, postfix, ... ;
• Mail Delivery Agent (MDA) : le facteur déposant la lettre dans la boîte à lettres du destinataire.
  • procmail, dovecot,  ....

Les interface graphiques tels que Evolution et Thunderbird cumulent toutes ces fonctions (mais sont habituellement utilisés avec le serveur mail d'un FSI, le système Debian installé ne gère l'envoi de courriel qu'en local et ne permet pas d'envoyer des messages vers l'extérieur ni d'en recevoir de l'extérieur). Cependant, il est utile d'installer et de configurer un ensemble traditionnel MTA/MDA (par exemple exim4 et mutt). En effet, certains utilitaires du système [16] peuvent envoyer des messages importants sous forme de courriels à l'administrateur du système. L'agent de transport du courrier exim4, combinant les fonctions MTA et MDA, est un programme relativement petit mais très pratique. Par défaut, il est configuré pour n'envoyer des courriels que sur le système local. Les courriels adressés à l'administrateur (le compte root) sont envoyés à l'utilisateur créé pendant l'installation [source].

Selon le principe de symétrie propre au réseau p2p, chaque noeud devrait être également (symétriquement) équipé de ces fonctions. Dans ce qui suit, notre protocole d'expérimentation repose sur Evolution et postfix, qui à eux seuls vont donc assumer l'ensemble de ces fonctions.

DNS. Les MTA étant généralement configurés par défaut pour consulter des serveurs DNS plus sophistiqués que /etc/hosts (tels que dnsmasq ou bind), il faut forcer postfix à consulter ce dernier en ajoutant smtp_dns_support_level = disabled dans /etc/postfix/main.cf [source], puis faites # postfix reload.

Notre expérimentation d'exim4 a échoué car ce MTA ne permet pas d'utiliser /etc/hosts pour assurer la fonction DNS. J'ai tenté exim+dnsmasq puis exim+bind9 (chaque fois avec la configuration par défaut du serveur DNS), mais cela n'a pas suffit à résoudre le problème de résolution d'adresse. Ceci dit, je n'ai pas cherché plus loin, notamment pour la configuration de /etc/resolv.conf.

Vérifions maintenant, dans le terminal, que les deux machines peuvent envoyer et recevoir des emails :
Envoi :
userA@machA:~$ echo Salut | mail userB@machB.home
Réception :
userB@machB:~$ mail ⇒ sélectionnez le numéro du mail que vous voulez lire, ou $ cat /var/mail.usrX.

Pare-feu. La lectrice est invitée à vérifier que la réception n'est possible que si le niveau de protection du pare-feu de B est abaissé à "trusted", soit le niveau minimal ... (nous verrons plus loin comment augmenter la sécurisation de notre système email dans ce réseau wifi p2p).

Evolution

Comment envoyer et recevoir des mails via Evolution plutôt que via le terminal ? Après de nombreux essais-erreurs, je suis arrivé à la solution suivante. Il s'agit, sur chaque machine, de créer deux comptes mails : un pour les envois (dans votre boîte habituelle), et un pour les réceptions (dans une nouvelle boîte) :

• Envoi : Édition > Préférences > Ajouter :
  • adresse email : userX@machX.home (X=A sur machA, X=B sur machB) ;
  • serveurs :
    • réception : aucun;
    • envoi: SMTP, en mentionnant machX.home comme nom de serveur.
  • sécurité : aucune (nous traiterons de la sécurité dans la section suivante).
  • une fois le compte créé, marquez-le comme compte par défaut, sinon l'envoi via Evolution ne fonctionnera que si la connexion Internet (donc par câble) est également active.
• Réception : Édition > Préférences > Ajouter :
  • Nom du compte (qui apparaîtra dans la colonne de gauche d'Evolution, au-dessus de la boîte de réception de userX@machX.home, et qui est donc différente de votre boîte de réception habituelle) : par exemple "/var/mail/userX" ;
  • adresse email : userX@machX.home (X=A sur machA, X=B sur machB) ;
  • serveurs :
    • réception : "Ficher Unix standard de spool mail box" (sélectionnez /var/mail/userX);
    • envoi: aucun.
  • sécurité : aucune.

Voilà, c'est tout ! Nous pouvons donc envoyer et recevoir des emails d'une machine à l'autre, sans connexion à Internet, sans abonnement à quoi que ce soit !

Notez que nous n'avons pas besoin de MDA...

En cas de problèmes durant votre expérimentation du mail :

• check-list des points à vérifier :
  • /etc/hosts (lignes rouge et verte, cf. supra #DNS)
  • /etc/hostname (machX)
  • /etc/mailname (machX.home)
  • connexion adhoc (cf. #wifi-adhoc)
  • /etc/postfix/main.cf (smtp_dns_support_level = disabled)
  • reload postfix (après édition de /etc/postfix/main.cf)
  • config. Evolution (cf. supra)
• informations utiles dans # cat /var/log/mail.log

Sécurité

 7.1. Pare-feu adapté
 7.2. DMZ
 7.3. Cryptage

Un pare-feu adapté

Nous avons vu que les fonctions web (protocole HTTP) et mail (protocole SMTP) de notre réseau wifi p2p ne fonctionnent que si le niveau de protection du pare-feu est abaissée au niveau minimum ("trusted" : toutes les connexions entrantes sont acceptées). En terme de sécurité cette situation n'est évidemment pas tolérable. La première étape pour maximiser la sécurisation de notre réseau wifi p2p est la création d'une zone adaptée à nos besoins spécifiques.

Pour relever la protection de B à un niveau adapté à nos besoins, on va d'abord copier (sous un autre nom) le fichier de configuration de la zone "public" dans le répertoire des configurations personnalisées [source] :
# cp /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/wifip2pz.xml.

On l'édite alors pour le transformer comme suit :

Pour obtenir la liste des noms de services valides : $ firewall-cmd --get-services

Ensuite :

1. # firewall-cmd --reload et service NetworkManager restart
2. vérifiez que la zone wifip2pz :
   • est bien enregistrée : $ firewall-cmd --get-zones
   • est configurée selon nos besoins : $ firewall-cmd --zone=wifip2pz --list-services
3. relevez à "wifip2pz" le niveau de protection de la connexion active sur la machine B : # nmcli connection modify wifip2p connection.zone wifip2pz (cf. sections #pare-feu et #wifi-adhoc).

Vérifiez alors que fonctionnent toujours les fonctions web (cf. section #siteWeb) et courriel (cf. section #mail) :

• visite du site machB.home à partir de la machine A ;
• envoi d'un mail à userB@machB.home à partir de la machine A ;
• réception du mail sur la machine B.

Rappel. Si vous avez respecté notre protocole d'expérimentation, le niveau de protection de votre machine habituelle (A) a été maintenu au niveau maximum ("drop" : les paquets réseau entrants non sollicités sont bloqués ; il n'y a pas de réponse du serveur ; les paquets entrants liés aux connexions réseau sortantes sont acceptés ; les connexions réseau sortantes sont autorisées). Nous n'avons abaissé que le niveau de protection de la machine B (votre machine de réserve), laquelle n'est pas connectée à Internet. Ceci afin de sécuriser l'expérimentation, étant entendu que dans sa forme non expérimentale la configuration des noeuds de notre réseau wifi p2p est indentique (principe de symétrie).

Enfin le résultat de la commande suivante montre les potentialités de configuration fine de firewalld ... :

$ firewall-cmd --zone=wifip2pz --list-all
wifip2pz
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: http smtp
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

DMZ

Certains services doivent être accessibles de l’extérieur par nature, comme un serveur WWW, un relais de courrier électronique, un serveur DNS.

Le schéma suivant illustre le principe de la "zone démilitarisée" (acronyme anglais : DMZ) dans le paradigme traditionnel "client-serveur". La DMZ est une machine (réelle ou virtuelle), ou un sous-réseau, du réseau local (en bleu), mais isolé de celui-ci par une pare-feu. Ce dernier isole le tout d'Internet (en violet). La DMZ contient les services susceptibles d'être accédées depuis Internet (site web, mail, ...).

Le pare-feu (i) redirige par défaut tous les flux en provenance d'Internet vers la DMZ ; et (ii) bloque les accès au réseau local à partir de la DMZ. Ainsi, en cas de compromission d'un des services dans la DMZ, le pirate n'aura accès qu'aux machines de la DMZ et non au réseau local.

La technique DMZ n'est pas suffisante : elle doit être complétée par un système de détection d’intrusion (IDS).

Proxy. « Il est prudent que les serveurs en zone publique contiennent aussi peu de données que possible, et même idéalement pas du tout, pour éviter qu’elles soient la cible d’attaques. Ceci semble contradictoire avec le rôle même d’un accès à l’Internet, mais cette contradiction peut être résolue en divisant les fonctions. Ainsi pour un serveur de messagerie il est possible d’installer un relais en zone publique qui effectuera toutes les transactions avec le monde extérieur mais transmettra les messages proprement dit à un serveur en zone privée, inaccessible de l’extérieur, ce qui évitera que les messages soient stockés en zone publique en attendant que les destinataires en prennent connaissance. De même un serveur WWW pourra servir de façade pour un serveur de bases de données en zone privée. Ces serveurs en zone publique qui ne servent que de relais sont souvent nommés serveurs mandataires (proxy servers en anglais). (...) Le relayage entre zone publique et zone privée fonctionne aussi dans l’autre sens : l’utilisateur en zone privée remet son courrier électronique au serveur privé, qui l’envoie au relais en zone publique, qui l’enverra au destinataire. Pour consulter une page sur le WWW, l’utilisateur s’adresse au serveur relais qui émettra la vraie requête vers le monde extérieur. Ici le relayage peut procurer un autre avantage, celui de garder en mémoire cache les pages obtenues pendant un certain temps, pour les fournir au même utilisateur ou à un autre lorsqu’il les redemandera sans avoir à accéder à la source distante. » [source, p.254, édition 2024].

Routeur vs firewall. Un routeur doit décider au coup par coup du sort de chaque paquet individuel, avec très peu de possibilité d’analyse historique, un coupe-feu peut disposer d’informations plus complètes, peut garder des datagrammes en file d’attente jusqu’à reconstituer une séquence plus longue de la communication et en faire une analyse plus complète. Bien sûr ceci a un coût en termes de débit [source, p.254, édition 2024].

P2P

Dans le paradigme décentralisé (p2p), et plus particulièrement celui de notre réseau élémentaire expérimental composé de deux machines A et B, les machines bleues du schéma représentent notre machine B, et le routeur Internet (violet) représente la machine A (à partir de laquelle nous effectuons nos tests sur la machine B) !

Rappelons en outre qu'une des spécifications de notre réseau wifip2p est la mobilité des noeuds [#objectif], ce qui implique que le pare-feu et la DMZ devront être installés sur chaque noeud. Évidemment cette installation doit être séparée du système d'exploitation de la machine hôte :

À priori deux options se présentent : double amorçage ("dual boot") ou machine virtuelle (acronyme anglais VM). La cadre ci-dessous explique pourquoi la VM est la solution adaptée aux spécifications de notre réseau wifi p2p.

Nous avons déjà installé le pare-feu sur les machines A et B, mais pas sous forme de machine virtuelle (acronyme anglais VM). Il nous reste donc à réinstaller d'une part le pare-feu dans une MV, et d'autre part les serveurs web et mail dans une autre VM, le tout sur la même machine B.

Mais est-il nécessaire d'installer le pare-feu dans une VM ? Ainsi pourquoi le pare-feu n'est-il pas installé par défaut dans une VM ?

Systèmes possibles pour la virtualisation des composants de notre DMZ :

• wiki.debian.org/SystemVirtualization
  • wiki.debian.org/Xen
  • wiki.debian.org/LXC
  • wiki.debian.org/KVM
  • wiki.debian.org/QEMU
  • wiki.debian.org/VirtualBox
  • wiki.debian.org/Schroot
• debian.org/doc/manuals/debian-handbook/sect.virtualization
• debian.org/doc/manuals/debian-reference/ch09.fr.html#_virtualized_system
• en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software

Après avoir lu les références ci-dessus (août 2022), il apparaît que l'installation et la configuration d'un système DMZ en réseau wifi p2p représente un degré de complexité substantiellement supérieur aux précédentes sections, avec en outre de possibles problèmes aux niveaux matériel et logiciel. Est-ce le signe d'une technologie non mature, ... où de mes limites actuelles dans la maîtrise de Linux Debian ?

Dans un cas comme dans l'autre, il me paraît judicieux de "donner du temps au temps", en mettant cette section en attente. Peut-être ne sera-t-il pas nécessaire d'y revenir, s'il s'avère que GNUnet offre une solution "clés sur porte" (cf. infra section #cle-sur-porte).

Cryptage

Section en préparation...

Il s'agit notamment de garantir que les données circulant sur le réseau ne puissent être lues que par des ayants-droit. La notion d'ayant droit implique que la cryptographie est ici intrinsèquement liée à l'identification électronique des utilisateurs A et B.

La transformation opérée par un système de chiffrement repose sur deux éléments : une fonction mathématique (de transformation du texte) et une clé secrète. Seule une personne connaissant la fonction et possédant la clé peut effectuer la transformation inverse, qui transforme le texte chiffré en texte clair. C’est la même clé qui sert au chiffrement et au déchiffrement, et pour cette raison elle doit rester secrète. Les systèmes de chiffrement asymétrique utilisent deux clés – une pour chiffree, l'autre pour déchiffrer – ce qui permet de rendre publique la clé de chiffrement, puisque’elle ne permet pas le déchiffrement [source p.230].

OpenSSH est plus complet (intégré) que OpenSSL, avec des différences. OpenVPN est basé siu Openssl, et semble plus complet que Openssh.

Gestion du grand nombre

Section en préparation...

Notre réseau élémentaire est composé de deux personnes/noeuds. Mais idéalement ce réseau devrait pouvoir fonctionner avec des milliards d'utilisateurs/noeuds.

Il nous faudra pour cela des logiciels serveurs adaptés, capable de fonctionner de façon distribuée (c-à-d non centralisée) au niveau de la gestion :

• des noms de domaine : bind ? :
  • garantir qu'aucune adresse n'est utilisée par plusieurs personnes ... ;
• de l'authentification des utilisateurs : democratiedirecte.net/identification-authentification-internet ;
  • neutraliser les usurpations d'identité ... ;
• du routage : quagga ? :

  Si je comprends bien, un réseau totalement décentralisé (un noeud = une personne physique) devrait pouvoir se passer d'ISP et d'AS, et donc utiliser OSPF plutôt que BGP comme protocole de couche 3 du modèle OSI [source].

• ...

Distribution des fonctions serveur

Section en préparation...

• Topologie mesh
• OSPF

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. Monnaies libres et monnaie directe

Réseau pair-à-pair et serveur domestique

Je n'ai encore testé aucun des deux systèmes répertoriés ci-dessous. La fonction didactique du présent document est d'établir une connaissance pratique des principes élémentaires des réseaux wifi décentralisés. C'est sur base de cette compréhension que l'on pourra efficacement expérimenter les systèmes répertoriés ci-dessous.

	Site	Wikipedia	Debian
Réseau pair-à-pair	GNUnet	GNUnet	GNUnet
Seveur domestique	FreedomBox	FreedomBox	FreedomBox

• Réseau pair-à-pair : un site mesurant la taille et l'activité du Fédiverse : the-federation.info
• Serveur domestique : un serveur-noeud doit en principe être connecté 24h/24, n'est idéalement pas mobile, et enfin est préférablement séparé physiquement du client-noeud ; ⇒ le serveur-noeud est installé sur un mini PC.

Monnaies libres et monnaie directe

L'infrastructure Duniter (chaîne de blocs) est à ce jour le système le plus abouti en matière de monnaie libre.

Cependant, pour les raisons évoquées dans allocation-universelle.net/monnaies-electroniques#modele-decentralise, j'encourage vivement les développeur de Duniter à forker ou compléter Duniter afin de pouvoir appliquer, à la monnaie nationale de pays où la carte d'identité est déjà électronique, le principe de symétrie de la théorie relative de la monnaie (de sorte que la monnaie nationale devient alors une monnaie directe.

Les logiciels clients de la carte d'identité électronique belge sont déjà intégrés dans Debian [BeID]. Les développeurs de Duniter sont donc invités à entreprendre les démarches pour intégrer leur logiciel dans la distribution Linux Debian (voir wiki.debian.org/HowToPackageForDebian)