Activité pratique

Durée2h30

Découverte d’un réseau

Le réseau en mode BYOD

Introduction

BYOD, abréviation de l’anglais « bring your own device », en français, PAP pour « prenez vos appareils personnels » ou AVEC pour « apportez votre équipement personnel de communication », est une pratique qui consiste à utiliser ses équipements personnels (smartphone, ordinateur portable, tablette électronique) dans un contexte professionnel. Wikipedia

Les statistiques du taux d’adoption des équipements numériques laissent penser que vous en avez très probablement un entre les mains, ou pas bien loin. Ces appareils, outre leurs capacités de calcul et de stockage, ont quasi-systématiquement des capacités réseau.

Cette séance a pour objectif d’explorer ces capacités réseau:

comprendre “pourquoi ça marche”;
se familiariser avec les aspects réseau de ses propres équipements & usages;
illustrer quelques connaissances évoquées en cours sur les technos réseau (DNS, DHCP, adresses IP, IPv4 IPv6, passerelle, routeurs, couche liaison / couche réseau, etc.)

Sur son propre ordinateur…

Votre ordinateur est allumé ? Bien !
Il a du réseau ? Super !
…Oui mais quoi, précisément ?

Fouillez dans les paramètres réseau de votre ordinateur pour essayer de retrouver les informations suivantes, et notez-les:

Disposez-vous d’une interface réseau de type Wifi, Ethernet, autre ?
Laquelle (ou lesquelles) est active ?
Pour chacune, est-ce que vous retrouvez une indication d’adresse physique (ou adresse MAC) ?
Quelle est son adresse IP ?
Une adresse IPv4, IPv6, les deux ?
Quel est son masque réseau ?
(Vous vous souvenez de ce que c’est ? …la partie (gauche) de l’adresse qui est commune à toutes les machines du même réseau local, bref, vos voisins directs…)
Est-ce que vous avez un routeur par défaut ?
(Vous noterez que son adresse IP débute comme la vôtre: il est forcément l’un de vos voisins direct, principe du routage hop-by-hop.)
Est-ce que vous avez un serveur DNS (ou resolver) ?
(Vous vous souvenez: pour faire la traduction des noms de serveurs en adresses IP…)
Comment est-ce que votre appareil a reçu toutes ses informations de paramétrage réseau ?
Est-ce une configuration manuelle ? (c’est vous qui avez rentré tous ces paramètres)
Est-ce une configuration automatique ?
Et si oui, par quel moyen ? par DHCP ?

Tous ces paramétrages sont quasi-indispensables au bon fonctionnement de la connectivité réseau de votre appareil. Si lui a réussi à les trouver, vous aussi ! Cherchez ! Notez !

L’interface graphique de votre ordinateur vous propose des moyens supposément intuitifs pour accéder à ces informations. Au besoin, quelques indications techniques suivant votre système d’exploitation:

Guide du support Microsoft
Guide de malekal.com
En ligne de commande, cherchez de la documentation sur ipconfig et netsh

N’allez pas trop vite. Je sais que vous avez oublié des trucs, recommencez, cherchez mieux ! 😉

Sur son smartphone…

Vous avez un smartphone (tablette, console, gadget, etc.) ? Bien !
Il y a du réseau ? Super !
Bon bin, mêmes questions… Et n’oubliez pas de noter les réponses également.

Interface réseau active ?
Adresse IP ? Masque ?
Routeur ?
DNS ?
Configuration manuelle/automatique DHCP ?
Si vous étiez en Wifi, passez en 4G/5G et reprenez les infos de paramétrages; et réciproquement.

Fouillez dans les paramètres de configuration de votre appareil, les onglets qui vous parlent “d’information de connexion”, les “paramètres avancés”, etc.

Gardez en mémoire par quels moyens vous accédez à ces informations sur votre propre appareil.

Au besoin, cherchez de la documentation sur Internet.
(En faisant attention aux pseudo-blogs qui se proposent en fait de vous vendre une application / service de VPN ou autre avec force de jargon technique éblouissant et discours alarmiste sur votre sécurité… Bref, faite preuve de discernement.)

