FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Les protocoles TCP et UDP pour les débutants

11 janvier 2022 à 16:55

I. Présentation

Dans ce tutoriel, nous allons découvrir les protocoles UDP et TCP, deux protocoles indispensables lorsque l'on s'intéresse au fonctionnement des réseaux informatiques.

Les protocoles TCP et UDP sont présents au sein de la couche "Transport" (ou couche n°4) du modèle OSI, ce qui va permettre de déterminer comment les données seront échangées entre deux hôtes. L'objectif de cet article est de vous proposer une introduction à ces deux protocoles afin de comprendre l'essentiel, tout en illustrant mes propos avec des analyses de trames réseau obtenues à partir du logiciel Wireshark.

Note : si vous souhaitez effectuer des analyses de trame pour tester de votre côté, vous devez installer Wireshark sur votre machine. Voici le lien vers le site officiel : Télécharger Wireshark.

II. Le protocole TCP

TCP signifie Transmission Control Protocol, et il s'agit d'un protocole orienté connexion. Le protocole TCP est très utilisé lorsque l'on utilise des protocoles IP, c'est pour cela que l'on parle aussi de TCP/IP.

Avec le protocole TCP, avant que des données soient échangées entre les deux hôtes, l'hôte source va créer une session de connexion avec l'hôte distant afin de le prévenir qu'il va recevoir des données. Pour cela, un premier échange aura lieu entre les deux hôtes (voir détails ci-dessous).

Une fois que la connexion est établie, l'échange de  données peut commencer. Pendant cet échange de données, les paquets (correspondants aux données) sont envoyés dans l'ordre, et le protocole TCP va s'assurer que tous les paquets sont bien transmis, et si ce n'est pas le cas, il est capable de renvoyer les paquets manquants. C'est l'un des avantages du protocole TCP.

Cette connexion sera maintenue jusqu'à ce qu'elle soit fermée, ce qui signifie qu'elle sera active à minima jusqu'à la fin de l'échange de données entre les deux hôtes. Elle peut être maintenue afin d'être prête dès que les deux hôtes auront besoin de communiquer ensemble.

En complément du contrôle des flux et de la gestion des erreurs, le protocole TCP est capable de contrôler la congestion du réseau sur lequel les paquets sont échangés. Un algorithme de contrôle de congestion est utilisé et en cas de surcharge du réseau, le flux TCP sera adapté en conséquence.

Il faut retenir que TCP va permettre d'établir une connexion fiable entre les deux hôtes pour s'assurer que les données sont correctement reçues par l'hôte distant.

A. Les protocoles qui utilisent TCP

TCP est le protocole de transport le plus utilisé sur Internet et chaque protocole applicatif a besoin d'utiliser un protocole de transport, dont TCP et UDP font partie. Il est difficile d'établir une liste exhaustive des protocoles qui s'appuient sur TCP pour le transport.

Néanmoins, voici la liste de quelques protocoles populaires qui s'appuient sur TCP :

  • Les protocoles HTTP et HTTPS, notamment pour charger le contenu des sites Internet
  • Le protocole SMTP pour envoyer des e-mails
  • Le protocole NFS pour transférer des données (sur certaines versions uniquement)
  • Le protocole SMB pour transférer des données
  • Les protocoles SSH et Telnet pour la gestion à distance d'un équipement
  • Le protocole RDP pour l'administration d'un hôte via le Bureau à distance
  • Le protocole LDAP pour interroger un annuaire comme l'Active Directory

Vous l'avez compris, TCP est un protocole que l'on utilise tous les jours au travers d'applications diverses et variées. Vous verrez également qu'UDP joue un rôle important au quotidien.

B. Fonctionnement d'une connexion TCP

Pour établir une connexion TCP, trois étapes sont nécessaires alors on parle d'un processus "three-way handshake". Ces trois étapes correspondent à trois paquets TCP : SYN, SYN-ACK et ACK. Ces termes correspondent à des flags (des marqueurs) que l'on peut retrouver au sein des paquets TCP.

L'initialisation d'une connexion TCP entre deux hôtes se schématise de cette façon :

TCP three-way handshake

Le paquet TCP SYN correspond à une demande d'initialisation de connexion envoyée par un client à un serveur, tout en sachant que SYN signifie "Synchronized". Ensuite, le serveur répond avec un paquet TCP SYN-ACK pour initier la connexion dans l'autre sens (SYN) et indiquer au client qu'il a bien reçu la demande de connexion (ACK pour Acknowledge). Enfin, le client répond au serveur avec un paquet TCP ACK pour accuser réception de la demande de connexion (Acknowledge). La connexion TCP est établie en mode full-duplex, c'est-à-dire dans les deux sens.

Note : des numéros de séquence sont associés aux différents échanges TCP afin de pouvoir suivre les connexions. En cas de perte de paquets, c'est grâce à ce suivi des numéros de séquence, incrémenté au fur et à mesure de l'échange, que TCP est capable de réémettre les paquets manquants. Chaque échange contient deux numéros : un numéro de séquence et un numéro d'acquittement (ack).

Pour fermer une connexion TCP, il y a deux méthodes : la méthode propre (ou normale, disons) qui consiste à envoyer un paquet TCP FIN à l'hôte distant pour lui demander de fermer la connexion aussi de son côté. En attendant sa réponse, on reste à l'écoute, notamment le temps qu'il indique que la connexion peut être fermée et les ressources libérées. Le serveur va envoyer un paquet TCP ACK puis ensuite TCP FIN (lorsque la connexion sera prête à être fermée côté serveur), et enfin le client répondra par TCP ACK : la connexion sera fermée des deux côtés.

Lorsque la connexion TCP ne peut pas être terminée proprement (par exemple : une coupure réseau entre les deux hôtes, un bug pendant la session, etc.), il existe une autre solution qui consiste à forcer la fermeture de la connexion TCP via un paquet TCP RST. On peut dire que l'on essaie d'avertir l'hôte distant que l'on ne répondra plus à ses requêtes pour cette connexion et qu'elle va être fermée.

C. TCP : capture de trafic HTTP

Pour voir dans la pratique comment se déroul une session TCP, on peut utiliser un logiciel de capture de paquets réseau, tel que Wireshark. Pour générer une connexion TCP, nous allons nous connecter sur un site Internet via le protocole HTTP (ou HTTPS).

Au lancement du logiciel, il est nécessaire de cliquer sur le menu "Capture" puis "Options" afin de sélectionner l'interface réseau, ici "Ethernet0", mais aussi pour définir un filtre. Pour que notre capture ne soit pas polluée et que l'on récupère uniquement ce qui concerne la connexion au site Internet, on va ajouter un filtre sur l'adresse IP du serveur qui héberge le site Internet (en l'occurrence une machine virtuelle sur mon réseau local dans cet exemple). Ce filtre sur l'adresse IP "192.168.100.120", aussi en source et destination sera :

