====== Jouons un peu... ======
{{ :demoroutage:simple_reseau.gif?310|}} C'est lorsque l'on croit avoir tout bien compris que l'on tombe parfois dans le panneau...
Voyons un cas de figure un peu plus compliqué, mais intéressant.
Dans ce cas, déjà vu en page précédente, gw2 représente un routeur avec masquage d'adresse, de manière à permettre aux hôtes du réseau 192.168.0.0 d'accéder à l'Internet. Les hôtes du réseau 192.168.0.0 connaissent uniquement :
* la route de leur propre réseau ;
* une route par défaut : 192.168.0.252.
Hormis le détail de masquerade, gw2 agit comme un routeur tout à fait ordinaire. Sa table de routage est simple :
ca-marseille-14-119:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
80.8.136.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 80.8.136.1 0.0.0.0 UG 0 0 0 ppp0
Mais compliquons un petit peu l'architecture...
{{ :demoroutage:dbl_reseau.gif?510|}}
Nous rajoutons un second réseau , 192.168.1.0, interconnecté au réseau 192.168.0.0 par une autre passerelle, que nous appellerons cyclope. Ce routeur va fonctionner sans masquage d'adresse (ce serait trop facile sinon).
===== Objectif de la manœuvre. =====
Nous aimerions bien que les choses se passent de la manière suivante :
* Le réseau jaune doit accéder à l'Internet,
* le réseau jaune doit accéder au réseau bleu,
* le réseau bleu doit accéder au réseau jaune, bien sûr.
Facile, me direz-vous ? Peut-être pas tant que ça...
==== De 192.168.1.0 vers INET ====
Il suffit d'indiquer aux hôtes du réseau jaune 192.168.1.1 comme passerelle par défaut. cyclope a une table de routage toujours très simple :
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Bon. un paquet part de 192.168.1.2 à destination, par exemple, de 213.186.35.33.
* L'émetteur, sachant que le destinataire n'est pas dans le réseau jaune, va envoyer le paquet sur cyclope,
* cyclope, voyant que ce n'est pas pour lui, va chercher une route pour joindre le destinataire. Malheureusement, il n'en connaît pas. Ca va se terminer par un "no route to host" ou un truc de ce genre.
Il nous faut donc modifier la configuration de cyclope, pour lui indiquer une route par défaut, qui pointera sur gw2 :
~# route add default gw 192.168.0.252 eth0
~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.252 0.0.0.0 UG 0 0 0 eth0
La route par défaut de cyclope est placée, il sait maintenant où envoyer les paquets qui ne vont pas dans le réseau bleu (ni dans le réseau jaune, d'ailleurs).
Et rejouons le scénario
Re-bon. un paquet part de 192.168.1.2 à destination, par exemple, de 213.186.35.33.
* L'émetteur, sachant que le destinataire n'est pas dans le réseau jaune, va envoyer le paquet sur cyclope,
* cyclope, voyant que ce n'est pas pour lui, va chercher une route pour joindre le destinataire. N'en trouvant pas une explicite, il va envoyer le paquet à gw2,
* celui-ci, ne connaissant pas non plus de route explicite pour ce paquet, va l'envoyer à sa passerelle par défaut, à savoir 80.8.136.1 dans l'exemple.
C'est parti. Après, ce n'est plus de notre compétence, mais de celle de notre fournisseur d'accès. Le paquet va arriver à destination.
=== Mais pour le retour ? ===
Pour le retour, ça va coincer, vous pensez bien... Lorsque la réponse va arriver sur gw2, après démasquage de l'adresse du destinataire, il lui restera à trouver une route qui mène à 192.168.1.0 et elle n'en connaît pas, donc, retour sur la passerelle par défaut. Ca ne va pas trop bien marcher. Il faut bricoler quelque chose sur gw2 :
~# route add -net 192.168.1.0 gw 192.168.0.16 netmask 255.255.255.0 eth1
~#route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
80.8.136.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.1.0 192.168.0.16 255.255.255.0 UG 0 0 0 eth1
0.0.0.0 80.8.136.1 0.0.0.0 UG 0 0 0 ppp0
{{ :demoroutage:route_inet.gif?510|}}
En rajoutant cette route, ça ira mieux. gw2 enverra le paquet à destination de 192.168.1.2 sur cyclope qui, lui, saura joindre le destinataire.
Voilà une bonne chose de faite. Notre réseau jaune est maintenant en mesure d'offrir à ses hôtes l'accès à l'Internet.
==== De 192.168.1.0 vers 192.168.0.0 (et vice versa). ====
Ce serait trop beau que ça marche du premier coup...
Sur le réseau bleu, il y a deux passerelles. Si on ne le dit pas à tous les hôtes du réseau bleu, elles ne le découvriront pas toutes seules. Elles ne connaissent, faut-il le rappeler, qu'une route par défaut, qui pointe sur gw2, à savoir 192.168.0.252.
Essayons quand même, depuis 192.168.0.15, de faire un ping sur 192.168.1.2. Ca passera le temps.
Envoi d'une requête 'ping' sur 192.168.1.1 avec 32 octets de données :
Réponse de 192.168.1.1 : octets=32 temps=1 ms TTL=255
Réponse de 192.168.1.1 : octets=32 temps<1ms TTL=255
Réponse de 192.168.1.1 : octets=32 temps<1ms TTL=255
Réponse de 192.168.1.1 : octets=32 temps<1ms TTL=255
Statistiques Ping pour 192.168.1.1:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 1ms, Moyenne = 0ms
Mince alors, ça marche !!! Comment ce peut-ce ?
En faisant du ping pong.
=== ping ===
* 192.168.0.15 ne connaît pas de route vers 192.168.1.2. Il envoie la balle à sa passerelle par défaut 192.168.0.252 (gw2),
* gw2, lui, connaît une route vers le réseau 192.168.1.0, c'est cyclope (192.168.0.16). Il lui passe la balle,
* cyclope envoie à 192.168.1.2.
=== pong ===
{{ :demoroutage:route_intra.gif?510|}}
* 192.168.1.2 répond. Ne sachant pas joindre 192.168.0.15, il envoie à cyclope,
* cyclope sait joindre **__directement__** 192.168.0.15, il connaît la route vers ce réseau.
C'est une partie triangulaire, en quelque sorte.
Voici graphiquement ce que ça donne, mais dans l'autre sens, ping en vert et pong en violet :
Bien entendu, nous pouvions aussi indiquer à 192.168.0.15 la route directe pour aller dans le réseau 192.168.1.0, mais ce n'est pas forcément facile à faire de façon automatique (DHCP par exemple).
=== Traceroutes ===
Pour finir de convaincre l'aimable assistance, voici des traceroutes dans les deux sens.
== de 192.168.1.2 vers 192.168.0.15 : ==
~# traceroute -n 192.168.0.15
traceroute to 192.168.0.15 (192.168.0.15), 30 hops max, 38 byte packets
1 192.168.1.1 1.150 ms 1.601 ms 1.602 ms
2 192.168.0.15 1.618 ms 1.863 ms 1.932 ms
Comme prévu, 192.168.1.2 va joindre 192.168.0.15 en traversant le seul routeur 192.168.1.1 (cyclope, côté 192.168.1.0).
== de 192.168.0.15 vers 192.168.1.2 : ==
~# traceroute -n 192.168.1.2
traceroute to 192.168.1.2 (192.168.1.2), 30 hops max, 38 byte packets
1 192.168.0.252 1.209 ms 0.855 ms 0.839 ms
2 192.168.0.16 1.531 ms 0.728 ms 2.235 ms
3 192.168.1.2 1.702 ms 1.195 ms 1.184 ms
En revanche, pour atteindre 192.168.1.2, 192.168.0.15 passera d'abord par 192.168.0.252 (gw2) puis par 192.168.0.16 (cyclope, côté 192.168.0.0)
===== Conclusions. =====
* Les routes aller et retour ne sont pas forcément les mêmes,
* des paquets peuvent trouver leur route dans un sens, mais pas dans l'autre,
* sur des structures plus compliquées, ça peut marcher, mais pas forcément de manière efficace. Avec un peu d'imagination, vous trouverez des cas où un paquet peut beaucoup voyager dans votre inter réseau, pour arriver finalement sur la machine juste à côté. Attention donc, lorsque ça marche du premier coup alors même que ce n'était pas du tout évident, avant de s'émerveiller, il vaut mieux essayer de comprendre pourquoi.