Voisinage réseau

Au niveau WiFi (couche liaison)

Bon, reprenons: votre (vos) appareil a une liaison WiFi… Bien ! Mais cherchons à en savoir plus.
Questions:

Quel est le nom (SSID) du lien WiFi en questions ?
(Probablement “Eduroam” si vous sur le réseau de l’école, ou pas…)
Est-ce qu’il y a d’autres réseaux WiFi visibles de là où vous êtes ?
(Probablement un certain nombre… Certains sont des réseaux de l’école liés à des services ou laboratoires de l’école, d’autres sont des partages de connexion des smartphones de vos voisins laissés ouverts distraitement.)
Est-ce qu’il y a des réseaux WiFi cachés ?
(Bin, par définition, s’ils sont cachés vous ne les voyez pas… Ou en tout cas pas sans déployer des outils d’analyse & sécurité WiFi particuliers, mais c’est un autre débat…
Si vous en conaissez un d’actif, là, essayez.
Le principe d’un réseau WiFi caché: il n’annonce pas son nom en clair sur les ondes, à vous de le connaître pour paramétrer votre connexion et accrocher ce réseau.)
Le réseau WiFi que vous avez accroché, il est sur un canal et une fréquence précis. Lequel ?
(Fouillez un peu plus dans les paramètres réseau de votre appareil, c’est forcément quelque part…)

Quelques outils (cherchez de la documentation):

Sous Windows, en ligne de commande: netsh wlan show interfaces
Sous Linux, en ligne de commande: /sbin/iwconfig
Sous MacOS, en ligne de commande: sudo wdutil info
Sous Android, diverses applications comme WiFiman, WiFiAnalyzer etc.

Au niveau IP (couche réseau)

Votre appareil à une liaison WiFi / 4G / Ethernet. Et par-dessus cette liaison, vous avez un paramétrage IP (une adresse + masque, un routeur, un DNS, etc.)

Votre voisin également !

Grâce à ce que vous avez noté précédemment, comparez les paramètres IP de vos différents appareils, ainsi qu’avec vos voisins de classe.
(Vous pouvez discuter, mais pas trop fort, hein.)
Sur les adresses IP, comparez notamment la partie gauche, les $n$ premiers bits indiqués par le masque.
Si vous avez les mêmes valeurs, alors vous êtes officiellement sur le même réseau local, des voisins directs qui peuvent se joindre sans passer par un routeur.
De la même manière, comparez avec l’adresse de votre routeur: vous êtes forcément voisins.
Comparez également avec l’adresse de votre serveur DNS: ce n’est pas forcément un voisin direct.

Donc, sur le papier, on peut voir qui est voisin réseau, ou qui nécessite de traverser un routeur. Essayons:

L’outil ping en ligne de commande met en œuvre le protocole ICMP ECHO.
En gros: on envoie un paquet à l’adresse IP indiquée en paramètre, et si tout se passe bien, la machine en question nous renvoie notre paquet (ping pong).
Conclusion: si on voit notre paquet revenir c’est que tout se passe bien (configuration: ok, liens: ok, etc.)
par contre s’il ne revient pas, on ne peut pas conclure: soit la configuration de l’un ou l’autre est mauvaise, soit un firewall a filtré, soit la machine en face est éteinte, soit le lien est rompu, soit un routeur sur le chemin a mal routé, soit…

Notez que l’on peut pinger aussi bien nos voisins directs que n’importe quelle adresse routée.
- Tentez de pinger les adresses IP de vos divers appareils, et ceux de vos voisins de table.
  Notez les résultats (juste si l’autre est joignable ou pas, on ne va pas s’attarder ici sur les mesures de délais).
  
  Note: en ligne de commande, faire ping une_adresse_ip, puis, après quelques échanges arrêter avec un Ctrl-C
