Rôle d'ARP
Nous avons vu qu'une station ne lisait le contenu d'une trame qu'à la condition qu'elle lui soit adressée. Or le paquet IP est justement placé dans la trame ! Lorsqu'une couche haute transmets des données à une autre machine, elle communique à la couche IP, l'adresse IP de destination.
IP formate ensuite un paquet avec une entête IP. Celle-ci comportent l'adresse de destination, transmise par la couche supérieure, et l'adresse IP source de l'émetteur. Cette dernière est connu par IP car vous l'avez initialisée lors de l'installation de la machine.
IP communique ce paquet à la couche 2 (ici le MAC) pour l'encapsuler dans une trame MAC avant émission sur le support. Mais il doit également communiquer l'adresse MAC de destination de la trame, pour que la couche 2 puisse formater correctement la trame ! D'où IP sortira-t-il cette adresse ? Il va l'inventer ? Non ... ARP est là !
ARP pour Address Resolution Protocol prend en charge, comme son nom l'indique, la résolution d'adresse entre le niveau 2 et le niveau 3. Il a pour rôle de trouver l'adresse MAC correspondant à une adresse IP donnée.
Lorsqu'il a découvert cette adresse, il met à jour une table ARP !
Fonctionnement d'ARP
Nous venons de voir qu'IP doit transmettre à la couche MAC l'adresse de destination MAC de la trame qui véhiculera le paquet IP transmis. La procédure est la suivante :
La séquence de recherche est terminée ! Maintenant IP peut envoyer son paquet à la couche MAC en transmettant l'adresse MAC !
Vous voyez, ARP c'est très simple !
|
Formats des paquets ARP
ARP est encapsulé directement dans IP (il n'est pas placé dans UDP ou TCP). Il propose deux paquets :
Quelques remarques à propos d'ARPLes problème liés à la table ARP
Je vous l'ai précédemment indiqué la table ARP est mémorisée en RAM. De plus, dans la majorité des cas il n'y a pas de timeout sur les tables ARP. Ceci veut dire que lorsqu'une correspondance MAC-IP a été réalisée elle reste mémorisée dans la station jusqu'au "reboot" de celle-ci. Et croyez-moi ! Ce n'est pas anodin !
Dans une architecture classique des stations et des serveurs partageant le même réseau local discutent ensemble. Supposons qu'un PC rencontre un problème vous allez le remplacer. La carte réseau du nouveau PC aura une adresse MAC différente. Par contre vous aurez réaffecté au PC la même adresse IP. Mais le serveur a mémorisé dans sa table ARP la correspondance "Ancienne @MAC-@IP". S'il émet des données vers le PC celui-ci ne lira pas les trames puisque leurs adresses destinations ne correspondent pas à son adresse MAC !
Rassurez-vous ! Pour un PC ce n'est pas grave ! En effet, pour le remplacer vous avez dû le mettre hors tension. Le nouveau PC a donc une table ARP vierge. Comme un PC est plutôt client, c'est lui qui va demander des infos au serveur, ce n'est pas le serveur qui va décider de lui parler de lui-même (il a autre chose à faire, le bougre, que de faire la causette aux nouveaux qui lui demandent rien !!). Le PC va donc lancer une séquence ARP vers le serveur pour mettre à jour sa table et le serveur va en profiter pour détecter la modification d'adresse MAC et mettre à jour sa propre table !
Mais imaginons que vous remplaciez une station qui ne cause pas toute seule sans être sollicitée ! Imaginez que vous remplaciez un serveur ou un routeur !! Pensez-bien à faire rebooter les PC du LAN ... Sinon ... Plus de communication avec le serveur ou le routeur ! Toutes les tables ARP des stations sont fausses pour la résolution d'adresse de l'équipement que vous avez remplacé !
ARP et la passerelle par défaut
Dans les exemples de routage des chapitres précédents, et notamment dans le paragraphe "Sortir du réseau" du chapitre 6, nous avons vu qu'une station envoie son paquet à une passerelle par défaut lorsque le paquet est à destination d'un autre réseau IP.
Nous avons très succintement évoqué le rôle d'ARP dans ce mécanisme. En effet, comment envoyer un paquet IP à destination de 12.0.0.1 en voulant le tranférer à 10.0.0.254 sans changer l'adresse IP du paquet ? C'est simple ... On l'envoie dans une trame ayant pour adresse destination, l'adresse MAC du routeur (passerelle).
Lorsque la station doit envoyer un paquet en dehors de son réseau IP, elle scrute sa configuration pour trouver l'adresse de Gateway Default que vous lui avez donné lors de son installation. Puis elle regarde dans sa table ARP, l'adresse MAC correspondante à l'adresse IP de la Gateway Default. Si celle-ci existe dans la table ARP, la station encapsule son paquet IP dans une trame à destination de l'adresse MAC de la passerelle. Si celle-ci n'existe pas, elle lance une procédure de résolution d'adresse ARP, telle que nous l'avons précédemment étudié !
Et le tour est joué ! La passerelle reçoit une trame qui lui est destinée et qui véhicule un paquet IP qui ne lui est pas destiné. Elle applique l'organigramme de routage tel que nous l'avons vu au chapitre 6.
La tempête du matin ...
Tous le monde commence son travail entre 8 et 9 heures le matin ... Enfin c'est la moyenne des bureaux ... En arrivant la première opération est d'allumer son PC avant même de retirer son manteau (on espère que Windows aura fini son boot quand on sera revenu du premier café !).
Comme les tables ARP sont vides à ce moment là (rappelez-vous, elles sont stockées en RAM, donc volatile). Dès qu'on va appelé un serveur il va falloir renseigner la table ARP. Chaque fois qu'on appelle une ressource il faut de nouveau renseigner cette table.
Les requêtes sont véhiculées par des trames "broadcast", qui sont donc luent par toutes les stations. Bien souvent seuls les serveurs sont sollicités et sont donc les seuls à répondre.
Quoiqu'il en soit, lorsque vous placez un analyseur sur un réseau LAN vous assistez à des "tempêtes de broadcast" dans ce créneau horaire. Ceci entraîne une surcharge momentanée du réseau ... Il est déconseillé de procéder dans ce créneau horaire à des opérations lourdes de duplication de bases par exemple !! Vous noterez un ralentissement non négligeable !
Les serveurs doivent répondre à des centaines de requêtes ARP, le LAN véhicule deux trames par requête, toutes les stations lisent les broadcast des requêtes ARP ... Et on travaille quand ?
ARP et la sécurité !
ARP est un bonheur pour les "hackers" et une plaie pour les administrateurs. En effet grâce à ARP, si vous avez les moyens d'accèder au LAN, vous pouvez connaître très rapidement l'ensemble des stations présentent sur un LAN !
Avec un peu de connaissance, vous pouvez programmer un petit utilitaire ou installer sur votre PC un analyseur qui va scruter le contenu de tous les ARP_Request et ARP_Reply émis sur le LAN. Vous aurez ainsi découvert toutes les adresses niveau 2 et 3 des équipements du LAN.
Ne reste plus qu'à faire "sauter" les protections des couches supérieures ...
Vous pouvez même vous substituer à une station lorsque celle-ci aura réalisé son authentification d'accès auprès d'un serveur !! Vous attendez qu'elle entre son login/password en surveillant le trafic. Puis vous reprogrammez votre station avec l'@MAC et l'@IP de la station. Vous accédez ainsi en son nom au serveur, et lui ni voit que du feu !
Vous allez me dire qu'il faut quand même accéder au LAN ! Certes, mais les anglo-saxons estiment que 70% des actes de piratages ont pour source l'intérieur de l'entreprise. Je vous accorde qu'ils sont un peu parano, mais ...
Rassurez-vous, des mécanismes de couches supérieures permettent de vaincre ce trou de sécurité, mais il existe aussi des moyens de les faires sauter !
|
Le proxy-ARP, c'est quoi ?
Vous avez peut-être déjà croisé ce terme en vous demandant pourquoi un ARP de proximité ? En fait c'est un ARP qui trompe !!
Supposons que votre entreprise rachète une autre entreprise (disons que vous travaillez chez Cisco, Intel ou Microsoft !). Le siège de cette nouvelle entreprise posséde un réseau local supportant l'adresse réseau 10.0.0.0. Pas de chance ! C'est la même adresse réseau que celle de votre siège ! Et bien sûr, votre PDG veut que vous interconnectiez les deux sites (heu .. Plutôt DSI ! Un PDG, ne sait pas ce que veut dire "interconnecter" ! Lui il dit : "Fusionner moi nos bases de connaissances !").
Vous voilà bien embêté ! Si vous placez un routeur entre les deux, il va être malade si vous placez chacune de ces interfaces dans le même réseau IP (croyez-moi, il ne se laissera pas faire ! Belliqueux l'engin !).
Mais dans votre malheur, vous avez un peu de chance (croyez-moi, profitez-en ! Parce que c'est pas souvent !). En effet, en examinant le plan d'adressage de l'entreprise achetée vous remarquez que tous les équipements de son réseau local ont pour adresses 10.1.X.X avec un masque 255.0.0.0. Or vos stations sont toutes avec une adresse 10.2.X.X/8 ! Quelle chance (croyez-moi ! J'insiste ! C'est pas souvent !) ! Vous allez vous en sortir avec Proxy-ARP, sans être obligé de reprogrammer toutes les stations (ben oui .. Vous connaissez pas DHCP alors vous en êtes pour vos frais .. C'était une petite remarque à l'attention des experts dans le fond de la salle, qui sont tordus de rire !).
Vous avez remarqué que les stations avaient un masque de réseau classe A sans sous-réseau. Autrement dit, la station 10.2.0.1 de votre siège estime que le serveur 10.1.0.1 du siège de l'entreprise achetée est sur son réseau IP ! Elle va donc tenter de le contacter directement sans passer par votre routeur installé entre les deux réseaux ! Quand elle lancera une requête ARP pour connaître l'adresse MAC du serveur, elle n'obtiendra rien puisqu'il n'est pas sur son LAN !
En installant un routeur entre les deux réseaux, qui implémente la fonction Proxy-ARP vous allez résoudre le problème ! Vous devez simplement placer chaque interface du routeur dans un sous-réseau différent :
Si la fonction Proxy-ARP est implémentée dans le routeur, voici ce qui va se passer :
Et c'est très bien comme ça ! Le routeur pourra router les paquets et tout le monde sera content !
C'est ça le Proxy-ARP !!
|
Conclusion du chapitre
Ouf ! C'en est fini d'ARP ! Pas compliqué, mais difficile à expliquer par écrit !! Pas trop fatiguant ce chapitre ? Normal ! On prenait des forces pour la suite ...
Dans le chapitre suivant (pour se réveiller) on va fragmenter le paquet IP ! C'est sympa un paquet IP en petits morceaux, non ?
|
Commentaires
Enregistrer un commentaire