linux-debian.net

R&D : wifi p2p wan

Introduction

 1.1. Objectif
 1.2. Réseau d'individus
 1.3. Environnement expérimental

Objectif

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

Apprentissage par expérimentation. La lectrice est vivement invitée à 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.

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

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

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

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

Section en préparation...

Client-
serveur

Le schéma ci-contre 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.

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.

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. Monnaie libre

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.

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.