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).
Ce travail s'adresse aussi bien aux informaticiens qu'au citoyen lambda :
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.
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 :
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.
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).
Décentraliser, c'est distribuer les fonctions serveur sur chaque noeud. Un noeud est donc composé d'un client-noeud et d'un serveur-noeud.
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 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) :
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.
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).
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.
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 :
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 :
Pour ce faire, un système P2P devrait comporter quatre composants fondamentaux [source p.219] :
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 :
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 :
Quelques principes de base de la gestion d'un pare-feu :
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).
Fonction et méthodes d'un pare-feu
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.
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 : /utiliser#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 ...
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 > :
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.
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
.
Protocoles radio
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 :
Machine A | ||||||
---|---|---|---|---|---|---|
|
Machine B | ||||||
---|---|---|---|---|---|---|
|
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 | ||||||
---|---|---|---|---|---|---|
|
Machine B | ||||||
---|---|---|---|---|---|---|
|
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 :
$ hostnameRemarques :
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
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.
Environnement :
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/ :
Une fois cela fait, vérifiez localement la présence du site web de B, en y accédant via le navigateur de B :
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.
Site web de la machB apparaissant dans le navigateur de machA. Notez que le navigateur (Firefox) n'affiche pas le http:// avant le nom du site, malgré qu'il a fallu l'entrer.
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 ...
Environnement :
N.B. Durant l'installation il vous sera proposé un série de configurations par défaut. Acceptez les toutes, en veillant à ce que la première soit "Internet".
Commençons par un peu de théorie. Le système de messagerie sur Internet est fondé sur deux types de protocole :
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) :
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].
Principes du fonctionnement de l'email [schéma : zestedesavoir.com]
NB : la trajet des flèches SMTP est initié par l'expéditeur, tandis que que la flèche POP/IMAP est initiée par le destinataire.
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).
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) :
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 :
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 :
Vérifiez alors que fonctionnent toujours les fonctions web (cf. section #siteWeb) et courriel (cf. section #mail) :
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:
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, ...).
Source, p.253, édition 2024.
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].
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.
double amorçage vs machine virtuelle
La notion de "machine virtuelle" regroupe différentes abstractions simulant des machines virtuelles de manière plus ou moins indépendante du matériel. On peut ainsi obtenir, sur un seul ordinateur physique, plusieurs systèmes fonctionnant en même temps et de manière isolée. Cette technique permet notamment d'héberger des services distincts sur des machines (virtuelles) distinctes pour des raisons de sécurité.
En double amorçage, si l'un des systèmes est contaminé par un virus, alors l'ensemble du PC peut l'être également. Dans une VM, cet inconvénient est (en principe) neutralisé, car la VM fonctionne dans un "bac à sable" ("sandbox") : le système d'exploitation virtualisé s'exécute dans un environnement complètement isolé et, par conséquent, ce que vous faites dans le système d'exploitation virtualisé n'affectera pas le système d'exploitation natif.
D'autre part le double amorçage n'est pas simultané : on ne peut utiliser en même temps les deux systèmes, ce qui ne correspond pas aux besoins de notre réseau wifi distribué : en principe votre site web, et surtout votre serveur mail, devraient être opérationnels lorsque vous utilisez votre ordinateur.
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 :
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).
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.
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 :
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].
Section en préparation...
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 domestiqueJe 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 |
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.
Auteur : F. Jortay | Contact : | Suivre : infolettre