ip src 192.168.100.120 or ip dst 192.168.100.120

Le filtre "ip src" permet de définir un filtre sur l'adresse IP source, tandis que le filtre "ip dst" permet de filtrer sur l'adresse IP de destination. Le fait d'indiquer "or" permet d'inclure une condition "ou" afin de capture les échanges entre notre machine locale et le serveur Web distant.

Une fois que c'est fait, cliquez sur "Démarrer" pour débuter la capture.

Wireshark : filtre sur une adresse IP source et destination
Wireshark : filtre sur une adresse IP source et destination

Dans le même temps, on accède au site Internet situé à l'adresse "192.168.100.120" à partir d'un navigateur. Au sein de Wireshark, on peut voir une dizaine de paquets apparaître. Il est temps d'arrêter la capture afin de l'analyser en cliquant sur le bouton "stop" en haut à gauche.

Wireshark : communication en HTTP entre un client et un serveur web
Wireshark : communication en HTTP entre un client et un serveur web

La colonne "Protocol" donne des indications sur le protocole repéré au sein de chaque paquet capturé. On remarque la présence de deux protocoles HTTP et TCP.

Wireshark : paquets TCP et HTTP lors de la connexion à un site Internet via HTTP
Wireshark : paquets TCP et HTTP lors de la connexion à un site Internet via HTTP

On remarque également que les premiers paquets sont uniquement en TCP : cet échange de quelques paquets TCP correspond à l'initialisation de la connexion afin de permettre le transfert de données dans les deux sens.

On peut voir le paquet n°1 (le numéro de paquet est indiqué sur la première colonne) où notre hôte local (192.168.100.101) envoie une requête TCP "SYN" à destination du serveur Web (192.168.100.120). Ensuite, le paquet n°2 correspond à la réponse du serveur Web à notre hôte local afin d'initier la connexion, d'où le TCP "SYN, ACK" pour lui dire qu'il a bien reçu sa demande. Enfin, le paquet n°3 correspond à une nouvelle réponse TCP "ACK" de l'hôte local vers le serveur Web : la connexion est établie.

Wireshark : plusieurs connexions TCP initiées
Wireshark : plusieurs connexions TCP initiées

Note : il ne faut pas confondre les numéros de paquets Wireshark avec les numéros de séquences et d'acquittement évoqués précédemment. Les numéros de paquets dans Wireshark n'ont pas de réelles significations, si ce n'est permettre de classer les paquets chronologiquement.

En regardant la capture d'écran ci-dessus, on peut avoir l'impression que la connexion TCP est initialisée plusieurs fois. Disons que c'est bien le cas dans le sens où plusieurs connexions TCP sont montées en parallèle afin de transférer plusieurs fichiers en même temps : ce qui est fort utile sur les pages où il y a de nombreux éléments, à savoir des images, des feuilles de style CSS, etc.

Au sein de Wireshark, chaque connexion TCP est associée à un numéro de stream que l'on peut afficher en regardant le champ "Stream index".

Wireshark : le champ "Stream index" d'une connexion TCP
Wireshark : le champ "Stream index" d'une connexion TCP

Une fois la connexion TCP établie, les données sont transférées. Chaque paquet HTTP est suivi d'un paquet TCP "ACK" : l'hôte local demande la ressource au serveur Web (paquet n°7), et ce dernier lui répond "OK, j'ai bien reçu ta demande" (paquet n°8) et il commence à lui retourner les données (paquet n°9). Ensuite, l'hôte local confirme au serveur Web qu'il a bien reçu les données via une réponse TCP "ACK" (paquet n°10).

En complément, au sein de chaque paquet HTTP, on peut voir qu'il y a un en-tête TCP, ce qui prouve que le protocole HTTP utilise bien le protocole TCP pour le transport des données.

Présence d'une en-tête TCP dans les paquets HTTP
Présence d'un en-tête TCP dans les paquets HTTP

Passons maintenant à la découverte du protocole UDP.

III. Le protocole UDP

UDP signifie User Datagram Protocol, et il s'agit d'un protocole de communication sans connexion. Le protocole UDP est une alternative au protocole TCP.

Lorsque le protocole UDP est utilisé pour transporter les données, il va envoyer les données d'un hôte source vers un hôte de destination, sans chercher à savoir si l'hôte de destination a bien reçu l'ensemble des données. Autrement dit, il n'y a pas de vérification des erreurs : si l'on envoie un fichier via UDP, on ne sait pas si l'hôte distant a reçu entièrement ce fichier ou s'il l'a reçu partiellement.

Note : lorsque l'on parle du protocole UDP, on évoque le principe du "fire and forget" c'est-à-dire "tire et oublie" puisqu'avec UDP on envoie les paquets puis on ne s'en occupe plus, comme si on avait oublié qu'un paquet avait été envoyé.

Puisque l'on ne vérifie pas que l'hôte distant a bien reçu les données, on économise des ressources, mais aussi du temps, donc le protocole UDP est plus rapide que le protocole TCP.

