filtrage @ MAC en VPN

par **calamarz** » 27 Jan 2003 14:17

Voilà une petite question je voudais savoir si il est possible de filtrer les users entre deux reseaux VPN avec les @ MAC (pour une securité maximum). Une autre question quelqun connait un bon outils gratuit d'analyse de bande passante pour voir l'utilisation d'un VPN. Merci <IMG SRC="images/smiles/icon_bise.gif">

par **West** » 27 Jan 2003 17:53

Je crois que C impossible, les adresses mac ne passent les routeurs ou autre matériel fonctionnant jusqu'a la couche 2 je crois . Sinon pour l'autre question, G pas la réponse mais ça m'interresse aussi !!

par **Sebray** » 28 Jan 2003 10:24

Que cela soit possible ou pas, je n'en sait rien... Par contre les adresses MAC passent les routeurs (couche 3 du modèle OSI). N'importe quel analyseur de trame vous le montrera. Le format d'une trame ethernet est le suivant : 8 octets : préambule 6 octets : @ MAC destinataire 6 octets : @ MAC source 2 octets : type de trame 46 à 1500 octets : données 4 octets :CRC le champ "type de trame" nous donnera le format des données encapsulé dans le champ données : ARP, IP, etc... Donc les ordinateurs et les routeurs voient les @ MAC avant les @ IP. Concernant le filtrage sur @ MAC, les meilleurs routeurs le font (ALCATEL, CISCO, HP, 3COM), ceux qui sont manageable (donc très rarement accessible a une clientèle de particulier), évidemment ! D'ailleurs, pour ceux qui font du VLAN, il est même possible pour ces routeurs de mettre en place une attribution du VLAN par l'adresse MAC... mais là je m'égare. Tout ca pour dire que les @ MAC passe les routeurs/passerelles, les switch (niveau 2 modèle OSI) et les hubs (niveau 1 du modèle OSI)... @ peluche Seb

par **West** » 29 Jan 2003 02:18

T sur qu'il s'agit de l'adresse du pc source ?? ça m'étonne quand qu'un routeur transporte jusqu'a la fin l'adr mac du poste source . A moins ke je me plante mais je pense k'il s'agit de l'adresse du réseau "local" du routeur, apres il fé un routage a son interface ext, pour rechercher l'adr ip du dest. ainsi de suite ....

par **antolien** » 29 Jan 2003 02:51

je me suis posé la question pendant un temps. mais après reflexion, cela me parraït un peu lourd de transporter une adresse mac à travers les routeurs. les hubs et switchs je veux bien mais les routeurs je pense que non. dans le cas contraire, pourkoi avoir inventé l'addresse ip ? je pense que les équipements rézo voient les @ mac en local mais ne les diffusent pas sur le réseau public. quand à ton insinuation sebray, "les adresses MAC passent les routeurs" , cela me parraît tendu, et je crois que tu t'embale sur le modèle OSI , j'aimerai bien savoir ou tu as appris ça ! ce discour me parraît décousu alors je te prierai d'étayer un peu tes propos car c'est intéressant.

par **Sebray** » 29 Jan 2003 17:13

