Différences

Ci-dessous, les différences entre deux révisions de la page.

--- 050-manips-ipv4:040-un-routeur [le 05/04/2025 à 16:40] – supprimée - modification externe (Date inconnue) 127.0.0.1
+++ 050-manips-ipv4:040-un-routeur [le 11/09/2025 à 13:04] (Version actuelle) – [Conclusion] prof
@@ Ligne 1: / Ligne 1: @@
+====== Ajout d'un routeur ======
+Attention, ça se complique...
+Nous voudrions maintenant que notre réseau expérimental ''192.168.61.0/24'' puisse avoir un accès à l'internet.
+Nous bricolons donc notre plateforme expérimentale de la façon suivante:
+{{ 050-manips-ipv4:demonet2.svg |Interconnexions}}
+  - Ajout d'une interface Ethernet dans le ''demoserver'', avec l'adresse 192.168.60.252. (Elle s'appellera logiquement ''enp1s0''). La configuration devient alors dans le fichier ''/etc/network/interfaces'':<html><pre class="code"># The loopback network interface
+auto lo
+iface lo inet loopback
+<span class="hly">allow-hotplug enp1s0
+iface enp1s0 inet static
+  address 192.168.60.252/24
+  gateway 192.168.60.254</span>
+allow-hotplug enp7s0
+iface enp7s0 inet static
+  address 192.168.61.1/24
+</pre></html>
+  - Branchement de cette interface dans le réseau 192.168.60.0/24 qui dispose d'un routeur vers l'internet à l'adresse 192.168.60.254. C'est la «box» qui dispose également d'un résolveur DNS. \\ Nous pouvons déjà vérifier que ''demoserver'' accède correctement à l'internet:<html><pre class="code"><b>ping -c1 www.debian.org</b>
+PING www.debian.org(klecker.debian.org (2001:67c:2564:a119::77)) 56 data bytes
+bytes from klecker.debian.org (2001:67c:2564:a119::77): icmp_seq=1 ttl=46 time=29.8 ms
+--- www.debian.org ping statistics ---
+packets transmitted, 1 received, 0% packet loss, time 0ms
+rtt min/avg/max/mdev = 29.789/29.789/29.789/0.000 ms
+</pre></html>Jusque là, tout va bien.
+  - Le kernel Linux sait parfaitement effectuer du routage entre interfaces réseau, encore faut-il activer cette fonction qui ne l'est pas par défaut pour des raisons de sécurité (administrateur requis):<code>sysctl -w net.ipv4.ip_forward=1</code>
+Théoriquement, si ''demoserver'' a compris sa fonction de routage, ''democlient1'' devrait pouvoir accéder à 192.168.60.254. Essayons avec un ''ping'' :
+  ping -c1 192.168.60.254
+La réponse n'est pas sympathique:
+  ping: connect: Le réseau n'est pas accessible
+====== Tracer les routes ======
+Vérifions d'abord les routes que connaît ''demoserver'':
+<html><pre class="code">
+<b>ip route list</b>
+default via 192.168.60.254 dev enp1s0 onlink
+.168.60.0/24 dev enp1s0 proto kernel scope link src 192.168.60.252
+.168.61.0/24 dev enp7s0 proto kernel scope link src 192.168.61.1
+</pre></html>
+  - Il sait comment aller sur ''192.168.60.0/24'';
+  - il sait comment aller sur ''192.168.61.0/24'';
+  - il sait comment aller ailleurs en passant par ''192.168.60.254'' via l'interface ''enp1s0''.
+Est-ce que ''democlient1'' sait comment sortir de son réseau ?
+Sur ''democlient1'':
+<html><pre class="code">
+<b>ip roule list</b>
+.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101
+</pre></html>
+La seule route qu'il connaît est celle qui permet d'accéder aux nœuds du réseau ''192.168.61.0/24''. Aucune chance d'accéder à un autre réseau. Il faut donc lui expliquer comment sortir. Indiquons-lui une route par défaut (administrateur requis):
+  ip route add default via 192.168.61.1
+Et vérifions:
+<html><pre class="code">
+<b>ip route list</b>
+<span class="bhly">default via 192.168.61.1 dev enp1s0 </span>
+.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101
+</pre></html>
+Voilà qui est mieux. Essayons encore...
+<html><pre class="code">
+<b>ping -c1 192.168.60.254</b>
+PING 192.168.60.254 (192.168.60.254) 56(84) bytes of data.
+--- 192.168.60.254 ping statistics ---
+<span class="hly">1 packets transmitted, 0 received, 100% packet loss, time 0ms</span>
+</pre></html>
+Dans les cas désespérés, il faut sortir l'artillerie lourde. Voyons avec wireshark  ce qu'il se passe sur les deux interfaces de ''demoserver''. Relançons le ping et voyons:
+<html><pre class="code">
+No. Source          Destination     Protocol  Info
+  192.168.61.100   192.168.60.254  ICMP      <span class="hly">Echo request <b>(no response found!)</b></span>
+</pre></html>
+Nous devrions voir cet ''Echo request'' 2 fois s'il traversait le routeur, Sur l'interface dans ''192.168.61.0'' puis sur l'interface dans ''192.168.60.0'' !
+** Le routeur ne route pas...**
+Il fallait savoir que si le kernel Linux sait faire le routage, cette fonction est désactivée par défaut pour des raisons de sécurité. La commande ''sysctl'' //permet de configurer les paramètres du noyau à chaud// (cf. ''man sysctl''). En l'occurence:
+Vérifions:
+<html><pre class="code">
+<b>sysctl net.ipv4.ip_forward</b>
+<span class="bhlr">net.ipv4.ip_forward = 0</span>
+</pre></html>
+Il faut mettre ce paramètre à ''1'':
+<html><pre class="code">
+<b>sysctl -w net.ipv4.ip_forward=1</b>
+<span class="bhlg">net.ipv4.ip_forward = 1</span>
+</pre></html>
+Essayons encore en laissant Wireshark  espionner le tout:
+<html><pre class="code">
+No. Source          Destination           Protocol Info
+  192.168.61.100  192.168.60.254        ICMP     Echo request (no response found!)
+  192.168.61.100  192.168.60.254        ICMP     Echo request (no response found!)
+</pre></html>
+Il y a du mieux. Le paquet traverse bien le routeur, mais aucune réponse n'arrive... Supposons alors que le paquet est bien arrivé sur ''192.168.60.254'' ce qui est bien légitime puisque le paquet est arrivé sur ''192.168.60.0''. La Box a donc certainement répondu à ''192.168.61.100'' Sauf qu'elle ne connaît pas la route vers ce réseau. Elle connaît ''192.168.60.0'' sinon elle route vers l'internet ! Il faudrait ajouter la route vers ''192.168.61.0/24'' à la Box, malheureusement la Box n'est pas configurable en ce qui concerne ses routes et il n'y a aucune raison qu'elle soit au courant de nos bidouillages internes. C'est du matériel «grand public»!
+Au final, nous avons bien une route qui permet d'aller de 192.168.61.0/24 vers 192.168.60.254, mais il n'y a pas de route pour le retour. Alors, comment faire ?
+====== Les solutions de retour ======
+Il y a deux solutions plus ou moins simples, plus ou moins élégantes.
+===== Virer le routeur de la Box =====
+{{050-manips-ipv4:modem-routeurs.svg?300 |Cliquez pour agrandir}}C'est possible au moins avec les Freebox . Il faut alors la configurer en mode «bridge». Dans ce cas, elle va fonctionner comme un simple modem, et placer derrière un routeur «maison» comme nous faisions au bon vieux temps, lorsque les fournisseurs d'accès ne proposaient qu'un simple modem. Nous aurions alors un montage de cette forme:
+Le routeur R1 assure les mêmes fonctions que celui qui est intégré dans la Box, à ceci près que nous pouvons lui ajouter une route vers 192.168.61.0/24.
+Mais nous ne détaillerons pas d'avantage cette solution. Consultez les archives du site pour voir ça de près.
+===== Faire du «masquerade» =====
+C'est-à-dire sur ''demoserver'' masquer l'adresse source dans tous les paquets sortant du réseau 192.168.61.0/24  par celle de l'interface ayant l'adresse 192.168.60.252, c'est-à-dire faire finalement la même chose que la Box entre le réseau ''192.168.60.0/24'' et l'internet. Ainsi, les cibles verront 192.168.60.252 comme adresse source et y répondront en toute bonne foi. À charge pour ''demoserver'' de replacer la bonne adresse de destination des les réponses qu'il reçoit, puis de les router convenablement. Le processus est largement décrit dans le chapitre dédié.
+C'est cette solution que nous allons adopter. Prenons pour l'instant la solution comme une recette de cuisine. Sur ''demoserver'', l'interface ayant pour adresse 192.168.60.252 s'appelle ''enp1s0''. Après avoir installé le paquet ''iptables'', voici la commande magique (administrateur requis):
+  iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
+===== Et admirer... =====
+  ping -c1 192.168.60.254
+Donne à présent:
+  PING 192.168.60.254 (192.168.60.254) 56(84) bytes of data.
+bytes from 192.168.60.254: icmp_seq=1 ttl=63 time=1.23 ms
+Nous avons la réponse au ping. Un coup de sniffeur pour vérifier tout ça nous donne en résumé classé de façon chronologique:
+<html><pre class="code">
+No. Time           Source          Destination       Info
+  0.000000000    <span class="hly">192.168.61.101  192.168.60.254    Echo (ping) request</span>   (reply in 2)
+  0.000427949    <span class="hlb">192.168.60.252  192.168.60.254    Echo (ping) request</span>   (reply in 4)
+  0.000760552    <span class="hlb">192.168.60.254  192.168.60.252    Echo (ping) reply</span>     (request in 3)
+  0.001019194    <span class="hly">192.168.60.254  192.168.61.101    Echo (ping) reply</span>     (request in 1)
+</pre></html>
+Les trames jaunes sont capturées sur ''sw1'' et les bleues le sont sur ''sw2''.
+Nous voyons sur la trame n°1 (ping request):
+  * l'adresse source est celle de ''democmlient1''
+  * l'adresse cible est celle du routeur dans 192.168.60.0/24
+Dans la trame n°3 nous retrouvons le ping request mais:
+  * l'adresse source est désormais celle de ''demoserver'' sur ''enp1s0''. C'est le travail du «masquerade».
+  * l'adresse cible reste bien sûr la même.
+Dans la trame n°4, nous avons le «ping reply» de 192.168.60.254 qui est envoyée à 192.168.60.252 (''demoserver'')
+Dans la trame n°2, nous retrouvons le «ping reply», mais cette fois-ci adressée à 192.168.61.101 c'est-à-dire ''democlient1'', re-travail du «masquerade»
+Dans les faits, la Box fait également du masquage d'adresse vers l'internet pour IPv4, ce qui était prévisible puisque nous utilisons le réseau 192.168.60.0/24 qui n'est pas routable directement sur l'internet (adresses réservées à l'usage privé).
+====== Conclusion ======
+Est-ce que dans ce cas, 192.168.61.0/24 serait alors capable lui aussi de communiquer avec l'internet ?
+<html><pre class="code">
+ ping -c1 51.68.121.59
+PING 51.68.121.59 (51.68.121.59) 56(84) bytes of data.
+<span class="bhly">64 bytes from 51.68.121.59: icmp_seq=1 ttl=52 time=19.8 ms</span>
+</pre></html>
+Yesssssssssssssssss!
+Dans ce genre de situation, il faut toujours vérifier que:
+  - Le routeur intermédiaire a bien une interface dans chaque réseau,
+  - qu'il est configuré pour effectuer le routage,
+  - que les routes de retour existent bien, d'une manière ou d'une autre,
+  - que tous les éléments des réseaux sachent à quel routeur s'adresser pour sortir de leur réseau.
+  - lorsque quelque chose ne fonctionne pas comme prévu, les sondes d'observation du réseau, Wireshark par exemple, peuvent bien aider à démasquer le bug.
+Notre réseau virtuel 192.168.61.0/24 est donc capable de communiquer avec 192.168.60.0/24 qui lui-même est capable de communiquer avec l'internet.
+Ceci dit, tous les aménagements de configuration que nous avons bricolé l'ont été de manière temporaire:
+  - la route par défaut pour les clients du réseau 192.168.61.0/24 pourra être dynamiquement ajoutée à la configuration IP par l'intermédiaire du serveur DHCP.
+  - l'activation du routage sur ''demoserver''.
+  - le masquage d'adresse mis en place sur ''demoserver'' devra être reconstitué à chaque démarrage de ce dernier. Un paquet Debian ''iptables-persistent'' prévu pour, devra être installé sur ''demoserver''
+Pour activer le routage de façon permanente il faut créer dans le répertoire ''/etc/sysctl.d'' un fichier nommé par exemple ''activationRoutage.conf'' qui contiendra cette unique ligne:
+  net.ipv4.ip_forward=1
+Au prochain démarrage, ''systemd'' lancera un service nommé ''systemd-sysctl'' qui s'occupera d'ajuster les variables système en fonction de ce nouveau fichier. Les plus curieux pourront consulter le manuel de la commande ''sysctl''.
+Pour le serveur DHCP, revenons sur son fichier de configuration
+<html><pre class="code">
+{
+    "Dhcp4": {
+        "interfaces-config": {
+            "interfaces": [
+                "enp7s0"
+            ]
+        },
+        "valid-lifetime": 360,
+        "renew-timer": 180,
+        "rebind-timer": 350,
+        "authoritative": true,
+        "lease-database": {
+            "type": "memfile",
+            "persist": true,
+            "name": "/var/lib/kea/kea-leases4.csv",
+            "lfc-interval": 3600
+        },
+        "subnet4": [
+            {
+                "subnet": "192.168.61.0/24",
+                "pools": [
+                    {
+                        "pool": "192.168.61.100 - 192.168.61.120"
+                    }
+                ],
+<span class="hly">                "option-data": [
+                   {
+                        "name": "routers",
+                        "data": "192.168.61.1"
+                   }
+               ],</span>
+            }
+        ]
+    }
+}
+</pre></html>
+Il suffit d'ajouter le paragraphe surligné dans le fichier ''/etc/kea/kea-dhcp4.conf'' et de relancer le serveur.
+Après redémarrage de ''demoserver'', nous pouvons vérifier:
+<html><pre class="code">
+<b>ip route list</b>
+<span class="hly">default via 192.168.60.254 dev enp1s0 onlink </span>
+.168.60.0/24 dev enp1s0 proto kernel scope link src 192.168.60.252
+.168.61.0/24 dev enp7s0 proto kernel scope link src 192.168.61.1
+</pre></html>
+Le serveur connaît la route par défaut, celle qui mène à l'internet.
+<html><pre class="code">
+<b>sysctl net.ipv4.ip_forward</b>
+<span class="hly">net.ipv4.ip_forward = 1</span>
+</pre></html>
+Le kernel a retenu qu'il devait effectuer le routage.
+<html><pre class="code">
+<b>iptables -t nat -L POSTROUTING -v</b>
+Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
+ pkts bytes target      prot opt in     out     source           destination
+  1568 <span class="hly">MASQUERADE  all  --  any    enp1s0  anywhere         anywhere</span>
+</pre></html>
+Le masquage d'adresse est bien actif pour tout ce qui sort par ''enp1s0''.
+Du côté du ''democlient1'' il faut juste vérifier qu'il connaît après redémarrage la route par défaut:
+<html><pre class="code">
+<b>ip route ls</b>
+<span class="hly">default via 192.168.61.1 dev enp1s0</span>
+.168.61.0/24 dev enp1s0 proto kernel scope link src 192.168.61.101
+</pre></html>
+Et voilà le travail !
+Nous verrons plus loin que tout ceci devient obsolète si l'on utilise exclusivement IPv6, mais ce n'est pas encore possible.