L'en-tête d'un segment UDP contient très peu de champs : le port source, le port de destination, la longueur totale du segment, la somme de contrôle (pour vérifier l'intégrité du segment envoyé par le réseau) et les données.

A. Les protocoles qui utilisent UDP

Voici quelques exemples de protocoles qui utilisent UDP comme protocole de transport, tout en sachant que cette liste n'est pas exhaustive.

  • Le protocole DNS pour la résolution des noms (même si TCP peut être utilisé dans de rares cas)
  • Le protocole SNMP pour la supervision des équipements
  • Le protocole NTP pour la mise à jour de la date et l'heure via le réseau
  • Le protocole TFTP pour le transfert de fichiers simplifié

Au quotidien, on utilise le protocole DNS pour naviguer sur Internet afin de résoudre les noms des sites que l'on souhaite visiter. Cette résolution de noms s'effectue via le protocole de transport UDP.

Lorsque l'on regarde un flux vidéo en streaming, ce flux est transporté via le protocole UDP, car cela permet d'alléger la charge côté serveur et que c'est adapté à cet usage. Pour lire un flux diffusé par un serveur, le protocole UDP est idéal. Généralement, les protocoles qui utilisent UDP le font, car si un paquet est perdu ce n'est pas critique pour le reste de la transmission. Par exemple, s'il y a une perte d'une image lors de la lecture d'un flux en streaming, cela n'est pas grave et passera inaperçu.

B. UDP : capture de trafic DNS

Sur le même principe que pour le protocole TCP, nous allons réaliser une capture de paquets avec Wireshark. Cette fois-ci, le protocole DNS sera étudié afin de visualiser l'usage du protocole de transport UDP.

Au sein de Wireshark, cliquez sur "Capture" puis "Options". On va créer un filtre pour capturer uniquement les paquets à destination du serveur DNS configuré sur ma machine locale et correspondant à l'adresse IP "192.168.100.11".

À la place du filtre "ip dst", on peut utiliser "dst host" pour spécifier un hôte cible y compris en indiquant un nom DNS directement plutôt qu'une adresse IP. Ce qui donne le filtre suivant :

dst host 192.168.100.11

Mais, on aurait pu utiliser :

ip dst 192.169.100.11

Afin de capturer l'échange complet, avec les réponses du serveur DNS, il faudrait ajouter une condition sur l'adresse IP source. Pour s'intéresser uniquement à l'UDP et remarquer sa présence, ce n'est pas indispensable.

ip src 192.168.100.11 or ip dst 192.168.100.11

Il ne reste plus qu'à cliquer sur "Démarrer".

Wireshark : filtre sur une adresse IP destination
Wireshark : filtre sur une adresse IP destination

Pendant ce temps, à l'aide d'une console on va générer une requête DNS via l'outil "nslookup" sur un nom de domaine. Pour ma part, je vais tout simplement requêter sur le nom de mon domaine Active Directory.

nslookup it-connect.local

En arrière-plan, on remarque la présence des paquets DNS dans Wireshark.

Wireshark : communication DNS entre un client et un serveur
Wireshark : communication DNS entre un client et un serveur

Si l'on regarde le paquet n°8, on voit que mon hôte local a interrogé le serveur DNS pour obtenir une réponse pour le domaine "it-connect.local". Le paquet suivant ne correspond pas à la réponse du serveur DNS, car je n'ai pas inclus les réponses dans mon filtre Wireshark.

En regardant l'en-tête du paquet correspondant à ma requête DNS, on remarque la présence d'un en-tête UDP puisque c'est indiqué "User Datagram Protocol". On remarque également que cet en-tête contient beaucoup moins de champs différents : il n'y a pas de suivi sur le transfert des données ni de connexion, donc c'est plus léger.

Wireshark : présence d'un en-tête UDP dans les paquets DNS
Wireshark : présence d'un en-tête UDP dans les paquets DNS

IV. TCP vs UDP

En reprenant les caractéristiques principales, voici ce que l'on obtient si l'on compare les protocoles TCP et UDP :

TCP UDP
Fiabilité Elevée Faible
Vitesse Faible Elevée
Détection des erreurs Oui Non
Correction des erreurs Oui Non
Contrôle de la congestion Oui Non
Accusé de réception (ACK) Oui Uniquement la somme de contrôle

Si l'on veut faire une comparaison avec la vie réelle, on peut prendre l'exemple d'un courrier que l'on expédie par voie postale. Si l'on envoie ce courrier en prenant l'option "lettre recommandée avec accusé de réception", on sera capable de savoir si le destinataire a bien reçu ou non le courrier puisque l'on va recevoir une preuve dans sa boite aux lettres quelques jours plus tard. Cet accusé de réception nous assure que le courrier est arrivé à destination. On peut considérer en quelque sorte que cela correspond au fonctionnement du protocole TCP.

Par contre, si l'on envoie ce courrier simplement en tant que "lettre verte" ou "lettre prioritaire", nous n'avons aucun moyen de savoir si le destinataire a bien reçu le courrier via ce mode d'expédition. Cette fois-ci, on se rapproche du fonctionnement du protocole UDP. On peut imaginer qu'un jour nous allons recevoir une réponse à notre courrier, car souvent un courrier implique une réponse, tout comme le serveur DNS répond aux requêtes DNS qui lui sont envoyées, mais cela est lié au fonctionnement du protocole de couche supérieure (DNS) plutôt qu'au protocole d'UDP, ce dernier étant là uniquement pour transporter la requête.

Désormais, vous connaissez les grands principes des protocoles TCP et UDP. Si la sécurité informatique vous intéresse, je vous recommande de lire cet article sur les scans de port en exploitant le protocole TCP.

Pour finir, sachez que ce ne sont pas les seuls protocoles de transport disponibles et il y a un protocole assez récent qui est de plus en plus à la mode : le protocole QUIC. Probablement le sujet d'un prochain article.

The post Les protocoles TCP et UDP pour les débutants first appeared on IT-Connect.

Informatique : c’est quoi une DMZ ?

7 décembre 2021 à 17:15

I. Présentation

Dans cet article, je vais aborder une notion fondamentale en sécurité informatique : la notion de DMZ, c'est-à-dire de zone démilitarisée.

Je vais vous expliquer à quoi ça sert, comment ça fonctionne et nous verrons des exemples à travers quelques schémas.

II. Qu'est-ce qu'une DMZ en informatique ?

Tout d'abord, il faut savoir que DMZ, ça signifie en anglais DeMilitarized Zone, et en français zone démilitarisée. Pour comprendre l'origine de ce terme, il faut s'intéresser à l'histoire, non pas à l'histoire de l'informatique, mais à l'histoire de la Corée et à la Guerre Froide. La zone démilitarisée Coréenne est une zone tampon (représentée par des terres inhabitées et où l'accès est très limité) qui sert de frontière entre la Corée du Nord et la Corée du Sud.

Sur l'image ci-dessous, on peut voir que la zone démilitarisée crée une véritable séparation entre la Corée du Nord et la Corée du Sud.

Source : lefigaro.fr

Quel est le rapport entre la DMZ entre les deux Corée et une DMZ en informatique ? Et bien, si l'on compare la situation des deux Corée avec un réseau informatique, on peut voir quelques similitudes et imaginer que :

  • La Corée du Nord, c'est le réseau Internet (ou le réseau local, comme vous voulez)
  • La Corée du Sud, c'est le réseau local (ou Internet)
  • La zone démilitarisée est une séparation entre les deux qui est là pour des raisons de sécurité

Effectivement, on peut considérer que le réseau local est une zone de confiance, tandis qu'Internet est une zone à risque. Grâce à la DMZ, on va chercher à protéger le réseau local d'Internet, tout en permettant la communication entre les deux zones, mais de façon contrôlée et filtrée.

En informatique, la DMZ est un sous-réseau isolé à la fois du réseau local et de l'internet, c'est en quelque sorte une zone tampon, entre un réseau sécurisé et un réseau non sécurisé. Bien sûr, le réseau non sécurisé c'est Internet, car on sait qu'Internet est dangereux.

Mais, alors, qu'est-ce que l'on en fait de cette DMZ ?

