Une passerelle par défaut par interface

Tags: #<Tag:0x00007f2c9c65b0b0>

Bonjour,

J’utilise des machines avec deux interfaces réseau pour une question de ségrégation des flux, j’utilise donc une passerelle par interface.

Voici ma configuration sur Debian 11 :

/etc/network/interfaces:

allow-hotplug ens192
iface ens192 inet static
        address 192.168.61.31/24
        gateway 192.168.61.254
        dns-nameservers 192.168.11.27
        

allow-hotplug ens224
iface ens224 inet static
        address 192.168.60.31/24
        dns-nameservers 192.6811.27
        post-up ip route add 192.168.60.0/24 dev ens224 src 192.168.60.31 table prod
        post-up ip route add default via 192.168.60.254 dev ens224 table prod
        post-up ip rule add from 192.168.60.31/32 table prod
        post-up ip rule add to 192.168.60.31/32 table prod

Dans le fichier /etc/iproute2/rt_tables

    # reserved values
    #
    255     local
    254     main
    253     default
    0       unspec
    #
    # local
    #
    #1      inr.ruhep
    200     prod

Avec les commandes ip routes je retrouves bien mes configurations

ip route

 default via 192.168.61.254 dev ens192 onlink 
192.168.60.0/24 dev ens224 proto kernel scope link src 192.168.60.31 
192.168.61.0/24 dev ens192 proto kernel scope link src 192.168.61.31 

ip route show table prod

default via 192.168.60.254 dev ens224 
192.168.60.0/24 dev ens224 scope link src 192.168.60.31 

En théorie tout est sensé fonctionner mais dans la pratique j’ai l’impression que la directive « gateway » écrase la gestion des metrics dans le fichier rt_tables.

Je ne comprends pas trop si j’ai commis une erreur de configuration ou si ce que j’essaie de faire n’es pas possible…

Et bien sûr, ça ne marche pas.

Doublon.

Inutile et ignoré puisque c’est une adresse locale à la machine.

Il manque la commande ip rule pour vérifier les règles de routage.

En théorie, comment le routage est-il censé fonctionner ? Concrètement, qu’est-ce qui doit être routé comment ?
Quels sont les flux mis en oeuvre ?

La règle de routage basée sur l’adresse IP source ne s’applique que si l’adresse source est déjà définie avant la décision de routage. Or l’adresse source d’une connexion sortante n’est généralement définie qu’au cours de la décision de routage, en fonction de l’interface sélectionnée et non l’inverse.

L’architecture mise en place a pour but de séparer les flux de production de ceux d’administration, via deux interfaces avec des adresses et des règles différentes.

J’utilise ce système depuis quelques temps j’ai l’impression qu’il fonctionne mieux quand les requêtes sont entrantes sur l’interface224.

J’avais déjà du recourir a l’utilisation de règles de routage statiques avec ip rule, ceci règle en effet les problèmes de choix dont font face les paquets avec une ip 0.0.0.0 en sortie.

Merci d’avoir éclairé ma lanterne. Je vais tenter de répondre à cette problématique avec quelques règles statiques.

Cette phrase n’apporte aucune information concrète. Si les réseaux d’admin et de prod était réellement séparés, il n’y aurait pas besoin de règles de routage avancé, il suffirait de définir les routes statiques pour les différentes destinations.

C’est ce que je fais je défini une ou plusieurs routes suivant mes besoins.

post-up add to 192.168.XX.0/24 table prod

Qu’entendez vous par règle de routage avancées ?

Le routage avancé, c’est quand on utilise ip rule et des tables de routage supplémentaires.

Comment indiquer les interfaces de sorties et les passerelles aux interfaces sans ajout de règle de routage sur la machine ?

Je sens bien que je ne manipule pas correctement la ségrégation des flux sur le parc, j’ai déjà essayé plusieurs configurations je ne comprends pas comment cela fonctionnait.

La séparation des réseau est plus logique que physique une grosse partie est virtualisée et/ou gerer par un firewall classique.

Il m’est impossible d’expliquer comment la configuration présentée « fonctionne » dans certains cas de figure que j’utilise.

Je ne vois pas comment résoudre mon problème sans utiliser de paramètres ip rule et une table par interface.

Peu importe. Si les réseaux utilisent des plages d’adresses séparées, alors l’adresse de destination devrait être le seul critère qui compte pour le routage, et des routes dans la table principale devraient suffire. Le routage avancé n’est utile que si une même destination peut être joignable via plusieurs chemins selon d’autres critères (à définir).

Re - Bonjour !

ça me semble claire mais en pratique qu’entendez vous par table de principale ?

La table de routage principale « main » est celle qui est manipulée par les les commandes « ip route » si on ne spécifie pas explicitement de table, « route » ou « netstat -r » et pour laquelle une règle de routage existe par défaut :

$ ip rule
0:     from all lookup local 
32766: from all lookup main 
32767: from all lookup default
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug ens192
iface ens192 inet static
        address 192.168.61.31/24
        up ip -4 rule add prio 29000 table main || true
        up ip -4 rule del prio 32766 table main || true
        up ip -4 route add default via 192.168.61.254 dev $IFACE onlink table lan1
        up ip -4 rule add prio 30000 from 192.168.61.31 table lan1 || true
        up ip -4 rule add prio 31000 table lan1 || true

allow-hotplug ens224
iface ens224 inet static
        address 192.168.60.31/24
        up ip -4 rule add prio 29000 table main || true
        up ip -4 rule del prio 32766 table main || true
        up ip -4 route add default via 192.168.60.254 dev $IFACE onlink table lan2
        up ip -4 rule add prio 30000 from 192.168.60.31 table lan2 || true
        up ip -4 rule add prio 31000 table lan2 || true

Une configuration dans ce genre ?

En ajoutant évidemment les tables de nom « lan1 » et « lan2 » dans le fichier rt_tables .


AnonymousCoward

Je vais essayer, sur différents scénarios.

Cela dit la configuration via table main en spécifiant les réseaux destinations me parait plus saine.

Pourquoi dev $IFACE plutot que le nom de l’interface sur la règle ?