Je sais que la route par défaut (ou gateway) est l’interface réseau (ou adresse ip) du routeur que doit emprunter un paquet pour sortir d’un réseau et aller vers un autre réseau (comme le réseau internet par exemple).
Et donc lorsque, depuis un poste client, je souhaite accéder à un site internet (comme foo.com par exemple) d’adresse ip 88.111.222.333 par exemple, la trame ethernet va au switch puis à la route par défaut (càd le routeur), puis dans le réseau internet, jusqu’au serveur web de foo.com.
Mais si la trame ethernet qui arrive au switch a comme valeur du champ adresse ip de destination « 88.111.222.333 », comment le switch sait qu’il faut transmettre cette trame vers la route par défaut (càd vers le routeur) ?
Y aurait-il un champ supplémentaire dans la trame qui indique l’adresse ip ou l’adresse mac de la route par défaut ?
Le modèle OSI est effectivement très important là-dedans. Mais aussi le principe d’encapsulation réseau .
( la page Wikipedia est illustrée avec le modèle TCP/IP, différent du modèle OSI, mais le principe reste le même )
Dans le modèle OSI, IP se situe à la couche 3 « réseau » alors que MAC est la couche 2 « liaison ».
Pour faire très court, lorsque ta machine veut faire parvenir des données à une adresse IP qui demande de passer par un routeur / une passerelle, elle envoie :
des données de niveau 3, un paquet IP avec une adresse IP d’expéditeur (la sienne) et une adresse IP du destinataire final. Ces données sont encapsulées dans …
des données de niveau 2, une trame (Ethernet, disons) avec une adresse MAC expéditeur (la sienne) et une adresse MAC destinataire, qui est celle du routeur / la passerelle. Ces données sont encapsulées dans …
des données de niveau 1, le Ethernet qui passe dans les fils
De son coté, le routeur voit arriver une trame avec son adresse MAC comme destinataire donc il sait qu’il doit continuer à la traiter.
Il regarde ensuite la couche 3 des données reçues et si l’adresse IP de destination est une adresse qui ne lui appartient pas, il fait suivre / « forwarde » / « route » le paquet.
Comment la machine source connaît l’adresse MAC de la passerelle / du routeur ? En utilisant le protocole ARP .
On peut étudier un exemple de « ping » et ARP en utilisant le site Cloudshark : cloudshark - arp.pcap
En sélectionnant un « paquet » dans la liste, on peut voir l’ensemble des couches de données.
Il y aurait encore beaucoup à dire mais c’est le principal.
Un switch n’est pas un routeur. Il ne sera pas concerné par le routage sauf s’il inclut des fonctionnalités de routage auquel cas ce n’est plus exclusivement un switch.
La machine cliente a pour adresse de passerelle une adresse qui est dans son sous-réseau (obligatoirement).
Le protocole IP est conçu pour gérer cet aspect. Seuls les routeurs sont concerné par le routage.
Le routage consiste à passer d’un sous-réseau à un autre, jusqu’à l’arrivée à destination.
La route par défaut ne se trouve pas dans la trame (à moins d’être source-routée, mais dans ce cas de nombreux système de sécurité vont rejeter le paquet).
C’est du forward de passerelle en passerelle.
Pour chaque interface d’un sous-réseau correspond une passerelle dans ce sous réseau. Chaque routeur dispose d’une passerelle par défaut, qui elle correspond à l’équipement à qui envoyer les trame dont le routeur ne sait pas quoi faire.
En clair:
un routeur transmet un paquet d’un réseau vers un sous-réseau qu’il connaît si ce sous-réseau est la destination du paquet.
Si le paquet a pour destination un sous-réseau qu’il ne connaît pas, alors il envoie le paquet à sa passerelle par défaut.
Quand plusieurs routes sont possible, il y a des protocole qu permettent d’aider à la décision comme l’OSPF, ou le BGP (exemple non exhaustifs)
La règle est simple:
Un switch ne route pas, car ce n’est sa fonction première. Aujourd’hui il y a des switch de niveau 3 qui de facto peuvent être aussi des routeurs.
Mais fonctionnellement un switch ne route pas, seul un routeur le fait. Un équipement matériel peut endosser les deux rôles.
Les adresses mac ne sont connues que dans un même sous-réseau physique (donc pas de couche OSI au delà de IP).
Le routage n’utilise pas la moindre encapsulation de quoi que ce soit.
L’encapsulation consiste à avoir un paquet (en-tête+data) dont les data contiennent elle-même un en-tête et des datas d’un paquet encapsulé.
En simple, un colis avec un émetteur et un destinataire qui contient un autre colis avec un émetteur et un destinataire.
MAC est effectivement à la couche 2 et ne permet que des communication entre deux interfaces (c’est en quelque sorte l’équivalent du sous-réseau IPv6 fe80::).
En couche 2 le protocole est ARP, en couche 3 c’est IP en couche 4 c’est TCP ou UDP.
Un paquet est composé de deux partie:
une partie en-tête (header) qui contient les information nécessaire au transport c’est la partie IP (mais qui contient des informations nécessaire aux couches inférieures) mais aussi les datas nécessaires au protocole TCP par exemple ou tout autre protocole.
Une partie data qui va contenir les données transmises. A noter que l’en-tête contient la taille correspondante aux données. Certaines attaques se basent sur le fait de déclarer une taille de données différentes du contenu réel des données, permettant ainsi de tromper les piles de communication pour faire de l’overlap de paquets. Mais c’est un autre sujet.
La partier data peut très bien contenir des informations qui comportent elles-aussi un en-tête et des données. Dans ce cas, et dans ce cas uniquement c’est de l’encapsulation.
PC, ip 192.168.0.42/24 , mac aa:bb:cc:11:22:33 → je veux parler à 88.111.222.333
sa table de routage lui dit :
0.0.0.0/0 via 192.168.0.1 metric 1 dev ens192
et son cache ARP ne contient pas de mac address pour 192.168.0.1
donc PC va chercher SA gateway en faisant un broadcast ARP pour apprendre la mac de l’ip 192.168.0.1 qu’il a en default-route :
<sourceMAC aa:bb:cc:11:22:33 sourceIP 192.168.0.42 ; destMAC ff:ff:ff:ff:ff:ff destIP 192.168.0.255> « whois 192.168.0.1, Tell 192.168.0.42 »
Paquet transite via le switch programmable qui n’a même pas été programmé parce que le prestataire est un peintre (ce qui permet de démontrer le distingo entre la couche 3 et 2 d’OSI qui lui suffit à faire son taff de commutateur).
à ce stade le switch ne sait pas/plus ou est branché le routeur car son cache ARP est vierge de son entrée (normal, il a pas d’ip le switch, foutu presta), ainsi que sa MAC-ADDRESS-TABLE (ca c’est signe que le routeur il a pas parlé sur le lan depuis 1-5 min selon marque/modèle du switch → paramètre par défaut de la durée du cache de la mac-address-table).
Le switch voit passer le paquet du PC sur son port 1/17, ce qui refresh l’entrée de la mac aa:bb:cc:11:22:33 du PC sur le vlan1 (ben oui, switch non programmé, hein) port 1/17 dans sa MAC-Address-table.
Comme il ne sait pas ou est le routeur il inonde tous les ports qui sont membres du vlan1 (pas programmé → tous les ports, donc)
Le routeur 192.168.0.1 reçoit ce broadcast et répond :
<sourceMAC 01:23:45:aa:dd:cc sourceIP 192.168.0.1 ; destMAC aa:bb:cc:11:22:33 destIP 192.168.0.42> « 192.168.0.1 is at 01:23:45:aa:dd:cc »
du coup le switch voit la MAC du routeur (il vient d’émettre un paquet) et refresh sa mac-address-table : vlan1 port 1/48 01:23:45:aa:dd:cc
et il commute le retour de paquet uniquement sur le port 1/17 (puisque sa mac-addres-table dispose encore de l’entrée aa:bb:cc:11:22:33) (grace à la mac-destination qui est maintenant celle du PC : le routeur lui répond, en LAN on parle de MAC à MAC, une fois qu’on a une association IP-MAC dans notre cache arp local).
maintenant que ton PC a reçu la mac du routeur (il l’a inscrite dans son cache arp, vérifie avec arp -a 192.168.0.1), tu envoies réellement le paquet suivant à 88.111.222.333 via 192.168.0.1=01:23:45:aa:dd:cc :
Mac source : aa:bb:cc:11:22:33 (PC)
Mac destination : 01:23:45:aa:dd:cc (routeur)
IP source : 192.168.042 (PC)
IP destination : 88.111.222.333
port source : tcp 57618 (random)
port destination : tcp 443 (https)
et le paquet est envoyé en unicast : PC → switch port 1/17 vlan 1 → swich port 1/48 vlan 1 → port lan du routeur,
qui le forwarde ensuite sur son interface WAN en le source-nattant (masquerade : source mac wan du routeur : 01:23:45:aa:dd:ce + ip publique du routeur : 212.7.183.145, ip destination inchangée, mac destination : le next-hop du routeur coté opérateur))
et ainsi de suite de routeur en routeur.
Donc pour te répondre, les routeurs (layer3) savent vers ou acheminer les paquets selon leur table de routage, et trouvent également la mac (layer2) de l’ip de leur next-hop (default-route via 217.7.183.144 dev eth0 metric1) via ARP si besoin, + règles autorisant le traffic (man iptables) + NAT.
Et les switchs, ils commutent les paquets des actifs brassés sur eux : ils ont juste besoin de savoir dans quel vlan et sur quel port est telle mac (sinon ils innondent tous les ports du même vlan), ils n’ont même pas besoin d’avoir une ip dans ce vlan pour en commuter (layer 2) les paquets. (sauf les switchs de niveau 3 qui sont du coup adressés en ip dans les vlans qu’ils desservent, c’est un autre sujet puisque le switch vient de devenir un routeur dans ce cas ;p)
Evidemment en tant que switch programmable, il devrait avoir lui meme une ip (fixe ou dhcp) + une route par défaut et un dns/ntp afin de réussir à se maintenir à l’heure et pouvoir être administré, mais comme c’est un mauvais qui l’a mis en place, il ne peut pas faire celà car il n’a pas de config. Cela ne l’empeche pas d’avoir un default-vlan (vlan1) et que tous ses ports soient untagged vlan1 (par défaut dans ce vlan en port access) → il peut donc correctement commuter tous les paquets du vlan 1 sur la simple connaissance des adresse mac dans sa mac-address-table.
C’est ce qui le distingue d’un HUB (concentrateur) qui lui n’a pas de mac-address-table → il innonde toujours tous les paquets sur tous les ports.