Dans la DMZ, on va venir connecter des serveurs avec des rôles spécifiques. Plus précisément, en DMZ on va connecter des serveurs qui ont besoin d'accéder à Internet et d'être joignables depuis Internet. Par exemple, un serveur Web si vous hébergez un site Internet, ou alors un serveur de messagerie pour l'envoi et la réception d'e-mails. On peut aussi positionner un serveur proxy qui sert de relais pour la navigation à Internet entre les postes de travail et Internet.

Depuis quelques années maintenant, il est très courant d'utiliser un reverse proxy plutôt que d'exposer directement les serveurs, que ce soit les serveurs Web ou les serveurs de messagerie. Ce serveur va gérer les connexions entrantes, en provenance d'Internet, pour les relayer vers le(s) bon(s) serveur(s).

L'objectif étant de ne jamais exposer directement sur Internet les serveurs et postes de travail connectés au réseau local de l'entreprise. Les flux de ces équipements doivent passer par la DMZ, et donc par la zone tampon, afin de contrôler, relayer et filtrer les échanges entre le réseau local et Internet.

L'intérêt de la DMZ, c'est de créer une zone étanche dans laquelle sera contenu un pirate informatique en cas de compromission d'un serveur. En théorie, car cela dépend aussi de la configuration en place et notamment du firewall (pare-feu) car c'est bien lui qui crée la séparation entre les différentes zones : le réseau local (LAN), Internet et la DMZ.

III. Architecture réseau d'une DMZ