- Tentez de pinger l’adresse de votre routeur, l’adresse de votre DNS.
- Tentez quelques pings à l’aveuglette, par exemple en reprenant votre adresse IP à laquelle vous ajoutez 1 ou 2.
L’outil traceroute (ou tracert sous Windows) envoie une série de paquets UDP vers la destination, mais en jouant sur la valeur du TTL d’un paquet à l’autre.
(Sur Internet, on fait généralement des paquets avec TTL=64; ici on va faire varier TTL={1..64})
Time to Live (ou Hop Limit en IPv6): durée de vie maximum du paquet, décrémenté à chaque traversée de routeur; et arrivé à échéance, le paquet est détruit par le routeur qui le voit tomber à 0, et qui prévient l’émetteur. Ainsi, en envoyant plusieurs paquets ayant un TTL qui augmente progressivement, on va découvrir les routeurs successifs sur le chemin qui vont se manifester les uns après les autres lorsqu’ils détruisent nos paquets. Bref, grâce à cette astuce l’émetteur découvre la route vers la destination.
- Faites des traceroute vers les IP de vos appareils, et ceux de vos voisins de table.
  Si vous êtes voisins réseau, vous devriez les joindre en 1 saut.
- Faites un traceroute vers l’IP de votre routeur. Normalement c’est un voisin lui aussi.
- Faites un traceroute vers l’IP de votre DNS, là vous devriez découvrir les différents routeurs qui vous séparent.
- Essayez vers un nom de serveur quelconque, pour voir.
- Vérifiez que le premier routeur traversé est bien votre routeur par défaut.

Résolutions de nom

Le service DNS (Domain Name System, relisez le cours) permet de retouver l’adresse IP associée à un nom, et réciproquement. (Et bien d’autres choses encore.)

Votre appareil a, dans sa configuration réseau, la connaissance de l’adresse IP d’un serveur DNS de type resolver. (Celui de l’école, de votre opérateur, … éventuellement votre propre appareil si celui-ci a un service de resolver DNS intégré.)

Dans l’univers DNS, il y a des resolvers (résolveurs en français) et des authoritative servers (serveurs faisant autorité). Le resolveur connait la réponse à votre requête soit parce qu’il a l’information dans son cache suite à une résolution précédente, soit parce qu’il sait trouver les serveurs faisant autorité à interroger à son tour, et à minima les serveurs racine de l’IANA. Un serveur faisant autorité, lui, a une base de donnée des noms+IP du domaine qu’il gère, ainsi que les adresse IP des autres serveurs DNS de ses sous-domaines. Bref, vous demandez à votre DNS, il vous répond.

En temps normal, c’est quasi transparent pour l’utilisateur final. Lorsque vous utilisez une application réseau, vous pouvez désigner votre destinataire aussi bien par son adresse IP (si vous la connaissez par cœur), soit par son nom. C’est tellement banal que le système d’exploitation de votre appareil intègre un client DNS en standard.

Faisons quelques requêtes à la main dans le terminal:

Sous Windowns, la commande nslookup
Sous Linux & Mac, la commande host

(Note: Sous Unix la commande nslookup était développée par les équipes de BIND qui l’ont déclaré déprécié au profit de la commande dig plus sophistiquée. Mais pour les exercices d’aujourd’hui, vous pouvez utiliser à votre convenance l’une des trois, bien entendu après avoir lu la doc… (“man host” / “nslookup” / “dig”))

Faites quelques requêtes sur des noms que vous connaissez bien.
(P.ex. imt-atlantique.fr z.imt.fr moodle.imt-atlantique.fr wikipedia.org service-public.fr …)
Faites quelques requêtes sur les adresses que vous avez notées précédemment (celles de vos appareils, routeurs, DNS, voisins, etc.)
On appelle cela des requêtes inverses.
Et vice-versa…

Whois

Comme indiqué dans le cours (si si, rappelez-vous), les adresses IP et noms de domaine sont enregistrés auprès de l’IANA ou ses délégataires.
Oui, mais par qui ?

Historiquement la commande Unix whois s’arrangeait pour bricoler des requêtes à des bases d’enregistrement bien connues mais pas vraiment standardisées. Cette méthode n’est plus tellement utilisée.