Salut à tous ! Je commencerais d'ailleurs par une petite chose : Mea Culpa, Mea Culpa, Mea Maxima Culpa ! Bon après cette démonstration de tous ce que je sais de Latin je m'en vais vous conter mes erreurs et les justifier (bah oui bon, on fait des erreurs mais qui n'en a jamais fait me jette la première pierre ! Mais aïe euh, vous aviez pas droit ! <IMG SRC="images/smiles/icon_eek.gif">) ) D'abord les miennes : effectivement les routeurs ne route pas les adresses MAC... enfin pas tout à fait. (Stooooop ! On n'a dit pas de cailloux !) Il ne les route pas parce que comme chacun l'a signalé (à sa manière!) il travaille au niveau de la couche 3 (couche réseau du modèle OSI), c'est à dire qu'il ne travaille qu'avec des adresses IP. Mais cependant il travaille quand même avec les adresses MAC pour la simple raison qu'il est connecté sur le réseau par un média : il recoit donc bien une trame au format ethernet (voir mon post précédent) qui contient une adresse MAC source et une adresse MAC destination et quelque soit le port de sorti, il fait bien repartir une trame ethernet avec une @MAC source et une @MAC destination (oui je sais, tant qu'il n'y a pas de changement de protocole réseau, mais on parle d'un routeur simple, pas d'une passerelle !) C'est donc de là que venait mon erreur. En fait, un routeur R, recoit une trame ethernet avec ces données là : @ MAC Destination = @ Mac de R @ MAC source = @ MAC du poste source ou du routeur précédent et fait repartir cette trame après analyse sous ce format là : @ MAC destination = @ MAC du poste destinataire ou du prochain routeur @ MAC source = @ MAC de R Donc effectivement, l'@ MAC source est bien perdue au passage d'un routeur. Je vais donc "étayer", pour répondre à Antolien, bien que je trouve son post un peu agressif (mais on a l'habitude ;o) ) et a qui je conseillerai peut être de prendre le temps de poster sa propre version plutôt que de dire uniquement que l'autre à tort (ce qui est vrai certes, mais qui ne fait pas avancer le schmilblick). Pourquoi avoir inventer l'adresse IP ? Euh c'est pas que l'adresse IP qui fait tous le protocole, hein ! Bah je sais pas moi, peut être que les militaires américains s'ennuyaient un jour et qu'ils ont voulus faire quelques chose avec leur dix doigts... non je plaisante! le protocole TCP/IP à été inventé par les militaires américains pour répondre à un besoin réel de vérification des données. Car si maintenant notre plus grand souci c'est de sécuriser l'envoi de ces données, il y a une trentaine d'année le plus important était d'en recevoir l'intégralité lors des connexions réseaux. Il y avait de plus un besoin de pouvoir router les trames afin de pouvoir segmenter des réseaux en unités logiques (imaginer une seule seconde si vous pouviez voir dans votre voisinage réseau tous les ordinateurs connectés dans le monde au même moment). Enfin il y avait le besoin de créer un véritable adressage, à la fois logique, évolutif et qui pourrait durer. Il aura duré plus de 30 ans avant que l'on dise que bon, il va falloir passer à IP v6. Combien de temps on aurait tenu avec du Netbios limité à 15 caractères ???? Après c'est un peu plus compliqué que " les équipements rézo voient les @ mac en local mais ne les diffusent pas sur le réseau public" et je l'explique plus bas ! Sinon j'ai appris ca à l'école, en BTS Info Gestion Admin Rézo, mais comme je l'ai expliqué plus haut, mon erreur vient d'une confusion dans mon petit esprit (donc merci à West et àtoi pour m'avoir fait me remettre en question !) Alors voici mon étaiement, et comme un dessin vaut mieux qu'un long discours, je vous fais... un long discours ! (bah oui, on peut pas faire autrement dans un forum <IMG SRC="images/smiles/icon_eek.gif">P ) Mais je vais prendre un exemple : On a donc un poste A (d'adresse IP locale 192.168.0.1 et d'adresse IP dynamique 193.124.214.214) qui veut envoyer un message sur la machine forum.ixus.net (qu'on appelera B, d'adresse 214.1.1.1) et pour ce faire il doit passer les routeurs R1 (son proxy Web) et R2 (le proxy web de B). Je rappelle les 4 couches du protocole TCP/IP (Modèle DOD) 1 - Interface réseau : i.e. Ethernet, Token Ring, ATM, ... (Couche OSI 1 et 2) 2 - Internet : IP, ICMP, IGMP, ARP (couche OSI 3) 3 - Transport : TCP et UDP (couche OSI 4) 4 - Application : HTTP, FTP, ... (couche OSI 5,6 et 7) Donc on va décomposer la communication et là attention, il va falloir suivre : 1- A veut envoyer son message sur le forum. Il est donc en couche 4 (DOD). On sait aussi que il va utiliser TCP pour communiquer (couche 3 DOD). Donc TCP encapsule donc les données dans une trame TCP. 2 - Il connait pas l'@ de B, juste son @ DNS. Il demande donc à son DNS la correspondance qui répond en lui disant : forum.ixus.net = 214.1.1.1. 3 - A vérifie dans sa table de routage comment faire pour envoyer quelque chose à 214.1.1.1 et voit qu'il doit passer par son adresse dynamique et par R1, qui a pour adresse 193.214.214.254. c'est IP qui s'occupe de ça (donc couche 2 DOD) IP encapsule donc la trame TCP das une trame IP. Mais le souci c'est que A ne connait pas l'adresse MAC de R1. 4 - A envoie donc une trame ARP en disant : " Moi c'est A(193.124.214.214), d'@ MAC AA:AA:AA:AA:AA:AA, quelle est l'@ MAC de RI(193.124.214.254)" et R1 répond par une trame RARP "Pour A(193.124.214.214),je suis R1(193.124.214.254), et mon @MAC c'est D1:D1:D1:D1:D1:D1". A va donc enfin pouvoir balancer sa trame Ethernet (couche 1 DOD) en encapsulant dedans les données d'IP. 5 - R1 recoit la trame ethernet et l'ouvre jusqu'au niveau de voir les @IP sources et destinataires, il regarde l'@ IP destinataire, vérifie qu'elle ne correspond à aucun de ses ports directs et suit alors ce que lui dise ces itinéraires statiques ou ces routes par défaut. Dans notre exemple, il sait que pour atteindre le réseau 214.1.1.0 (le réseau de B) il doit passer par R2. Si il ne connait pas l'@ MAC de R2, il balancera alors à son tour une trame ARP et R2 répondra par une RARP. R1 pourra donc ensuite tout réencapsuler comme nous l'avons vu au début (en remplacant les @ MAC sources et destination) dans une trame ethernet et balancer sur le port ou il sait que R2 est branché. 6 - Quand R2 recoit le paquet, il décortique à son tour, voit que l'adresse du réseau destinataire correspond à de ses ports directs et balance ne réencapsulant. (c'est le même principe que le point 5) 7 - B recoit de R2 sa trame et lorsqu'il l'ouvre, il peut voir que son expediteur est A d'@ IP 193.124.214.214. Si il veut lui répondre, il devra tout refaire en sens inverse. Voilà voilà, je pense que ce post aura été ma plus grande contribution, quelque soit mon pseudo sous Ixus, mais bon, il était important de rectifier les erreurs. Ciao et @ peluche Seb <IMG SRC="images/smiles/icon_bise.gif"> ---- L'édition (29/01/03) a permis la correction de quelques fautes d'orthographe et une remise en page du post----

par **antolien** » 29 Jan 2003 17:38

Hum, à moi de m'excuser, j'ai encore été agressif sans le vouloir. on me fait souvent la remarque alors je vais y faire attention. sebray, je comprend mieux ce que tu voulai dire. bon, alors, j'ai peut être lu un peu rapidement ce que tu as écrit, mais je voudrai ajouter que le routeur A ne connait pas l'@ MAC du poste de destination derrière le routeur B. c'est le routeur B qui connait les @ MAC de son coté LAN. la requette se fait au niveau de l'@ip @mac->routeur A<->(tcp/ip)<->routeur B->@mac maintenant, peut être que je dis des bétises, mais c'est comme ça que je vois la chose.

par **antolien** » 29 Jan 2003 18:01

par contre il y a une faille sur les cartes ethernet <a href="http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf" target="_blank">http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf</a> et pour le sans fil <a href="http://www.reseaux-telecoms.net/news_btree/03_01_24_133142_214/News_view" target="_blank">http://www.reseaux-telecoms.net/news_btree/03_01_24_133142_214/News_view</a>

par **Sebray** » 30 Jan 2003 10:39

Effectivement Antolien, comme tu le dit, A ne connait pas les adresses MAC des routeurs et ou postes qui ne sont pas dans l'un de ses réseaux. Ceci pour plusieurs raisons d'ailleurs : la première c'est que les trames ARP ne sont pas routables, il ne peut donc pas y avoir de résolution IP/MAC ou MAC/IP (dans le cas d'une RARP) et la deuxième, qui est vraisemblablement la plus importante, c'est que cela ne servirait à rien : On a déjà un protocole IP qui lui est routable et qui utilise les tables de routages pour savoir ou il doit envoyer ces trames (en utilisant les itinéraire statiques et les routes par défaut. Attention d'ailleurs, une résolution IP se fait dans un certain ordre, pour l'exemple, un itinéraire statique est prioritaire sur une route par défaut !). C'est donc réalisé bien plus haut dans les couches que les questions MAC. Mais pourquoi est ce qu'on s'$%#&! alors à encapsuler en ethernet alors que seul de l'IP suffirait ??? Bah c'est simple, si votre poste est connecté à un hub, un switch, un transceiver ou un pont avant un routeur, vous ne pourrez pas les passer si vous présentez seulement des trame IP. Ces 4 là, je crois, ne peuvent travailler autrement qu'avec des adresses MAC. Salut @ tous et @ peluche Seb

par **West** » 30 Jan 2003 13:42

Re salut Vous avez une réponse à la 2eme question : Une autre question quelqun connait un bon outils gratuit d'analyse de bande passante pour voir l'utilisation d'un VPN Car elle m'interesse aussi, mais pas seulement pour le vpn, mais pour un réseau ethernet tout court . merci

par **Sebray** » 31 Jan 2003 10:38

Salut... Eventuellement si tu as win2K server tu peux installer le moniteur réseau qui marche pas trop mal.. Sinon le meilleur des meilleurs reste pour moi Sniffer Pro, mais il est pas gratuit Enfin en gratuit mais bon un peu léger peut être, ca te suffira peut être, tu as lite sniffer, directement télécheargeable à l'adresse suivante : <A HREF="http://www.packx.net/packx/download/litesniffer/0.20beta/LiTe%20Sniffer%20v0.20%20beta.zip" TARGET="_blank">http://www.packx.net/packx/download/litesniffer/0.20beta/LiTe%20Sniffer%20v0.20%20beta.zip</A>

filtrage @ MAC en VPN

Qui est en ligne ?