Pour mettre en place une zone démilitarisée au sein d'une architecture réseau, vous avez besoin d'un firewall (c'est-à-dire un pare-feu). On peut créer une DMZ avec un seul firewall, mais dans certains cas il y a deux firewalls.

A. DMZ avec un seul pare-feu

Prenons l'exemple le plus courant : la création d'une DMZ avec un seul et unique firewall. Avec cette configuration, il faut imaginer un pare-feu avec trois zones déclarées où chaque zone dispose de sa propre adresse IP. Ainsi, une machine dans le réseau local passera par le pare-feu pour accéder à la DMZ (ou à Internet, selon la politique en place).

Sur le schéma ci-dessous, il est important de préciser que le réseau local et la DMZ ont un adresse IP qui s'appuie sur les classes d'adresses IP privées.

DMZ avec un seul pare-feu
DMZ avec un seul pare-feu

On peut imaginer que le serveur en DMZ soit le serveur de messagerie de l'entreprise. On le positionne en DMZ car il est exposé sur Internet : il doit accéder à Internet pour envoyer les e-mails, mais aussi être joignable depuis Internet pour recevoir les e-mails. De ce fait, il représente un risque en termes de sécurité.

Depuis le réseau, on autorise les machines à contacter le serveur de messagerie, en DMZ, via quelques protocoles et ports seulement : SMTP pour l'envoi des e-mails et IMAP pour la réception des e-mails.

Éventuellement, on peut ajouter le protocole HTTPS pour accéder au Webmail. Par contre, le serveur de messagerie n'est pas autorisé à réaliser un ping vers le réseau local, ni à établir une connexion Bureau à distance ou un transfert de fichiers vers une machine du réseau local, etc. Le pare-feu devra refuser les flux des autres protocoles (ICMP, SSH, RDP, etc.) pour des raisons de sécurité.

Le positionnement du serveur de messagerie permet de créer une politique de sécurité stricte et adaptée au sein du pare-feu.

B. DMZ avec deux pare-feu

Si vous avez un peu plus d'argent, vous pouvez mettre en œuvre une DMZ basée sur deux niveaux de pare-feu. De cette façon, la DMZ est créée grâce à la zone tampon située entre les deux pare-feu.

L'idéal c'est de mettre en place un serveur proxy en DMZ pour que la connexion Internet de tous les équipements du réseau local passe par ce serveur proxy situé en DMZ, ce dernier sera alors un relais. De cette façon, les machines du réseau local ne sont jamais en contact direct avec Internet. Attention, la mise en place d'un proxy est tout à fait possible lorsqu'il n'y a qu'un seul pare-feu.

DMZ avec deux pare-feu
DMZ avec deux pare-feu

Avec deux pare-feu, on peut appliquer la configuration suivante :

  • Le pare-feu n°1 autorise seulement les communications entre Internet et la DMZ
  • Le pare-feu n°2 autorise seulement les communications entre le réseau local et la DMZ

Dans les deux cas, avec des protocoles et des ports spécifiques. Si un attaquant parvient à passe-outre la politique de sécurité du pare-feu n°1 et prendre la main du serveur situé en DMZ, il devra passer une seconde barrière : le pare-feu n°2, afin d'accéder au réseau et aux serveurs connectés directement sur ce segment du réseau.

Dans cet exemple, je montre uniquement le flux lié à la messagerie, mais si vous souhaitez que vos utilisateurs accèdent à Internet en direct (sans passer par votre éventuel proxy), il faudra bien sûr autoriser les protocoles HTTP/HTTPS.

Que ce soit avec un ou deux pare-feu, gardez à l'esprit que l'objectif sera de protéger notre réseau de confiance, à savoir le réseau local, grâce à la zone démilitarisée.

The post Informatique : c’est quoi une DMZ ? first appeared on IT-Connect.

Les serveurs proxy et reverse proxy pour les débutants

2 décembre 2021 à 17:00

I. Présentation

Dans ce tutoriel, nous allons aborder les notions de proxy et reverse proxy de manière théorique, car ce sont deux notions très importantes en informatique.

Les notions de proxy et reverse proxy sont très proches, c'est pour cette raison que les deux seront présentés dans le même article, mais aussi parce qu'il est indispensable de connaître ces deux approches.

II. C'est quoi un proxy ?

Un serveur proxy, appelé également serveur mandataire, est un serveur qui jouera le rôle d'intermédiaire entre un client et un serveur distant. Par exemple, entre les ordinateurs connectés au réseau local d'une entreprise et Internet (et ses milliards de sites).

Jouer le rôle d'intermédiaire entre deux hôtes, c'est-à-dire ? Dans quel but ? En se positionnant entre le client source et le serveur cible, le serveur proxy va pouvoir réaliser plusieurs actions :

  • Filtrage, ce qui va permettre de bloquer certains sites ou certaines catégories de sites.
  • Cache, ce qui va permettre de mettre en cache les requêtes (exemple : page web) afin de les retourner plus rapidement aux postes de travail.
  • Compression, ce qui va permettre de réduire le poids des pages au moment de retourner le résultat aux clients.
  • Journalisation, toutes les requêtes reçues de la part des clients (postes de travail) seront stockées dans des journaux (logs).
  • Anonymat, puisque votre poste de travail se cache derrière le proxy, le serveur Web verra seulement le proxy.
  • Droits d'accès, puisque le proxy est un intermédiaire, il peut servir à positionner des droits d'accès pour filtrer les accès, au-delà du filtrage Web.

Prenons un exemple pratique : un poste de travail est configuré pour utiliser un proxy et l'utilisateur souhaite accéder au site "www.it-connect.fr". Le poste de travail va demander au serveur proxy de récupérer la page du site "www.it-connect.fr", alors le proxy va se connecter au site "www.it-connect.fr" et retourner la page Web au poste client. D'un point de vue du serveur qui héberge le site "www.it-connect.fr", on verra seulement le serveur proxy et on ignore la présence du poste de travail.

En quelques mots, on peut dire que le poste client demande au proxy d'aller récupérer le contenu de la page web à sa place et de lui retourner le résultat. Les serveurs proxy sont très souvent utilisés pour la navigation Internet, il agit donc sur les protocoles HTTP et HTTPS, mais on peut rencontre d'autres types de proxy (exemple : Proxy SOCKS pour faire du SSH).

A. Proxy et proxy transparent

En entreprise, il est très fréquent d'utiliser un serveur proxy et bien souvent il est là pour réaliser du filtrage Web afin de sécuriser la navigation Internet des utilisateurs, notamment dans les établissements scolaires. Par exemple, on va empêcher les utilisateurs d'accéder aux sites pornographiques.

Il y a deux manières d'intégrer un proxy :

  • Un proxy (classique)

Le proxy doit être déclaré sur le poste client afin que ce dernier soit configuré de manière à passer par le proxy lorsqu'une requête est envoyée, plutôt que de contacter directement l'hôte distant. Si le serveur proxy n'est pas configuré sur le poste client, alors la requête sera envoyée directement au serveur distant, comme si le serveur proxy n'existait pas.

Il y a plusieurs façons d'intégrer un serveur proxy dans une infrastructure. Cela peut être en DMZ, comme ça les postes clients contactent le serveur proxy isolé, et c'est ce serveur qui se connecte à Internet, et non les postes clients directement. Dans certains cas, la fonction de proxy est assurée directement par le pare-feu et donc dans ce cas, il n'y a pas la notion de DMZ (voir second schéma).

Schéma Proxy

  • Un proxy transparent (implicite)

Lors de l'utilisation d'un proxy transparent, appelé aussi proxy implicite, le proxy ne doit pas être configuré sur le poste et ce dernier l'utilisera sans s'en rendre compte, car le proxy sera utilisé comme passerelle au niveau de la configuration du poste client. C'est la configuration idéale pour filtrer le trafic émis par les postes clients.

Dans ce cas, la fonction de pare-feu et de serveur proxy transparent sont généralement regroupée sur un même serveur/équipement. Même si l'on pourrait mettre le serveur proxy transparent sous le pare-feu, et que les trames soient relayées entre le proxy et le pare-feu.

Schéma Proxy Transparent

B. Comment configurer un proxy sur un poste de travail ?

Sur un poste client, il y a plusieurs manières de configurer un proxy. Tout d'abord, il faut savoir qu'un proxy peut se configurer au niveau de chaque logiciel, sous réserve que le logiciel prenne en charge l'utilisation d'un proxy.

Sous Windows, le fait de configurer un proxy dans les "Options Internet" de la machine va permettre d'utiliser ce proxy dans d'autres logiciels qui vont venir se référer à cette configuration. Néanmoins, certains logiciels comme Firefox intègrent leur propre gestion du proxy (même si par défaut il va utiliser la configuration du système), ce qui peut permettre d'outrepasser la configuration du système.

Sur Windows 11, pour configurer un proxy, il faut cliquer sur "Paramètres", "Réseau et Internet" puis "Proxy". Ensuite, il faudra cliquer sur "Configurer" au niveau de l'option "Utiliser un serveur proxy" et il ne restera plus qu'à renseigner l'adresse du proxy.

Configurer proxy Windows 11
Configuration d'un proxy sur Windows 11

Dans Firefox, au sein des options, il faut cliquer sur l'onglet "Général" à gauche et tout en bas, au niveau de "Paramètres réseau", cliquer sur "Paramètres". La fenêtre "Paramètres de connexion" s'affiche et là on peut définir plusieurs proxy.

Configuration d'un proxy dans Firefox
Configuration d'un proxy dans Firefox

Vous allez me dire, comment configurer le proxy sur un parc informatique complet sans effectuer la configuration à la main... Dans ce cas, vous avez plusieurs solutions :

  • Utiliser une GPO pour déployer les paramètres de configuration du proxy sur les postes (au niveau de Windows ou des navigateurs)
  • Utiliser une GPO pour préciser l'emplacement d'un script d'auto-configuration du proxy ("proxy.pac") qui contient une fonction JavaScript "FindProxyForURL" dont l'objectif est d'indiquer si, pour une URL précise, le navigateur doit accéder au site directement ou s'il doit passer par le proxy. Le fichier doit porter l'extension "PAC" pour "Proxy Automatic Configuration".

C. Quels logiciels pour mettre en place un proxy ?

Pour mettre en place un serveur Proxy, il existe de nombreuses solutions. Certaines sont gratuites, d'autres sont payantes. Lorsque l'on parle de serveur proxy, j'ai un nom qui me vient en tête directement : Squid.

Squid est un logiciel qui permet de monter un proxy (et même un reverse proxy) sous Linux, il est performant et très célèbre. Il est toujours maintenu aujourd'hui et sa première version date de juillet 1996 ! Si vous montez un pare-feu avec PfSense, il est possible d'installer le paquet "Squid" pour ajouter la fonctionnalité de proxy à son pare-feu. En complément, l'installation du paquet "Squid-Guard" permettra d'effectuer du filtrage Web.

Au niveau des solutions payantes, il y a deux solutions assez connues : Olfeo et UCOPIA.

D. Le proxy est la notion d'anonymat

Je souhaitais revenir un peu plus en détail sur la notion d'anonymat lorsque l'on utilise un serveur proxy. Certes, en utilisant un serveur proxy il est possible d'être anonyme vis-à-vis du site que l'on visite, mais il faut savoir que le proxy va garder une trace de toutes les requêtes que vous lui envoyez. Autrement dit, il connaîtra tout votre historique de navigation. Pour être réellement anonyme sur Internet, la meilleure méthode consiste à utiliser un VPN.

E. Proxy de mise en cache

Un proxy de mise en cache, appelé "proxy-cache", effectue la mise en cache des données sur son disque local. Dans certains cas, on peut utiliser un proxy de mise en cache pour distribuer des mises à jour de logiciels : le proxy va télécharger une fois la mise à jour sur Internet et la mettre en cache, et ensuite il n'aura plus qu'à la distribuer aux postes clients directement, plutôt que chaque poste client se connecte sur Internet pour télécharger la mise à jour. Par exemple, l'éditeur ESET propose une fonctionnalité de mise en cache pour distribuer les mises à jour des signatures antivirus.

Il est à noter que cette mise en cache peut également être bénéfique dans le cadre de la navigation Internet.

F. Port utilisé par un serveur proxy

Il n'y a pas de port associé obligatoirement aux serveurs proxy, car ce n'est pas un protocole en soi. Malgré tout, il y a deux ports que l'on voit très souvent : 3128 et 8080. Pourquoi ? Tout simplement parce que le port 3128 est utilisé par défaut par Squid, et la popularité de ce logiciel fait que l'on associe souvent le port 3128 à la notion de proxy. Un autre numéro de port que l'on rencontre souvent est le 8080.

Néanmoins, rien ne vous empêche de monter un proxy et d'utiliser le port 80 comme port d'écoute.

G. Contourner les restrictions avec un proxy

Grâce à un proxy, on va pouvoir contourner les restrictions, que ce soit les restrictions géographiques ou les restrictions appliquées au sein d'un réseau local de votre entreprise (par un pare-feu, par exemple).

Prenons un exemple, vous avez besoin d'accéder au site "domaine.xyz" mais vous ne pouvez pas, car le pare-feu en sortie de votre réseau bloque l'accès à ce site. Comme le montre le schéma ci-dessous, la requête est bloquée par le pare-feu.

Pour contourner cette restriction, vous pouvez vous appuyer sur un proxy externe situé sur Internet. De cette façon, votre PC va demander au proxy d'accéder au site "domaine.xyz" et le proxy va vous retourner le résultat. La requête n'est pas bloquée, car vous contactez le proxy et non pas le site en direct. On obtient le schéma suivant :

Attention, je dis que la requête n'est pas bloquée par le pare-feu si l'on passe par un proxy, mais cela dépend de la configuration du pare-feu, et éventuellement du proxy :

  • Si le pare-feu effectue du filtrage DNS ou de site Web, il y a de fortes chances qu'il bloque une liste de proxy connu pour être utilisé pour contourner les restrictions.
  • Si le proxy écoute sur un port particulier comme le 3128 ou le 8080 et que le pare-feu n'autorise pas ces ports en sortie vers Internet, la connexion vers le proxy ne pourra pas aboutir.

Si vous êtes motivé, vous pouvez toujours monter votre propre proxy sur le port 80 (http) ou 443 (https) afin de l'utiliser comme rebond.

III. C'est quoi un reverse proxy ?

À l'inverse du proxy, le reverse proxy comme son nom l'indique fonctionne à l'inverse, c'est-à-dire qu'il permet aux utilisateurs externes d'accéder à une ressource du réseau interne. Lorsque vous accédez à une ressource protégée par un reverse proxy, vous contactez le reverse proxy et c'est lui qui gère la requête, c'est-à-dire qu'il va contacter le serveur cible à votre place et vous retourner la réponse. Le client n'a pas de visibilité sur le ou les serveurs cachés derrière le reverse proxy. Le reverse proxy agit comme une barrière de protection vis-à-vis des serveurs du réseau interne, et il va permettre de publier la ressource de façon sécurisée.

Un cas d'usage courant, c'est d'avoir plusieurs serveurs Web derrière un reverse proxy. Ce dernier va pouvoir répartir la charge entre les différents serveurs Web et en cas de panne d'un serveur Web, vous ne verrez pas la différence, car le reverse proxy orientera les requêtes en conséquence. Si l'on schématise une infrastructure Web qui s'appuie sur un reverse proxy intégré au pare-feu, on obtient :

Schéma Reverse Proxy

Si le serveur reverse proxy est un serveur à part entière, on va venir le positionner en DMZ, et dans ce cas, les serveurs Web peuvent être connectés au réseau local. Les flux provenant de l'extérieur, c'est-à-dire des postes clients qui veulent se connecter au site Web, continuent d'arriver sur le reverse proxy qui sert d'intermédiaire.

Comme dans le cas d'un proxy, le reverse proxy va pouvoir mettre en cache certaines ressources afin de soulager les serveurs Web, mais aussi pour améliorer les performances du site grâce à la compression des données. Par exemple, le reverse proxy va pouvoir mettre en cache des ressources statiques comme les scripts JavaScript.

Si l'on fait un parallèle avec le casino et les jeux de table, on peut dire que le croupier (le reverse proxy) distribue les cartes (les connexions) aux joueurs (aux serveurs) autour de la table (du réseau local) qui participent à la partie. Merci Geoffrey pour cette idée d'analogie. 😉

A. L'en-tête HTTP et le champ "X-Forwarded-For"

Le proxy peut configurer l'en-tête "X-Forwarded-For" pour ajouter à l'en-tête des requêtes HTTP l'adresse IP du client d'origine. De cette façon, le serveur qui reçoit la requête du reverse proxy pourra tracer le client d'origine malgré tout puisque le reverse proxy lui communique l'information.

Cette notion est importante d'un point de vue de la sécurité, notamment si elle est gérée sur le serveur Web directement : on pourra bloquer uniquement ce client s'il effectue une attaque brute force sur notre serveur Web, plutôt que de bloquer le reverse proxy, ce qui serait forcément problématique.

B. Quels logiciels pour mettre en place un reverse proxy ?

Pour mettre en œuvre un reverse proxy, il existe plusieurs solutions open source très connues, comme Apache et son module mod_proxy, mais aussi Nginx. Pour rappel, Apache et Nginx sont également très utilisés en tant que serveur Web. Le serveur Web de chez Microsoft, inclus à Windows et nommé IIS dispose aussi d'un module lui permettant de jouer le rôle de reverse proxy. Il existe également le logiciel HAProxy qui est aussi gratuit et open source.

Sans oublier Squid, que l'on peut utiliser comme proxy puisque je l'ai déjà cité précédemment, mais aussi en tant que reverse proxy Squid. Si vous installez un pare-feu PfSense, vous pouvez lui ajouter la fonction de reverse proxy grâce au paquet Squid.

The post Les serveurs proxy et reverse proxy pour les débutants first appeared on IT-Connect.

Créer un routeur Wifi avec un Raspberry Pi et RaspAP

26 octobre 2021 à 10:00

I. Présentation

Il existe de nombreux routeurs Wifi sur le marché, fournissant un niveau de service plus ou moins élevé et sur lequel vous avez plus ou moins la main.

Les "singleboard computers" (comprendre les ordinateurs à carte unique) dont le Raspberry Pi en tête, offre une myriade de possibilités de réalisations aussi bien pour des applications IoT et domotique, que pour des utilisations réseau.

Dans ce tutoriel, je vais vous montrer comment réaliser son propre routeur Wifi avec un Raspberry Pi et RaspAP, et le configurer pour avoir un résultat se rapprochant des meilleurs matériels disponibles.

Parmi les fonctionnalités offertes par RaspAP, nous pouvons retrouver :

  • Mode Pont (pour "étendre" votre réseau filaire)
  • Intégration OpenVPN et Wireguard
  • Bloqueur de pubs intégré
  • Utilisation du trafic en temps réel
  • Liste des clients connectés
  • Historique d'usage de la bande passante sur un mois

II. Prérequis

Pour réaliser ce tutoriel, j'ai besoin de :

  • Un RaspBerry Pi modèle 3 ou plus récent (avec wifi intégré)
  • Un PC
  • Un câble réseau
  • Une carte micro SD de 8 Go minimum (16 Go recommandé)
  • Le cas échéant un lecteur de carte micro SD

Vous aurez également besoin de RaspberryPi OS (anciennement Raspbian). Par chance, la fondation RaspberryPi qui est à l'origine de ce portage de Debian, met à disposition un logiciel sur son site permettant de faciliter la création de la carte SD, ce programme est disponible sur leur site officiel.

III. Création de la carte SD du Raspberry Pi

Téléchargez le logiciel cité plus haut, installez-le et lancez-le.

Vous arriverez sur une interface minimaliste laissant apparaître les trois étapes de la création de la carte SD :

Interface de RaspberryPi Imager

On commence donc par le premier : le choix de l'OS. Pour ma part, comme j’aime avoir le contrôle de ce que j’installe, je suis parti pour la version minimale (Lite), mais c’est à vous de juger, ça fonctionnera très bien avec une autre, il n'y a aucun problème.

Une fois la version de l'OS choisie, il nous reste à sélectionner notre carte micro SD dans la section stockage.

Note : l'opération effacera tout le contenu de la carte, aussi, veillez bien à sauvegarder vos données si besoin et surtout à sélectionner le bon lecteur avant de lancer l'écriture !

Une fois l'opération terminée, un pop-up vous avertira de la possibilité de retirer la carte SD du lecteur :

Note : pour les personnes réalisant ce tuto sous Windows, vous risquez d'avoir plusieurs fenêtres de l'Explorer qui s'ouvrent automatiquement une fois l'opération terminée. Certaines d'entre elles afficheront un message d'erreur et inviteront à formater la carte. Bien sûr, il ne faudra en aucun cas le faire, fermez simplement ces fenêtres sans en tenir compte.

La seule partition lisible sous Windows sera la partition "boot". Ça tombe bien puisque c'est justement dans celle-ci qu'il faudra rajouter un fichier nommé "ssh" sans aucune extension et vide directement à la racine. Ceci afin d'activer automatiquement le SSH au démarrage du Raspberry.

Dans cette même partition, un autre fichier va nous intéresser. Il s'agit de cmdline.txt qui indique plusieurs instructions pour configurer certains paramètres du noyau Linux. Comme son nom l'indique, il ne contient qu'une ligne. Ce fichier est intéressant pour nous afin de donner directement une adresse IP au Raspberry; cela nous permettra d'éviter d'avoir à le chercher sur le réseau pour s'y connecter ou de devoir brancher un écran dessus.

Pour assigner une adresse IP, il suffit de rajouter à la fin de la ligne :

ip=192.168.1.85

Enregistrez le fichier puis retirez la carte SD de l'ordinateur afin de l'insérer dans le Raspberry Pi.

IV. Connexion et installation de RaspAP

Une fois le Raspberry démarré, nous allons déjà vérifier que l'adresse IP préconfigurée a bien été appliquée. pour cela, un petit "ping" suffit à nous rassurer :

ping 192.168.1.85

Envoi d’une requête 'Ping' 192.168.1.85 avec 32 octets de données :
Réponse de 192.168.1.85 : octets=32 temps=5 ms TTL=64
Réponse de 192.168.1.85 : octets=32 temps=3 ms TTL=64
Réponse de 192.168.1.85 : octets=32 temps=4 ms TTL=64
Réponse de 192.168.1.85 : octets=32 temps=4 ms TTL=64

On peut donc se connecter en SSH avec l'utilisateur par défaut "pi" et le mot de passe "raspberry":

ssh [email protected]

Une fois connecté, la première chose à faire est bien entendu de changer le mot de passe par défaut :

[email protected]:~ $ passwd
Changing password for pi.
Current password:
New password:
Retype new password:
passwd: password updated successfully

Si vous êtes orienté réseau, vous avez peut-être remarqué que j'ai uniquement spécifié une adresse IP, sans masque de sous réseau ni passerelle. En réalité, la modification du fichier cmdline.txt ne configure pas une adresse IP, mais en assigne une secondaire, ce que nous pouvons vérifier avec la commande ip a :

Résultat de la commande ip a

On voit bien l'adresse précédemment citée, mais on voit aussi que le service DHCP a récupéré une adresse IP depuis ma box, ainsi que les autres paramètres IP.

Pour que ce soit plus propre, on va assigner directement depuis le service dhcpd qui est le client dhcp. Pour cela, il faut modifier le fichier dhcpcd.conf :

sudo nano /etc/dhcpcd.conf

Puis on ajoute les lignes suivantes :

#interface filaire
interface eth0
static ip_address=192.168.1.85/24
static routers=192.168.1.1
static domain_name_servers=9.9.9.9 1.1.1.1
  • On déclare d'abord le nom de l'interface : interface eth0
  • On assigne l'adresse IP souhaitée en précisant le masque : 192.168.1.85/24
  • On déclare le routeur : 192.168.1.1
  • Et enfin, les serveurs DNS que l'on souhaite utiliser. Pour ma part, j'ai choisi ceux de CloudFlare et Quad9, mais vous pouvez faire comme bon vous semble.

Après un redémarrage, on retape la commande ip a juste pour vérifier qu'on est propre :

Parfait, on peut passer à la suite.

On réalise tout d'abord une mise à jour des paquets :

sudo apt-get update && sudo apt-get upgrade

Le processus peut être long en fonction du nombre de mises à jour et de votre connexion.

Une fois l'opération terminée, il ne nous reste plus qu'à installer RaspAP. Ici, plusieurs techniques sont disponibles : copie du dépôt GitHub, à partir des sources ou avec un script. Par souci de facilité, je choisis la méthode du script. Celui-ci est disponible à l'adresse suivante : https://install.raspap.com

Pour ceux qui souhaitent accéder directement au dépôt GitHub, voici le lien

Nous allons donc télécharger le script et le mettre dans un fichier que nous nommerons "raspap.sh" :

wget https://install.raspap.com -O raspap.sh

L'option -O permet de spécifier un fichier en sortie.

Pour pouvoir exécuter ce script, il faut d'abord le rendre... exécutable! Pour cela, ajouter le droit +x, "x" correspondant à "exécution" :

chmod +x raspap.sh

Puis, exécuter le script :

sudo ./raspap.sh

Note : n'oubliez pas le "sudo" ici, car le script doit faire des modifications sur des services système ou des permissions. Sans celui-ci, l'installation se poursuivra, mais ne fonctionnera pas.

Ce qui devrait normalement vous conduire à ceci :

Démarrage du script d'installation

La question qu’il nous pose concerne l’emplacement du dossier racine de lighttpd, pour le site web de configuration. À part si vous voulez le mettre ailleurs pour une raison X ou Y, je vous conseille de taper « Y », le script vous posera alors une deuxième question (« Complete installation with this value? ») à laquelle nous répondrons oui aussi.

S'en suit un listing des différentes dépendances du package à l'issue de laquelle on nous demande si on veut bien installer ces paquets, bien évidemment, il faut répondre oui :

Après plusieurs minutes, l'installation des principaux packages est faite, il ne reste que la configuration. Ici encore, tout est automatisé et quelques questions vous seront posées (elles n'apparaitront pas les unes à la suite des autres comme dans le texte ci-dessous, le regroupement a été fait dans un souci de lisibilité):