Le plus simple pour faire quelques recherches ponctuelles, c’est de consulter les services web dédiés de l’IANA, de l’ICANN, et de notre registrar régional RIPE-NCC.

Vous pouvez faire des recherches sur des noms, sur des adresses IP, sur des noms d’organisation (à retrouver dans des réponses), des numéros d’Autonomous Systems, etc. Suivant les cas, ces différents registrars ne vous donneront pas forcément toutes les réponses à toutes vos requêtes… essayez, fouillez, enquêtez, explorez.

Challenges:

Arrivez-vous à retrouver votre opérateur Internet ? Est-ce qu’il a un numéro d’AS ?
Est-ce que le serveur web de l’école a une adresse IP de l’école ?

Analyse de trafic réseau

Nous allons maintenant utiliser le logiciel Wireshark que vous avez installé sur votre ordinateur en préparation de cette séance.

Ce logiciel fait deux choses:

Il capture les paquets réseau qui passent sous le nez de votre interface réseau.

Pour cela il reconfigure votre carte réseau en mode promiscuous. (Ne cherchez pas de traduction française, il n’y en a pas de bonne…) En gros, dans ce mode, votre carte réseau lit tous les paquets qui transitent sur la liaison, au lieu de filtrer sur l’adresse de destination et ne garder que ceux qui s’adressent à votre ordinateur comme elle ferait en temps normal. Bref, elle sniff le réseau. Passer dans le mode promiscuous nécessite les permissions Administrateur sur votre ordinateur; ne vous étonnez pas si votre système vous pose la question, c’est oui.
Ensuite, le logiciel analyse ces paquets, les décode et interprète chaque octet suivant la définition des protocoles réseau qu’il reconnaît.

Il présente le contenu de ces paquets de manière lisible pour un être humain, facilitant ainsi l’interprétation les échanges réseau. Il nous sera donc très utile pour comprendre, de visu, comment fonctionne TCP/IP.

Prise en main de Wireshark

Lancez le logiciel Wireshark.

Sur ce premier écran, vous voyez notamment une liste des interfaces réseau de votre ordinateur, et à côté, un petit dessin façon électro-cardiogramme qui figure l’activité du réseau sur l’interface en question.

Dans cette liste:
- Vous devriez reconnaître les noms des interfaces réseau que vous avez notées à l’exercice précédent;
- Vous devriez voir, en plus, une interface réseau virtuelle appelée Loopback, localhost ou lo;
  (Pour vous parlez à vous-même. Typiquement si vous avez un client et un serveur en local, ils se parlent grâce à cette interface-là.)
- Vous devriez voir aussi une pseudo-interface réseau appelée any, qui comme son nom l’indique agrège les paquets de toutes les autres interfaces;
  (Notez que ce n’est pas une vraie interface, même pas une interface virtuelle. Elle n’a pas d’existence dans le système d’exploitation, pas de configuration réseau. C’est juste un moyen, dans ce logiciel, pour récupérer tous les paquets de toutes les interfaces de l’ordinateur.)
- Apparaissent possiblement des interfaces réseau virtuelles créées pour des machines virtuelles (Docker & co.);
- Apparaissent possiblement des interfaces réseau virtuelles créées par des solutions de VPN si vous en avez;
- Et peuvent apparaître des pseudo-interfaces de capture applicatives, voir USB ou Bluetooth, suivant les librairies tierces installées.
Au besoin, consultez la documentation. Le look de ces copies d’écran peut varier suivant les versions de Wireshark.

Pour des premières manipulations simples, cliquez sur WiFi ou bien any (ou double clic, suivant les versions), c’est probablement l’une de celles où le pseudo électro-cardiogramme s’active le plus.
Sur ce second écran, vous avez trois panneaux.

Leur disposition peut varier suivant vos Préférences d’Affichage. (Vous ferez vos réglages plus tard.)

Mais pour résumer:
- Le panneau du haut liste les paquets au fur et à mesure qu’ils arrivent sur l’interface.
  
  Chaque ligne correspond à un paquet capturé, avec un timestamp, les adresses source et destination, le protocole reconnu, et un résumé de la nature du paquet.
  
  Si vous double-cliquez sur l’un de ces paquets, vous aurez les détails de ce paquet dans le panneau suivant.
