- Deuxième question : Si je connecte sur l'un des ports (imaginons le port 19) d'un switch(numéro 1) un autre switch(numéro 2) sur lequel plusieurs machines sont connectées(sur le switch numéro 2). Il est dit que la table CAM du switch numéro 1 aura, pour le port numéro 19 plusieurs adresse MAC (qui corrsepondent en fait au adresse MAC des différentes machines qui sont connectées sur le switch numéro 2) comme le montre cette photo :
Hors la table MAC n'est-elle pas censées mettre à jour ses données et donc n'avoir qu'une seule adresse MAC correspondant à son port 19 (l'adresse MAC sera donc l'adresse de la machine qui a parlé le plus récemment)?
- Dernière question : Je ne comprends pas bien ce qu'il veut dire dans son cour lorsqu'il dit :
"Le switch peut-il découvrir les adresses MAC des machines sur le réseau ?
Normalement non. Ce n'est pas son rôle, le switch est un élément passif. D'ailleurs, une machine qui est branchée sur un switch envoie la plupart du temps une trame au réseau quand elle voit que sa carte réseau est branchée, donc le switch la verra et mettra à jour sa table CAM."
Hello Bats et bienvenue dans le monde merveilleux du réseau (attention aux traversées de Licornes tout de même)
1. Oui, les @MAC sont censées être uniques. Elles sont en effet "gravées" en dur sur tes interfaces réseaux physiques. Sur une VM (machine virtuelle), tes interfaces ne sont pas physiques mais virtuelles donc si c'est toi qui manage ton environnement de virtualisation (hyperviseur), tu peux très bien fixer toi même cette @MAC virtuelle.
A savoir également qu'en pratique, des solutions existent qui te permettent de la changer ou du moins, d'envoyer des messages sur le réseau en faisant croire que tu émets avec une autre @MAC. C'est d'ailleurs un problème, puisque des "hackers" mal intentionnés peuvent lancer des attaques appelées MAC spoofing qui consistent à écouter le réseau puis se faire passer pour quelqu'un d'autre en utilisant les @MAC écoutées.
Également, le problème avec les @MAC uniques c'est la vie privée. En effet, des solutions existent qui permettent de te tracer puisque cette adresse ne change jamais. Il n'y a pas longtemps, Apple a intégré dans iOS une fonctionnalité qui fait que ton smartphone change à chaque fois d'adresse MAC quand il émet des paquets liés à la recherche d'un réseau Wi-Fi (exemple d'article à ce sujet).
2. Attention au vocabulaire : la table MAC est la table que le commutateur remplit pour se remémorer des correspondances @MAC --> port à utiliser et qu'il a apprises.
La CAM (Content-Addressable Memory) est un type de mémoire physique (composant hardware). Il se trouve que la table MAC (tableau logiciel) est enregistré sur ce support physique qu'est la CAM. La TCAM (Ternary CAM) est un type de CAM particulier à 3 états (au lieu des états binaire - donc 2 états - de la CAM traditionnelle) qui est d'ailleurs un élément TRES cher (et donc une ressource à optimiser) sur un commutateur.
3. C'est tout à fait normal que ta table MAC sur ton switch contienne plusieurs adresses pour un même port. Cela signifie simplement que si le switch reçoit une trame à destination de ces adresses, il sait grâce à sa table MAC qu'il doit les faire suivre sur son port 19 (donc vers le switch 2) ce qui est bien le comportement souhaité
4. Par rapport à la question du cours, imagine qu'un ordinateur soit branché sur un switch mais n'émette aucune trame. Le switch connait-il l'adresse MAC de cet ordinateur ? Si non, pourquoi ? Si oui, comment l'a-t-il déterminé ?
Cependant lorsque j'ai dis que je pouvais changer mon adresse MAC je ne parlais pas de potentielle VM mais réellement celle de mon pc. Je suis désolé mais je débute vraiment dans ce domaine je comprends encore pas grand chose.
Pour ce qui est de la table MAC, il est écrit dans le cours de la table qui associe @MAC et port est bien la table CAM (donc un composant hardware selon tes explications) est-ce une erreur ? (en fait il ne fais absolument pas mention de la table MAC dans son cour ).
Enfin le fait que le switch associe plusieurs @MAC à un même port montre donc que l'informations la plus ancienne n'est pas supprimé ? Je m'explique :
s'il avait Port 1 -> @MAC 20 (dans sa table MAC )et qu'il reçoit ensuite une trame sur son Port 1 mais @MAC SRC = @MAC 21 (au lieu de @MAC 20)
Le switch va-t-il modifier dans sa table MAC l'association Port 1 -> @MAC 20 par Port 1 -> @MAC 21 (ce que je croyais qu'il faisait) ou va-t-il simplement rajouter une ligne et aura donc :
Port 1 -> @MAC 20 Port 1 -> @MAC 21
Il me semblait qu'il ne gardait que l'information la plus récente
Concernant le changement d'adresse MAC, oui il est possible de changer l'adresse MAC d'une de tes interfaces physiques. Ce n'est pas un comportement "normal" au sens de la théorie des réseaux, c'est simplement le premier élément qui te permet de comprendre qu'il y a parfois des différences entre la théorie nécessaire à la compréhension des choses et la pratique Tu verras par la suivre d'autres phénomènes qui n'étaient pas envisagés dans la théorie et qui ont émergé pour des raisons pratiques ou des évolutions de l'usage d'internet (ex: apparition du NAT opérateur en raison de la pénurie d'adresses IPv4 car quand le protocole a été inventé, on ne pensait pas qu'il y aurait un jour besoin de plus d'adresses que ça !).
Le terme "table CAM" doit être un abus de langage tout simplement. Dans la pratique, je parle de table MAC et n'ai jamais entendu "table CAM" mais peut être pour d'autres c'est juste l'inverse ? Une chose est sure, la CAM est bien un type de mémoire. Quelques recherches Google te le confirmeront
En fait ce qu'il faut changer dans ta compréhension c'est les correspondances @MAC/port. Elles se font dans l'autre sens : @MAC --> PORT. Sur un switch, si un ordinateur avec la mac A se connecte et discute sur le port 1, la table MAC contiendra MAC A --> Port 1. Effectivement si tu décides de débrancher ton ordinateur et te connecter sur le port 2 puis tu communiques, le switch mettra à jour sa table mac avec l'entrée MAC A --> Port 2. Si par contre sur le port 3 tu as un autre switch de branché sur lequel sont reliés 3 ordi avec les MAC B, C, D, le switch aura pour table mac :
- MAC A --> Port 2 - MAC B --> Port 3 - MAC C --> Port 3 - MAC D --> Port 3
Le switch n'a que faire de l'association inverse Port x --> MAC y, cette information ne lui servirait à rien pour commuter des trames.
Ah bah tiens j'en ai une justement . J'en arrive au routage, je viens de finir avec le découpage des plages d’adresse... Ma question ne porte pas vraiment sur le cour mais plus sur l'apprentissage en lui même.
Comment tester ses connaissances ? Je veux dire par la que en C par exemple je pouvais me tester en développant des programmes mais là... Comment s’exercer ?
En fait j'adorerai travailler plus tard dans la sécurité informatique mais je ne sais pas vraiment où donner de la tête et par où commencer... Je me suis dis que commencer par le fonctionnements des réseaux pouvait être un bon début mais ensuite ?
Enfin voila si tu as des conseilles pour progresser et apprendre le plus de chose possible je suis preneur ! ( Je précise juste je suis en école Télécom et Informatique) Merci d'avance
En réseau c'est en effet plus compliqué pour s'exercer.
En terme de pratique il faut s'orienter du côté des simulateurs type Packet Tracer (cisco only) ou GNS3, sauf si tu as a ta disposition un labo de réseau, ce qui n'est pas impossible si tu dis être en école. Sinon, pour les bases plus théoriques, les études de cas marchent aussi très bien.
Pour ta question concernant la sécu, si tu parles uniquement de sécurité des réseaux, il faudra maîtriser parfaitement la discipline, y'a pas de secret. Le reste vient avec l'expérience
Si tu veux t'exercer sur du réseau tu peux utiliser Cisco Packet Tracer, c'est une application de simulation de réseau, tu peux mettre en place des machines qui se connecte à n'importe quel matériel existant, tu peux mettre en place des connexions filaires ou wifi, tu peux créer des VLAN, sous-réseaux, etc... Bref la liste est longue, je te laisse découvrir par toi-même !
Si tu souhaite travailler au cas par cas, tu peux utiliser des VM Linux avec un Putty. Si tu utilise des VM sans interfaces graphiques tu n'aura aucun mal à les faire tourner puisqu'elles ne consomment pas grand chose et c'est un des points qui fait qu'on les utilises beaucoup en entreprise, ce qui te permettrait d'avoir une pratique plus proche du monde du travail, je pense.
Comme toi j'aimerais travailler dans la sécurité informatique mais je suis aussi perdu que toi pour le coup et je ne saurai pas te donner de conseil pour progresser, donc j'attends que Snoop nous éclaire et si j'ai fait la moindre erreur je le laisse me corriger avec plaisir.
Si vous avez un peu de budget vous pouvez acheter des vieux switches, on trouve souvent des cisco en vente pour un prix modique sur leboncoin ou ebay (par exemple un cisco 2950 100Mbps se trouve souvent à 20 ou 30€). Certains ayant passé le CCNA se sont fait un petit "labo ccna" et revendent les switches et routeurs après avoir eu la certif, le package doit pouvoir se trouver dans les 100€ de mémoire.
Effectivement pour commencer à tâter un peu la ligne de commande et la configuration d'équipements, tu peux commencer par Packet Tracer (plus simple, plus léger, pour faire des tests pas trop avancés en termes de fonctionnalités - uniquement l'OS Cisco) ou GNS3 (plus lourd, plus avancé, permet de faire des tests avec autre chose que du Cisco).
Par contre je vais nuancer un peu ce qui a été dit plus haut. Il y a une différence non négligeable entre savoir configurer des équipements réseau et comprendre ce qui se passe vraiment au niveau protocolaire. Mettre en place un routage OSPF sur une petite dizaine d'équipements, c'est fait en quelques lignes de commande et il est tout à fait possible de le faire sans avoir la moindre notion de ce qu'est réellement un protocole de routage. Pareil pour le protocole ARP par exemple, tu peux très bien t'en servir sans t'en rendre compte et sans comprendre ce qu'il se passe.
Du coup, pour quelqu'un qui veut s'orienter vers de la sécurité réseau, il est très important de réellement comprendre les différents protocoles, comment les équipements échangent entre eux et via quels mécanismes. Il te faudra donc passer pas mal de temps à faire de la théorie.
Également, c'est bien beau de savoir configurer un réseau mais je te conseille également d'utiliser un analyseur de trames (Wireshark, what else?) qui te permettra de faire des captures de l'ensemble des messages échangés sur une interface et ensuite d'analyser un peu tout ça. Au début ça fait un peu peur mais au moins ça te permet de te rendre compte de la complexité des échanges entre différents équipements et par la suite ça te permettra d'analyser finement le mécanisme d'un protocole ou le comportement d'un équipement suite à un évènement dans le réseau (ex : comment mon protocole de routage sur tel routeur avertit le reste du réseau que ce subnet n'est plus joignable quand je coupe tel lien).
Une chose qui peut être très pénible mais également très instructive c'est de lire quelques RFC. Ce sont des documents qui définissent et détaillent des standards. Par exemple ARP est défini dans la RFC 826.
A t'entendre parler Snoop_cat ça me donne encore plus envie de m'y mettre à fond, ça à l'air vraiment génial ! Pour avoir une idée , ne connaissant pas vraiment ce domaine, en combien de temps peut on acquérir de bonnes bases en réseaux pour commencer à bidouiller chez soit ? C'est sûrement propre à chacun mais en moyenne j'entends. Avant de commencer à s'amuser il y a toujours des étapes un peu "ennuyeuses" où on ne fait qu'apprendre (comme partout hein !) sans vraiment voir où ça mène si vous voyez ce que je veux dire...
T'inquiètes, tu peux commencer à bidouiller chez toi sans avoir des bases en béton. En fait, tu peux commencer à bidouiller, mettre en place un réseau, etc... Et au fur et à mesure que tu apprends, tu fais des modifs sur ton installation.
Un truc pas mal, que j'ai pu faire chez moi : trouve un vieil ordinateur (portable ou fixe), et installe une distro serveur dessus (ou celle que tu veux après tout, le truc c'est d'avoir une machine que tu peux faire planter sans le regretter ). Tu mets en place le genre de réseau que tu veux, et tu le fais évoluer. Ça permet de manipuler un peu ce que tu apprends. Tu peux aussi utiliser des VM, mais si tu veux en faire tourner plusieurs en même temps sans qu'elles rament à mort, il faut pas mal de RAM et un CPU qui suit (ou alors j'utilise mes VM comme un gland )
Et le jour où tu te rends compte que ton truc est complètement non-sécurisé, ou que c'est un bordel monstre, tu formates et tu repars de 0 ! Avec tes nouvelles bases plus solides.
Voilà, je dis pas que c'est LE truc à faire... Juste une idée
- Edité par apple.juice 18 juin 2016 à 8:20:38
M'en veuillez pas. Si je suis ici c'est que je suis vraiment crevé :^D
Concernant le changement d'adresse MAC, oui il est possible de changer l'adresse MAC d'une de tes interfaces physiques. Ce n'est pas un comportement "normal" au sens de la théorie des réseaux, c'est simplement le premier élément qui te permet de comprendre qu'il y a parfois des différences entre la théorie nécessaire à la compréhension des choses et la pratique
Il se trouve que c'est extrêmement utile, dans plusieurs circonstances,
quand une machine doit être capable de prendre _immédiatement_ le relais d'une autre machine (serveur) défaillante, en prenant son adresse IP. Les autres machines du réseau local ont encore dans leur cache ARP la correspondance entre le numéro IP et l'adresse MAC de l'ancienne, et personne n'a envie d'attendre 2 minutes que les infos soient considérées comme périmées. Alors le nouveau serveur se donne l'adresse MAC (et IP) de l'ancien.
quand certains éléments du réseau ont, par sécurité, des tables ARP fixes. Ca sert pour éviter l'usurpation d'adresse IP, sur certaines adresses sensibles. Par exemple les étudiants qui ont mal configuré leur portable et le branchent sur un réseau d'université. Ca serait dommage qu'ils embrouillent la communication entre deux serveurs de ce réseau local. Donc quand on remplace un de ces éléments, soit il faut mettre à jour toutes les tables fixes, soit on pique l'ancienne adresse MAC.
Il se trouve que c'est extrêmement utile, dans plusieurs circonstances,
quand une machine doit être capable de prendre _immédiatement_ le relais d'une autre machine (serveur) défaillante, en prenant son adresse IP. Les autres machines du réseau local ont encore dans leur cache ARP la correspondance entre le numéro IP et l'adresse MAC de l'ancienne, et personne n'a envie d'attendre 2 minutes que les infos soient considérées comme périmées. Alors le nouveau serveur se donne l'adresse MAC (et IP) de l'ancien.
quand certains éléments du réseau ont, par sécurité, des tables ARP fixes. Ça sert pour éviter l'usurpation d'adresse IP, sur certaines adresses sensibles. Par exemple les étudiants qui ont mal configuré leur portable et le branchent sur un réseau d'université. Ca serait dommage qu'ils embrouillent la communication entre deux serveurs de ce réseau local. Donc quand on remplace un de ces éléments, soit il faut mettre à jour toutes les tables fixes, soit on pique l'ancienne adresse MAC.
Tu as tout à fait raison et ces cas d'usage existent bien dans la nature. Cependant, tu vas bien dans le sens de ce que je dis, à savoir que ceci n'est pas le comportement normal qu'on peut attendre d'un équipement réseau, c'est tout simplement un mécanisme mis en place par les gens de l'infra pour pallier à un problème/besoin métier/applicatif.
Le problème actuel c'est que les applicatifs qui tournent sur nos chers serveurs ne sont pas conçus pour être résilients alors que le besoin est en fait une application résiliente. Du coup, on nous demande à nous (on exige plutôt) qu'on mette en place des mécanismes compliqués qui "cassent" les comportements normaux. Pour le dire autrement, on appelle ça du bricolage. Le bricolage, ça fait souvent l'affaire mais c'est compliqué et "moche". Ça nécessite bien souvent de souscrire des contrats très chers de maintenance et de support pour assurer des SLA très serrés (GTR +4h, ça coûte cher !)
Dans tout ça, la tendance pour les nouvelles applications développées en ce moment est de prendre en compte cette résilience et le problème de la scalabilité "by design" au niveau applicatif. Tu veux de la résilience ou plus de capacité ? Tu bootes des VMs supplémentaires et le tour est joué. Plus de contraintes sur l'infra. On n'arrête plus le progrès
Ce n'est du "bricolage" que si tu considères au départ que l'adresse MAC doit être fixée au départ en dur et intangible (ce qui est faux pour quasiment toutes les cartes réseau). Alors parler de ce qui est "normal"....
Il faut revenir à la réalité : sur une machine qui vient de fumer, les applicatifs résilients, ils ne fonctionnent pas, et les trames destinées à son adresse MAC, elles n'arriveront nulle part si une autre machine ne s'est pas configurée avec.
Justement, les machines virtuelles, elles n'ont pas d'adresse MAC figée !
Ce n'est du "bricolage" que si tu considères au départ que l'adresse MAC doit être fixée au départ en dur et intangible (ce qui est faux pour quasiment toutes les cartes réseau). Alors parler de ce qui est "normal"....
Quand je dis "normal", ça renvoie à la théorie de base et justement pas à ce qu'on voit ou non dans le monde réel. Tu peux tourner les choses comme tu veux, le principe de l'adresse MAC a été pensé pour être unique au monde. Quand à son usage actuel, effectivement il diffère régulièrement de cette caractéristique initiale, je ne dis pas le contraire. En fait, on dit la même chose..
J'ai évoqué le terme bricolage car on demande à des gens (infra) de faire le boulot qui aurait du être fait aux niveaux supérieurs (applicatif) et cela nécessite souvent de faire des choses complexes qui n'ont en théorie pas lieu d'être. Si tu penses que c'est normal qu'on doive forcer un serveur à "voler" celle d'un autre pour qu'un service continue à tourner, je pense que tu manques un peu de recul. Ce n'est pas parce que quelque chose se fait en pratique que l'on devrait effectivement faire comme ça (autres exemples : CG-NAT, L2 étendu au dessus d'un WAN,...).
michelbillaud a écrit:
Il faut revenir à la réalité : sur une machine qui vient de fumer, les applicatifs résilients, ils ne fonctionnent pas, et les trames destinées à son adresse MAC, elles n'arriveront nulle part si une autre machine ne s'est pas configurée avec.
Justement, les machines virtuelles, elles n'ont pas d'adresse MAC figée !
Une application bien conçue (actuellement, certains parlent d'application "cloud-native" pour désigner ce dont je parle, n'hésitez pas à Googeliser le terme) sait scaler de manière automatique et sait prendre en compte la défaillance d'un nœud (d'un serveur) pour continuer à tourner sans interruption. Bien sur, si ton application tourne sur un seul serveur physique, une défaillance physique peut toujours survenir mais dans ce cas, qu'on n'aille pas me parler d'application résiliente si le matériel constitue déjà un SPOF...
Questions de débutant en réseau
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Blond, bouclé, toujours le sourire aux lèvres...