Enable HttpOnly for session cookies (Recommended)? [Y/n]: Y
Enable RaspAP control service (Recommended)? [Y/n]: Y
Install ad blocking and enable list management? [Y/n]: Y
  • La première option confirme l’ajout de l’attribut « HttpOnly » pour éviter l’accès en JavaScript aux cookies de session (afin d’empêcher les injections)
  • La deuxième va installer le démon RaspAP et l’activer afin qu’il démarre automatiquement
  • La troisième va installer un bloqueur de pubs qui sera intégré au point d’accès, rien que ça!

Encore une dernière question :

RaspAP Install: Configure OpenVPN support
Install OpenVPN and enable client configuration? [Y/n]:

Là, on vous demande si vous voulez installer OpenVPN, car oui, ce soft intègre aussi la gestion de connexions VPN. Pour ma part, je ne vais pas m’en servir donc je vais mettre « non », mais il est tout à fait possible de créer un mini serveur VPN embarqué!

À la fin de l'installation, un redémarrage est demandé, je vous conseille de le faire immédiatement.

The system needs to be rebooted as a final step. Reboot now? [y/N]:

V. Configuration de RaspAp

Au redémarrage du Raspberry Pi, on peut remarquer cette phrase :

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

Donc comme on veut que le wifi fonctionne, on va l’activer en tapant la commande :