- Le panneau au centre (ou en bas à gauche suivant les préférences d’affichage) donne des détails sur ce paquet.
  
  Chaque ligne peut se déplier (petit icon à gauche) pour donner encore plus de détails suivant les spécifications du protocole reconnu.
  
  Si vous sélectionnez un élément, les octets correspondants seront surlignés dans le troisième panneau.
- Le panneau en dessous (ou en bas à droite suivant les préférences d’affichage) affiche les octets tels qu’ils sont réellement transportés dans le paquet (ainsi que leur représentation hexadécimale).
Sur la barre de commande tout en haut, repérez les boutons pour Arrêter et Redémarrer la capture.

Wireshark peut vous proposer de sauvegarder dans un fichier les captures effectuées. Pour les manipulations d’aujourd’hui ce ne sera pas utile.
Faites plusieurs essais pour vous familiariser avec ce logiciel.

Observations passives

Observons du trafic existant, sans en générer nous même.

Relancez une capture réseau. Patientez quelques instants jusqu’à remplir le panneau du haut (la liste des paquets capturés).

Arrêtez votre capture.
Sur le panneau du haut, jouez avec le petit ascenseur à droite pour faire défiler la liste des paquets capturés.

Choisissez le paquet qui a le plus de charme à vos yeux. (En fait, peu importe lequel, il nous faut juste un exemple concret.)
Repérez sur la ligne: adresse source, adresse destination, protocole

Les adresses IP, on a déjà vu en cours à quoi cela ressemblait. Ici Wireshark peut vous remplacer l’IP par le nom de la machine si elle en a un. (Et si Wireshark est configuré pour faire des requêtes DNS; mais on paramètrera cela une autre fois.)

Mais le protocole ? Faites un petit tour sur Wikipedia (ce protocole a déjà très certainement une page), lisez le paragraphe d’introduction.
Double-cliquez sur le paquet, et regardez le panneau de détail du paquet.
- Encapsulation: Repérez les lignes correspondantes aux différentes couches protocolaires.
  
  Wireshark a capturé une trame Ethernet, qui porte un paquet IP, lui-même contenant un paquet TCP ou UDP, qui transporte un protocole applicatif, qui échange des données avec le destinataire…
  
  Chaque ligne correspond à l’entête du protocole correspondant, et que Wireshark sait interpréter.
- Ethernet: Dépliez cette ligne. Wireshark vous affiche les adresses MAC destination et source. (i.e. Les adresses physiques des interfaces Ethernet qui se causent; ne confondez pas ces adresses avec des adresses IP, ce n’est pas la même couche protocolaire.)
  
  Notez également que Wireshark vous indique un numéro de type de protocole transporté (probablement 0x0800 pour IPv4, 0x86DD pour IPv6, 0x0806 pour ARP…)
- IP: Dépliez cette ligne (à supposer que c’est bien de l’IP dans votre exemple, cela dépend justement du type précédemment indiqué).
  
  Repérez les adresses IP source et destination. Repérez si c’est de l’IPv4 ou de l’IPv6.
  
  Repérez également le protocole transporté (appelé Next Header en IPv6): TCP, UDP, ICMP, autre ?
- TCP, UDP, ICMP: Dépliez la ligne correspondant au protocole porté par votre paquet.
  
  Repérez les numéros de ports source et destination (dans le cas de TCP ou UDP). Notez que, le cas échéant, Wireshark peut parfois deviner l’application transportée si ces numéros de port sont classiques.
- Le cas échéant, dépliez la ligne correspondant au protocole applicatif deviné par Wireshark.
- Observez que chaque fois que vous cliquez sur une ligne, Wireshark va surligner les octets correspondants dans le dernier panneau.

Expériences

Cette fois-ci, nous allons observer du trafic que nous allons générer nous-même.

