Forum Linux.redhat Comment empêcher la création d'une route ?

Posté par  .
Étiquettes : aucune
0
24
mar.
2009
Bonjour,

Lorsque je configure une nouvelle interface réseau (via le fichier ifcfg-ethX) et que je l'active, j'obtiens automatiquement une nouvelle ligne dans la table de routage.
Cette ligne est calculée à partir de l'adresse de l'interface et du masque associé, et indique logiquement que le réseau correspondant est accessible via cette interface.
Je voudrais désactiver ce comportement, c'est à dire que je voudrais pouvoir configurer et activer une nouvelle interface sans que ma table de routage en soit modifier, ou à défaut en gardant le contrôle de ce qui est ajouté.

Au pire je rajouterai un "route del" dans rc.local mais c'est pas très joli.

Je ne trouve pas grand chose avec google, il est vrai que mon besoin doit être assez atypique. C'est pour une configuration un peu tordue (je l'admet) : je veux faire une passerelle entre deux réseaux physiques dont les membres sont tous dans le même réseau IP, d'où mon besoin de maîtriser le routage.

Je ne suis pas expert en réseau, peut-être y-a-t'il une autre manière de faire ça ?
  • # je comprend pas l'interet

    Posté par  . Évalué à 3.

    c'est quoi pour toi l'interet d'avoir une interface
    si c'est pour qu'elle ne serve pas à gerer le reseau que tu viens de creer ?

    parce qu'au final ta route c'est pour dire que pour acceder au
    reseau 192.168.1.0 netmask 255.255.255.0

    la machine va devoir passer par l'interface ethX

    c'est logique, c'est normal

    et je ne vois pas bien ce que tu vas faire d'une telle interface
    • [^] # Re: je comprend pas l'interet

      Posté par  . Évalué à 2.

      > une passerelle entre deux réseaux physiques dont les membres sont tous dans le même réseau IP

      Au pire, il disjoint la plage IP entre les deux sites, avec les netmasks qui vont bien de part et d'autre, et hop, ça fait deux réseaux séparés, entre lesquels on peut router du traffic (considérable comme un plus gros "tout" en étendant le netmask)...

      ... parce que bon : router entre des membres du même réseau IP, c'est contre nature : normalement, ça se switche les membres d'un même réseau IP (c'est même le principe du switch), quitte à faire du chaînage de switches si chaque "réseau" a déjà physiquement le sien...

      Mais bon : il faut choisir - généralement, on route entre des réseaux IP, et on switche au sein d'un résau IP. Même si les réseaux sont distants, et qu'un VPN est de la partie, on a toujours le choix entre routage et switchage... bref, qu'est-ce que ça vient faire là-dedans, un routeur, à part amener des emmerdes ?
      • [^] # Re: je comprend pas l'interet

        Posté par  . Évalué à 1.

        En fait ma passerelle doit aussi jouer le rôle de pare-feu, sinon effectivement je ne m'embêterais pas à séparer les réseaux physiques.

        La solution normale serait de faire deux réseaux logiques disjoints et au pire de la translation d'adresse si besoin pour faire illusion.

        Mais je ne veux pas toucher à la configuration IP du serveur que je cherche à isoler car il est un peu particulier. Je souhaite pouvoir le changer de réseau physique si nécessaire sans avoir à toucher à sa configuration IP, afin de le rendre rapidement disponible en cas de pépin sur mon pare-feu.
    • [^] # Re: je comprend pas l'interet

      Posté par  . Évalué à 1.

      Je m'attendais à ce genre de réponse, je vais donc détailler un peu mon idée (qui je le rappelle est tordue, j'assume).

      Ma passerelle a une interface eth0 (192.168.1.1/24) qui donne logiquement accès réseau 192.168.1.0/24

      J'ai sur ce réseau un serveur (192.168.1.10/24) que je souhaite isoler d'un point de vue physique en le connectant seul à l'interface eth1 de ma passerelle. Mais je souhaite aussi conserver son adressage IP.

      Je souhaite donner à eth1 l'adresse 192.168.1.2, mais le simple fait de configurer eth1 ainsi ajoute une nouvelle route vers le réseau 192.168.1.0/24 via cette interface, ce qui crée la confusion puisque j'avais déjà une route pour ce réseau via eth0.

      A la place de cette route créée automatiquement je souhaiterais créer une route statique vers le serveur 192.168.1.10.

      Autrement dit ma table de routage après création de eth1 est la suivante :
      Destination Passerelle Genmask Indic Metric Ref Use Iface
      192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
      192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

      alors que je voudrais avoir ceci :
      Destination Passerelle Genmask Indic Metric Ref Use Iface
      192.168.1.10 0.0.0.0 255.255.255.255 U 0 0 0 eth1
      192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

      Je sais obtenir ce résultat à coups de route add et route del, mais pas via les fichiers de configuration de Fedora pour que ce soit automatique et surtout un peu propre.

      En fait je cherche à faire proprement quelque chose de sale, c'est peut-être pour ça que je n'y arrive pas.
      • [^] # Re: je comprend pas l'interet

        Posté par  . Évalué à 3.

        Sous Debian, on fait ça via des hooks dans le fichier de conf réseau (/etc/network/interfaces) - genre en mettant la commande "route add blabla..." derrière un "up" (soit "up route add blabla..."), dans la section de la carte réseau.

        Par contre, ces fichiers ne sont généralement les mêmes d'une distro à l'autre, donc, à voir comment ça se gère sur ta distro.
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: je comprend pas l'interet

          Posté par  . Évalué à 2.

          Comme il dit plus haut, il veut apparemment pouvoir rebrancher le serveur sur un /24 tout classique (genre routeur basique de secours ?) en cas de partage en sucette de la passerelle.

          Mais la encore, si il s'y prend bien, jouer sur le netmask est faisable : serveur en 192.168.1.2/30, habituellement branché sur la patte 192.168.1.1/30 du routeur, le reste étant sur un /25, au plus, sur l'autre patte.

          En cas de pépin de la passerelle habituelle, le serveur en 192.168.1.2/30 est branché sur un routeur de secours où on n'a pas le contrôle des routes (genre de la box de fai bien pourrie comme il y en a), et qui est en 192.168.1.1/24 : aucun changement sur le serveur (si ce n'est changer de branchement, au bout du câble réseau), et tant qu'on n'implique pas de broadcast là-dedans, ni plus que de machines en dehors de 192.168.1.0/30 (donc autre que le routeur et le serveur... si on veut faire plus de place, on étend le netmask), il n'y aura aucun souci, et pour dépanner, ça ira largement.
      • [^] # Re: je comprend pas l'interet

        Posté par  . Évalué à 2.

        Je pense que ce que tu cherches à faire est un pont réseau.

        Il faut utiliser pour cela brctl
  • # La réponse est dans ton texte

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

    Cette ligne est calculée à partir de l'adresse de l'interface et du masque associé

    ifconfig eth0:1 192.168.10.11/32
  • # ip

    Posté par  . Évalué à 2.

    Il suffit d'utiliser au lieu de ifconfig ou du script ifcfg-ethX la commande ip
    ip link pour monter l'interface puis ip addr pour mettre une IP.
    Cela ne touche pas les routes.
  • # merci pour toutes les réponses

    Posté par  . Évalué à 1.

    Je n'ai pas eu le temps de revenir sur ce forum depuis mardi soir mais je vois que plusieurs pistes me sont proposées. Je vais prendre le temps de les explorer et si je trouve la solution je vous en ferai part.
    Juste pour éclairer ceux que ma demande intrigue, le serveur que je cherche à isoler est un NAS qui ne s'administre que par le réseau (web ou ssh). Sans possibilité d'y brancher un clavier et un écran, il est vital de conserver une accessibilité permanente au niveau IP car même pour changer son adresse il faut déjà y accéder.
    Bien sûr il y a toujours la solution d'avoir un PC portable sous la main et un cable croisé mais je souhaite que le rétablissement du service en cas de pépin sur le pare-feu soit rapide et si possible faisable par des personnes non averties.

Suivre le flux des commentaires

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