sudo raspi-config

On sélectionne « System options » puis « Wireless LAN » :

Menu de raspi-config

Sélectionnez le pays, pas besoin d’entrer un SSID, vous pouvez abandonner ici (« Cancel »), le Raspberry Pi va redémarrer et le wifi sera alors actif.

Si on se fie au dépôt GitHub, au redémarrage, votre point d’accès va prendre cette configuration :

  • IP address: 10.3.141.1
    • Username: admin
    • Password: secret
  • DHCP range: 10.3.141.50 to 10.3.141.255
  • SSID: raspi-webgui
  • Password: ChangeMe

Modifions certains paramètres maintenant.

Premièrement, il faut nous connecter à notre nouvelle interface graphique. Pour cela, on ouvre un navigateur et on tape l’adresse IP du RPi (pour moi et pour rappel : 192.168.1.85) avec les identifiants cités plus haut:

Page d'accueil de RaspAp
Page d'accueil de RaspAp

On va maintenant changer le SSID. Pour cela, direction le menu Hotspot sur la gauche.

Changez la valeur « SSID », pour un maximum de compatibilité et de performance, je vous conseille également de changer le « Wireless Mode » en 802.11n 2,4Ghz. Pour le canal, vous pouvez utiliser une application tel que Wifi Analyzer pour choisir le canal le moins occupé dans votre voisinage.