Puisque c’est du trafic nous concernant, nous pouvons filtrer sur notre IP. (Vous avez pu constater qu’il y a beaucoup de paquets qui circulent, on y vera plus claire en filtrant un peu.)

Dans la barre du haut, écrivez une règle de la forme ip.addr == 10.129.37.xxx, et validez.

Bien entendu, remplacez 10.129.37.xxx par votre propre adresse IP, ne recopiez pas aveuglément cet exemple…
Relancez la capture.

En principe, ça ne bouge pas trop à l’écran, sauf si:
- vous avez des applications réseau qui continuent à tourner dans un coin de votre PC; auquel cas, essayez d’en fermer un maximum;
- il y a des Mac dans le coin qui font volontiers des requêtes MDNS (du DNS en multicast, bien pratique dans certains cas, mais possiblement un peu verbeux lorsque les appareils Apple essaient de se synchroniser entre eux…).
  Dans ce cas, raffinez votre règle pour filtrer le multicast: ip.addr == 10.129.37.xxx && ip.addr != 224.0.0.0/24
- et s’il y a encore du trafic qui pollue l’affichage, n’hésitez pas à compléter votre règle de filtrage comme précédemment.
Repérez tout en bas de la fenêtre: il y a un compteur de paquets capturés qui continue à s’incrémenter. Certes, l’affichage est filtré, cependant les paquets sont bel et bien capturés et gardés en mémoire par Wireshark…
Expérience avec un ping:
- Relancez la capture. (Cela permet de nettoyer un peu les fenêtres de Wireshark.)
- Dans la console, refaites un ping comme à l’exercice précédent.
- Observez les paquets capturés par Wireshark: des “ICMP Echo request”, suivit de “ICMP Echo reply” (si tout se passe bien).
- Vérifiez que les adresses IP source et destination sont cohérentes.
- Comme précédemment, cliquez sur un paquet et regardez le panneau des détails: d’abord l’encapsulation des protocoles (Ethernet / IP / ICMP), puis le détail de chacun.
Expérience avec un traceroute:
- Relancez la capture. (Toujours faire du ménage…)
- Dans la console, refaites un traceroute comme à l’exercice précédent, en choisissant autant que possible une destination un peu lointaine.
- Observez d’une part les paquets UDP: adresses source et destination, un paquet UDP sur un port quelconque, et dans les détails de la couche IP des valeurs de TTL qui varient d’un paquet à l’autre.
- Et d’autre part, observez en réponse des paquets “ICMP Time-to-live exceeded”: intéressez-vous plus précisément à l’adresse IP de l’émetteur, c’est le routeur sur le chemin qui a dû détruire notre paquet comme expliqué précédemment.
Expérience avec une page web:
- Choisissons pour notre expérience le serveur web du cours.
  
  Juste pour avoir un affichage clair, nous allons filtrer sur son adresse IP: “ip.addr == 193.54.78.21”
  (Au besoin, vérifiez avec les commandes “nslookup” “host”.)
- S’il n’est pas déjà ouvert, ouvrez votre navigateur web. Puis relancez la capture. (C’est mieux d’attendre que le navigateur soit démarré avant de relancer la capture, car les navigateurs web ont la fâcheuse habitude de générer beaucoup de trafic à leur démarrage, vérifications de mise à jour, plugins divers, etc.)
- Maintenant, allez sur la page web du cours: https://hub.imt-atlantique.fr/ueinfo-fise1a/
  Au besoin, rafraichissez la page.
- Constatez dans Wireshark l’échange de paquets:
  - Une connexion TCP sur le port 443 (HTTPS), et dans ce flux TCP le protocole de chiffrement TLS.
  - Repérez les trois premiers paquets qui mettent en œuvre la fameuse poignée de mains en trois coups de TCP; la succession des paquets: SYN, SYN-ACK, ACK.
  - Voyez les échanges de données applicatives chiffrées en TLS, et donc illisibles même capturées par le logiciel.
  - Repérez la terminaison de la connexion, qui se clôture dans les deux sens: FIN, FIN-ACK, ACK.
Arrêtez la capture, fermez Wireshark, vous êtes arrivé au bout, bravo.