Forum général.général Relation entre classes et routage (IPv4)

Posté par  . Licence CC By‑SA.
Étiquettes :
2
30
avr.
2022

Bonjour à tous.

Je crois me rappeler qu'il existe une relation entre les classes réseau et le routage, dans le sens où, ayant une machine (virtuelle) avec plus d'une carte réseau et une passerelle par défaut pour chacune d'elles, la route privilégiée dépendra de la classe du réseau (à métrique identique). Est-ce exact?

J'ai en effet une machine virtuelle de test avec deux cartes réseau. L'une d'elle est en classe A, privée (10.10.x.y) et l'autre en classe C, privée aussi (192.168.x.y). Il n'y a aucune route statique et les deux reçoivent leurs paramètres par DHCP, y compris la passerelle par défaut — dans les faits, je veux montrer les effets d'une transition entre deux réseaux en désactivant l'un d'eux et visualiser le trafic passer par l'autre.

Je peux voir que les routes sont listées par ordre croissant de classe, ce qui suggère que la classe définit une "certaine" priorité dans le choix de la passerelle par la pile réseau mais sans que j'aie de preuve pour étayer cette affirmation. Quelqu'un aurait-il une piste?

Merci d'avance.

  • # test

    Posté par  . Évalué à 3.

    facile, ca se teste

    depuis ton linux tu fais un traceroute destination_externe
    tu verras vite si tu passes par defaut, par l'une ou l'autre des passerelles

    et quand les 2 sont actives en meme temps, laquelle est prise en priorité

    Perso j'aurais plutot pensé que c'était la dernière activée qui prend le pas sur l'autre

    • [^] # Re: test

      Posté par  . Évalué à 2.

      facile, ca se teste

      Bien sûr, j'ai testé et j'ai obtenu les résultats attendus.

      Ce que j'aimerais c'est un document de référence, histoire de montrer que je ne raconte pas de bêtises…

  • # Classes en 2022 ?

    Posté par  (site web personnel) . Évalué à 6. Dernière modification le 30 avril 2022 à 16:35.

    CIDR date de 1993. :o)

    Debian Consultant @ DEBAMAX

    • [^] # Re: Classes en 2022 ?

      Posté par  . Évalué à 2. Dernière modification le 30 avril 2022 à 19:26.

      Merci pour la référence mais je ne trouve pas dans ces définitions l'indication qui décrit la priorité de sélection dans le cas de multiples routes (si je peux l'exprimer ainsi). Visiblement, la route de classe A prend la priorité sur celle d'une classe B, puis sur C. Un indice?

  • # Question intéressante

    Posté par  . Évalué à 5. Dernière modification le 30 avril 2022 à 16:59.

    J'ai testé avec cette table de routage :

    # ip route show
    default via 192.168.1.254 dev wlp2s0 metric 100
    default via 192.168.1.254 dev enp0s20u2u4 proto dhcp metric 100
    

    et avec un ping de ma passerelle (ou d'une adresse externe, peut importe) ça change d'interface de temps en temps (vu avec tcpdump), mais avec une préférence pour la carte wifi (pourquoi ? je l'ignore). Ici les deux réseaux sont les mêmes, ta situation n'est pas forcément similaire.

    Par contre, bien sûr dès qu'une metrique est plus basse que l'autre, tout passe par la route qui est le coût le plus bas.

    Et sinon, comme le dit Cyril, la notion de classes, c'est un peu… désuet ;). On parle plutôt de sous-réseau ou de plages d'adresses de nos jours.


    Note pour ceux qui ne connaissent pas trop le monde merveilleux du routage :

    Le routage se fait selon les règles de routage, la route la plus précise va prendre le pas sur les autres.

    Par exemple si tu as ça dans ta table de routage :

    10.1.1.1/32 via 192.1.1.1
    10.1.1.0/24 via 192.2.2.2
    10.1.0.0/16 via 192.3.3.3
    default     via 192.4.4.4
    

    le trafic vers 10.1.1.1 passera par la passerelle 192.1.1.1 .

    … et la réponse n'arrivera pas forcément par la même passerelle :D.

    • [^] # Re: Question intéressante

      Posté par  (site web personnel) . Évalué à 2.

      Dans le cas de 10.1.1.1/32 il faut que cette interface soit reliée à une autre sur le même sous-réseau pour être contactée. Ce sous-réseau contenant une unique adresse, comment cela serait possible?

      Je découvre le /32, mais je ne vois pas encore le cas d'usage…

      Un LUG en Lorraine : https://enunclic-cappel.fr

      • [^] # Re: Question intéressante

        Posté par  . É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 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  . Évalué à 3.

      Je me demande si dans mon cas, ça ne change pas d'interface au gré de la fraîcheur de la table ARP, vu que j'ai ça dedans :

      ~$ arp -n
      Address                  HWtype  HWaddress           Flags Mask            Iface
      192.168.1.254            ether   34:27:92:4f:01:db   C                     wlp2s0
      192.168.1.254            ether   34:27:92:4f:01:db   C                     enp0s20u2u4
      

      Ce n'est pas très proche du cas sur lequel tu t'interroges au final.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.