Enregistrer les modifications en cliquant sur le bouton "Save settings".

Maintenant, direction l’onglet sécurité. Par défaut, la sécurité est définie sur WPA2 et CCMP, mis à part s’il y a des problèmes de connexion, je vous conseille de laisser en l’état et, si vous voulez savoir pourquoi, direction Wikipedia. Vous voyez au passage que la page nous génère un code QR pour la connexion.

En revanche, il est évident qu'il faut changer le mot de passe, un bouton est disponible pour en générer un, ce que j'ai fait, mais à vous de voir, il est plutôt...complexe :

Vous remarquerez que le soft génère automatiquement un code QR pour la connexion des smartphones par exemple. Très pratique si on met en place un wifi partagé.

Enregistrez et cliquez sur « Restart hotpsot ».

Normalement à ce stade, vous devriez voir apparaître le réseau wifi tel que vous l’avez configuré. Mais peut-être n’avez-vous pas envie d’utiliser la plage IP proposée par RaspAp ? C’est mon cas !

Pour les modifications, il faut se rendre dans le menu "DHCP server" pour mettre la plage réseau que vous souhaitez. Il faut dans un premier temps assigner une nouvelle adresse IP à l'interface wlan0 (qui est celle de notre Wifi):

Pour ma part, ce sera 172.16.0.0/24 avec une plage DHCP allant de 172.16.0.10 à 172.16.0.99. Pour les serveurs DNS, vous pouvez mettre ce que vous souhaitez.

Cliquez sur le bouton "Save Settings" encore une fois pour enregistrer les changements. Redémarrez ensuite le service dnsmasq en cliquant sur "Stop dnsmasq" puis sur "Start dnsmaq".

Pour appliquer ces nouveaux changements, il faut retourner dans le menu précédent (HotSpot) et redémarrer le service (Restart HotSpot).

De retour sur la fenêtre ssh, on peut vérifier que tout a été pris en compte avec la commande ip a :

Votre HotSpot est désormais opérationnel, vous pouvez commencer à connecter vos équipements.

VI. Conclusion

Nous avons vu dans ce tuto comment mettre en service un point d'accès wifi complet à partir d'un RaspBerry Pi et de RaspAP.

Le tout avec une interface graphique complète et détaillée, notamment au niveau de l’usage du réseau, ce qui peut être utile pour surveiller sa bande passante (menu "Data usage").

Ses possibilités de configuration et sa flexibilité en font une solution tout à fait viable face aux autres produits du marché.

The post Créer un routeur Wifi avec un Raspberry Pi et RaspAP first appeared on IT-Connect.
❌