Alors non, pas du tout. La destination de la route spécifiée n'a pas besoin de correspondre à la taille du subnet dans lequel la destination se trouve.
La table de routage dit seulement : pour joindre X, passe par Y. Ici, X est en /32 mais ce n'est pas la taille du réseau dans lequel se trouve la destination, c'est juste la destination de la route. Et les deux peuvent être différents :).
Spécifier un /32, c'est utile par exemple c'est quand tu dois joindre une IP via un tunnel, mais qu'il y a une superposition entre le réseau local et le réseau distant.
Un exemple pratique pour illustrer (et réel, ça m'est arrivé !) : mon patron est à l'hôtel à l'étranger et doit se connecter au VPN de l'entreprise.
Le réseau Wifi de l'hôtel est en 172.20.0.0/24 (172.20.0.0 -> 172.20.0.254).
Le LAN du boulot est 172.20.0.0/21 (172.20.0.0 -> 172.20.7.0).
Le DNS du boulot est 172.20.0.1.
la machine que le patron doit joindre est 172.20.3.7.
Le boss se connecte au VPN, et la gateway du VPN configure des routes, dont 172.20.0.0/21, sur le laptop du patron, et envoie les paramètres DNS, dont nameserver=172.20.0.1.
Il y a donc comme routes sur le laptop :
default via 172.20.0.254 dev wlan0 # internet
172.20.0.0/24 via 172.20.0.254 dev wlan0 # LAN wifi
172.20.0.0/21 via 192.168.10.7 dev ppp0 # LAN entreprise
Il existe donc une route pour 172.20.0.0/24, qui part sur Internet, et 172.20.0.0/21 qui part dans le VPN. Et donc le trafic pour le DNS (172.20.0.1) part sur Internet, car la route en /24 est plus précise. Bigre. J'ai donc ajouté une route 172.20.0.1/32 pour que le client envoie le trafic à destination du DNS dans le tunnel.
Par contre, l'accès à 172.20.3.7 est ok depuis le départ car 172.20.0.0/24 n'englobe pas cette IP, pas besoin de mettre une route de plus.
Au final on a :
default via 172.20.0.254 dev wlan0 # internet
172.20.0.0/24 via 172.20.0.254 dev wlan0 # LAN wifi
172.20.0.0/21 via 192.168.10.7 dev ppp0 # LAN entreprise
172.20.0.1/32 via 192.168.10.7 dev ppp0 # route pour le DNS entreprise
Je sais pas si c'est clair ?
(avec IPv6, on aurait plus difficilement eu un conflit dans les plages d'IP)
[^] # Re: Question intéressante
Posté par cg . En réponse au message Relation entre classes et routage (IPv4). Évalué à 8.
Alors non, pas du tout. La destination de la route spécifiée n'a pas besoin de correspondre à la taille du subnet dans lequel la destination se trouve.
La table de routage dit seulement : pour joindre X, passe par Y. Ici, X est en /32 mais ce n'est pas la taille du réseau dans lequel se trouve la destination, c'est juste la destination de la route. Et les deux peuvent être différents :).
Spécifier un /32, c'est utile par exemple c'est quand tu dois joindre une IP via un tunnel, mais qu'il y a une superposition entre le réseau local et le réseau distant.
Un exemple pratique pour illustrer (et réel, ça m'est arrivé !) : mon patron est à l'hôtel à l'étranger et doit se connecter au VPN de l'entreprise.
Le boss se connecte au VPN, et la gateway du VPN configure des routes, dont 172.20.0.0/21, sur le laptop du patron, et envoie les paramètres DNS, dont nameserver=172.20.0.1.
Il y a donc comme routes sur le laptop :
Il existe donc une route pour 172.20.0.0/24, qui part sur Internet, et 172.20.0.0/21 qui part dans le VPN. Et donc le trafic pour le DNS (172.20.0.1) part sur Internet, car la route en /24 est plus précise. Bigre. J'ai donc ajouté une route 172.20.0.1/32 pour que le client envoie le trafic à destination du DNS dans le tunnel.
Par contre, l'accès à 172.20.3.7 est ok depuis le départ car 172.20.0.0/24 n'englobe pas cette IP, pas besoin de mettre une route de plus.
Au final on a :
Je sais pas si c'est clair ?
(avec IPv6, on aurait plus difficilement eu un conflit dans les plages d'IP)