La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: Leon le 13 mai 2013 à 19:18:04
-
Bonjour à tous.
Je continue avec mes questions bizarres. Est-il possible de définir plusieurs adresses IP pour une seule et unique interface Ethernet d'un PC? Je suppose que oui, ou plutôt je sais que oui, car je le fais déjà avec des machines virtuelles dans VMWare.
Mais sans machine virtuelle? Je suppose que c'est possible aussi. D'ailleurs, je sais que certains serveurs possèdent plusieurs IP, sans faire de la virtualisation pour autant. Mais je n'ai aucune idée de comment ça marche.
En parallèle, je sais qu'on peut faire cohabiter plusieurs "sous-réseaux" (au sens IP) au sein d'un même réseau Ethernet. Ca fonctionne très bien, il n'y a rien à configurer de particulier. Tout ceci sans VLAN, je précise!
Donc en voyant ces 2 aspects, j'envisage la chose suivante: à partir d'un seul PC, équipé d'une seule interface Ethernet, serait-il possible d'accéder à chacun de ces 2 sous réseaux (qui cohabitent sur le même réseau ethernet), donc avec 2 IP différentes? Juste avec des bidouilles logicielles? Sans VLAN? Le tout avec un PC Vista ou XP?
Si oui, comment différencier quel logiciel utilise quelle IP (et donc sous-réseau)?
N'hésitez pas à me dire si je ne suis pas clair. Et merci d'avance aux experts en réseau.
Leon.
-
oui on peut, ça s’appelle du multi-homing (attention toutefois, ce terme a plusieurs sens suivant le contexte).
Sous Windows, on peut le faire avec l'interface graphique (bouton config avancée) ou en ligne de commande avec netsh.
Sauf cas speciaux, on ne différencie pas explicitement comment les logiciels utilisent tel ou tel IP. C'est le systeme (le routage en fait) qui s'en charge en fonction de la destination a atteindre.
Pour les logiciels type 'serveurs' (qui 'écoutent' sur port en attente de quelque chose) soit ils ont prévu le cas et permettent de choisir sur quel(s) ip(s) ils ecoutent (generalement ca s'appele la/les bind address(es) dans leur config), soit il n'ont pas prévu et dans ce cas ils n’écoutent que sur une seule IP , la première définie (dite IP principale).
-
Exemple sous Linux :
ifconfig eth0 1.1.1.1 netmask 255.0.0.0
ifconfig eth0:1 2.2.2.2 netmask 255.0.0.0
ifconfig eth0:2 3.3.3.3 netmask 255.0.0.0
etc etc etc
On peut très bien définir des adresses IP d'un meme réseau IP : ça s'appelle de l'aliasing. Ca peut etre pratique dans le cas de la migration d'un ancien serveur.
-
Merci pour la rapidité de la réponse!
Pour les logiciels type 'serveurs' (qui 'écoutent' sur port en attente de quelque chose) soit ils ont prévu le cas et permettent de choisir sur quel(s) ip(s) ils ecoutent (generalement ca s'appele la/les bind address(es) dans leur config), soit il n'ont pas prévu et dans ce cas ils n’écoutent que sur une seule IP , la première définie (dite IP principale).
Et côté "client"? Peut-on choisir laquelle des 2 IP va être choisie par un logiciel client sur le PC qui possède 2 IP? Le logiciel qui va initier une connexion TCP? Si non, comment va se faire le choix?
Est-ce que par exemple une adresse IP de destination qui est déjà dans un des 2 sous-réseaux (donc joignable directement sans passeer par une passerelle/routeur) sera systématiquement atteinte depuis l'IP du PC qui est sur le même sous-réseau?
Merci d'avance.
Leon.
-
En priorité ce sont les règles de routage qui s'appliquent : si une IP est accessible en direct, on l'utilise. Si on essaye de forcer le trafic du client à passer par une autre interface, il est probable (voir meme certain) que le serveur réponde par l'interface étant directement connecté au client.
Dans les cas posant problèmes en multi-homing, les controleurs de domaine Windows en font partie (à l'époque NT4 c'était meme interdit).
-
Et côté "client"? Peut-on choisir laquelle des 2 IP va être choisie par un logiciel client sur le PC qui possède 2 IP? Le logiciel qui va initier une connexion TCP? Si non, comment va se faire le choix?
Est-ce que par exemple une adresse IP de destination qui est déjà dans un des 2 sous-réseaux (donc joignable directement sans passeer par une passerelle/routeur) sera systématiquement atteinte depuis l'IP du PC qui est sur le même sous-réseau?
coté 'client', c'est exactement comme avec 2 cartes réseaux, y'a pas de différence.
on ne choisi pas l'IP, c'est le systeme qui fait le choix en fonction de l'IP distante
c'est le principe du routage comme a expliqué BadMax.
-
Effectivement, je viens de tester à l'instant.
L'adresse IP source utilisée depuis le PC qui possède 2 adresses IP, c'est l'adresse IP la plus "proche" de la destination, selon la table de routage du PC; et c'est vrai que l'adresse de destination soit sur le même sous-réseau ou derrière un routeur/passerelle. Donc ça me semble assez optimal comme méthode de fonctionnement. Ca m'arrange bien en fait.
Leon.
-
Je rajouterais qu'avec la commande netstat (sous Linux comme sous Windows), on peut regarder sur quelle(s) interface(s) écoute telle application serveur.
Exemple sous Windows :
C:\>netstat -an
Connexions actives
Proto Adresse locale Adresse distante État
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
...
TCP 127.0.0.1:2559 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4370 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4380 0.0.0.0:0 LISTENING
...
TCP 192.168.1.2:139 0.0.0.0:0 LISTENING
Si adresse locale = 0.0.0.0, écoute sur toutes les interfaces à la fois.
Si adresse locale = 127.0.0.1, n'écoute que sur l'interface locale
Si adresse locale = 192.168.1.2, n'écoute que sur l'interface 192.168.1.2 (associée ici à la carte Ethernet, j'ai qu'une adresse IP)
L'application serveur choisit l'interface lors de l'appel à la fonction système bind().
-
Bonjour à tous.
Je continue avec mes questions bizarres.
Ces questions me semblent normales!
Est-il possible de définir plusieurs adresses IP pour une seule et unique interface Ethernet d'un PC?
Sans problème. Pouvoir faire cela n'est pas exigé par les RFC pour les OS supportant IPv4, mais tous les OS supportant IPv4 le permettent. En IPv6 le support par l'OS est obligatoire.
Je suppose que oui, ou plutôt je sais que oui, car je le fais déjà avec des machines virtuelles dans VMWare.
Les machines virtuelles ont leurs propres interfaces Ethernet, distinctes de l'interface de l'hôte : le trafic interne d'une interface Ethernet d'une machine virtuelle ne remonte pas forcèment au niveau d'une interface Ethernet de l'hôte.
Mais sans machine virtuelle? Je suppose que c'est possible aussi. D'ailleurs, je sais que certains serveurs possèdent plusieurs IP, sans faire de la virtualisation pour autant. Mais je n'ai aucune idée de comment ça marche.
Avoir plusieurs adresses IP c'est comme avoir une seule adresse IP, mais plusieurs fois.
En parallèle, je sais qu'on peut faire cohabiter plusieurs "sous-réseaux" (au sens IP) au sein d'un même réseau Ethernet. Ca fonctionne très bien, il n'y a rien à configurer de particulier.
Il n'y pas de raison que ça ne fonctionne pas.
Je crois qu'on appelle ça le "partage de média".
Tout ceci sans VLAN, je précise!
Les VLAN c'est de la triche!
Donc en voyant ces 2 aspects, j'envisage la chose suivante: à partir d'un seul PC, équipé d'une seule interface Ethernet, serait-il possible d'accéder à chacun de ces 2 sous réseaux (qui cohabitent sur le même réseau ethernet), donc avec 2 IP différentes?
Oui.
Remarque : J'ai indiqué l'autre fois qu'un routeur IP est toujours un machin qui a plusieurs IP, sur plusieurs sous-réseaux. Mais la réciproque est fausse. Ton PC a plusieurs IP, sur plusieurs sous-réseaux, sans être un routeur.
Juste avec des bidouilles logicielles? Sans VLAN?
Bien sûr sans VLAN, créer un VLAN c'est créer un lien Ethernet virtuel distinct, ce serait de la triche!
Si oui, comment différencier quel logiciel utilise quelle IP (et donc sous-réseau)?
Convention IP
En IP, 0 est un joker : adresse non spécifiée, adresse non liée.
En IPv4 le joker d'adresse IP est donc 0.0.0.0.
En IPv6 le joker d'adresse IP se note [::] se qui correspond à l'adresse nulle (que des 0).
Pour visualiser l'adresse IP d'écoute
Sous Windows Vista, tu peux voir toutes les socket TCP avec netstat -ta; les socket d'écoute apparaissent en état "LISTENING".
Tu vois l'adresse locale et l'adresse distante de chaque socket. L'adresse distante d'une socket d'écoute est toujours non-spécifiée par définition.
Une socket connectée a toujours ses deux adresses spécifiées.
Pour configurer l'adresse IP d'écoute
Comme administrateur
Tu dois configurer chaque logiciel serveur séparèment : consulter la doc du logiciel en question; quelques exemples :
Pour Apache 2.2 : directive Listen (http://httpd.apache.org/docs/2.2/fr/mod/mpm_common.html#listen) :
Listen [IP-address:]portnumber
Pour sshd : directive ListenAddress dans /etc/ssh/sshd_config
Pour vsftpd : directive listen_address dans vsftpd.conf
Pour les services démarrés par un "super serveur" (comme le classique /usr/sbin/in.telnetd) : dans la config du service dans le "super serveur" :
xinetd : directive bind
Comme programmeur C
La séquence minimal pour ouvrir un TCP passivement est :
/* créer une socket :
type d'adresses pour cette socket :
PF_INET : de domaine d'adressage "IP" (IPv4)
ou bien
PF_INET6 : de domaine d'adressage IPv6
(pour passer en IPv6, il faut rajouter "6" dès qu'il est question d'adresse IP)
type de socket :
SOCK_STREAM :
définit la sémantique de la socket :
- socket de type connecté nécessitant une ouverture passive (listen) et active (connect) de l'autre coté
- socket fournissant à l'application un flux d'octets, sans délimitation des messages (piège pour des débutants!)
protocole :
IPPROTO_TCP : je choisis explicitement le protocole TCP
(mais en pratique on peut aussi laisser 0 qui demande le choix par défaut, qui est toujours TCP)
*/
s = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP);
// si s < 0 l'appel a échoué (examiner errno)
if (s < 0) // en cas d'erreur
{ perror ("socket"); exit (1); } // afficher un message puis quitter
/* une adresse d'extrémité de TCP est constituée d'un port et d'une adresse IP
sockaddr_in : adresse IPv4 + port */
sockaddr_in addr;
// initialisation :
addr.sin_family = AF_INET; // adresse IP (IPv4)
addr.sin_port = 80; // choix de port TCP
addr.sin_addr = INADDR_ANY; // INADDR_ANY = adresse 0
// lier la socket à une adresse d'extrémité de TCP
err = bind (s, &addr, sizeof addr);
// si err = -1 l'appel a échoué (examiner errno)
if (err != 0) // en cas d'erreur
{ perror ("bind"); exit (1); } // afficher un message puis quitter
/* ouverture passive du TCP
backlog : 5
"Le paramètre backlog définit une longueur maximale pour la file des connexions en attente."
*/
err = listen (s, 5);
// si err = -1 l'appel a échoué (examiner errno)
if (err != 0) // en cas d'erreur
{ perror ("listen"); exit (1); } // afficher un message puis quitter
Voilà la façon habituelle de démarrer un serveur TCP :
- l'adresse locale de la socket d'écoute est 0:80, ce qui signifie *:80
- l'adresse distante d'une socket d'écoute est toujours *:*
Si tu veux lier ton serveur à une adresse IP précise, par exemple pour avoir plusieurs différents sur la machine, tu remplaces INADDR_ANY par une adresse IP de ta machine.
Remarque : un pare-feu ne permet pas de choisir l'adresse locale d'une socket. Seule la programmation le permet.
N'hésitez pas à me dire si je ne suis pas clair. Et merci d'avance aux experts en réseau.
Clair comme de l'eau de source.
-
oui on peut, ça s’appelle du multi-homing (attention toutefois, ce terme a plusieurs sens suivant le contexte).
Ce terme est surtout utilisé pour ceux qui font du BGP.
ils n’écoutent que sur une seule IP , la première définie (dite IP principale).
Faux.
Il n'y a rien de tel. Fais des netstat -a.
-
Exemple sous Linux :
ifconfig eth0 1.1.1.1 netmask 255.0.0.0
ifconfig eth0:1 2.2.2.2 netmask 255.0.0.0
ifconfig eth0:2 3.3.3.3 netmask 255.0.0.0
Pourrait-on enfin arrêter d'utiliser cette commande obsolète depuis 10 ans?
Il faut utiliser ip
On peut très bien définir des adresses IP d'un meme réseau IP : ça s'appelle de l'aliasing. Ca peut etre pratique dans le cas de la migration d'un ancien serveur.
Les "alias" d'interfaces sont obsolètes sous linux depuis une dizaine d'années!
Voir Documentation/networking/alias.txt :
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
per interface. Newer tools such as iproute2 support multiple
address/prefixes per interface, but aliases are still supported
for backwards compatibility.
-
Peut-on choisir laquelle des 2 IP va être choisie par un logiciel client sur le PC qui possède 2 IP?
Programmation C
Le logiciel peut le choisir explicitement avec bind :
s = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP);
if (s < 0) // en cas d'erreur
{ perror ("socket"); exit (1); } // afficher un message puis quitter
// adresse locale de socket
sockaddr_in loc;
loc.sin_family = AF_INET;
loc.sin_port = ...;
loc.sin_addr = ...;
err = bind (s, &loc, sizeof loc);
if (err != 0) // en cas d'erreur
{ perror ("bind"); exit (1); } // afficher un message puis quitter
// adresse distante de socket
sockaddr_in dist;
dist.sin_family = AF_INET;
dist.sin_port = ...;
dist.sin_addr = ...;
// ouverture active du TCP
err = connect (s, &dist, sizeof dist);
if (err != 0) // en cas d'erreur
{ perror ("connect"); exit (1); } // afficher un message puis quitter
Choix de l'utilisateur
L'utilisateur peut choisir l'adresse source avec certains utilitaires; p.ex.
telnet
-s src_addr
Set the source IP address for the telnet connection to src_addr,
which can be an IP address or a host name.
ssh
-b bind_address
Use bind_address on the local machine as the source address of
the connection. Only useful on systems with more than one
address.
Sinon, ou s'il "choisit" l'adresse joker, c'est un paramètre de la table de routage.
-
C:\>netstat -an
Connexions actives
Proto Adresse locale Adresse distante État
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
...
TCP 127.0.0.1:2559 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4370 0.0.0.0:0 LISTENING
TCP 127.0.0.1:4380 0.0.0.0:0 LISTENING
...
TCP 192.168.1.2:139 0.0.0.0:0 LISTENING
Si adresse locale = 0.0.0.0, écoute sur toutes les interfaces à la fois.
Si adresse locale = 127.0.0.1, n'écoute que sur l'interface locale
Petite remarque :
127.0.0.1 n'est pas la seule adresse de bouclage local, toute la plage 127/8 est dédiée au bouclage local; donc tu peux utiliser 127.0.0.2, 127.0.0.3 ... pour distinguer des serveurs tournants sur un même port TCP ou UDP.
-
Merci pour ces informations détaillées !
-
Merci pour la rapidité de la réponse!Et côté "client"? Peut-on choisir laquelle des 2 IP va être choisie par un logiciel client sur le PC qui possède 2 IP? Le logiciel qui va initier une connexion TCP? Si non, comment va se faire le choix?
Certaines applications permettent de configurer l'IP utilisée pour la sortie. Tout dépend comment est programmée l'application (cf exemples plus haut).
Est-ce que par exemple une adresse IP de destination qui est déjà dans un des 2 sous-réseaux (donc joignable directement sans passeer par une passerelle/routeur) sera systématiquement atteinte depuis l'IP du PC qui est sur le même sous-réseau?
Cela dépend de la table de routage de votre machine et de la métrique du subnet directement connecté par rapport a la route par défaut. Ou a toute autre route que vous auriez manuellement ajoutée.
Sachant que de manière relativement exhaustive (fonctionnement d'un routeur) le choix d'une route ce fait (en cas de plusieurs chemins possibles) dans l'ordre, par rapport aux critères suivant : masque, distance administrative, métrique.
Les routeurs peuvent avoir plusieurs adresses sur la même interface. Aprés on peut aussi créer des instances de routage virtuelle (VRF chez Cisco), qui crée une table de routage pour chaque VRF. Cela permet de mutualiser le matériel tout en gardant un cloisonnement des réseaux.
Ce type de concepts existe aussi sous Linux, mais l’intérêt, me semble plus limité. Tout au moins en entreprise ou les serveurs sont plutôt mono rôle. Et ou les RSSI n'aiment pas avoir des équipements avec des pattes dans plusieurs réseaux.
-
Merci à tous pour vos réponses. Effectivement, ça m'a permi de bidouiller. Je découvre des choses.
Dans mes bidouilles, j'ai aussi constaté qu'une "passerelle" dans une table de routage d'un PC pouvait être en dehors de la plage du (des) sous-réseaux IP, tout en étant sur le même réseau ethernet. Là aussi c'est pratique. Mais par contre, il faut que la "voie retour" soit prévue, et donc que le routeur en face connaisse la route vers le PC en question.
Leon.
-
Les "alias" d'interfaces sont obsolètes sous linux depuis une dizaine d'années!
Voir Documentation/networking/alias.txt :
IP-aliases are an obsolete way to manage multiple IP-addresses/masks
per interface. Newer tools such as iproute2 support multiple
address/prefixes per interface, but aliases are still supported
for backwards compatibility.
J'ai donc testé le fait de mettre plusieurs IP sans mettre d'alias : cela ne fonctionne pas
Je précise que chaque IPv4 est dans un /24 différent avec une gateway différente.
Même chose pour IPv6 où chaque IPv6 est dans un /64 différent.
auto eno1
iface eno1 inet static
address IPv4-A
netmask 255.255.255.0
gateway GWv4-A
iface eno1 inet static
address IPv4-B
netmask 255.255.255.0
gateway GWv4-B
iface eno1 inet6 static
address IPv6-A
netmask 64
gateway GWv6-A
iface eno1 inet6 static
address IPv6-B
netmask 64
gateway GWv6-B
Peut être qu'il n'est possible de mettre plusieurs IPv4 sur la même interface qui si elles sont toutes dans la même plage ?
Si les alias semble toujours d’actualité pour IPv4, elle ne sont plus nécessaire pour IPv6 : Cette configuration fonctionne
auto eno1
iface eno1 inet static
address IPv4-A
netmask 255.255.255.0
gateway GWv4-A
iface eno1 inet6 static
address IPv6-A
netmask 64
gateway GWv6-A
iface eno1 inet6 static
address IPv6-B
netmask 64
gateway GWv6-B
auto eno1:0
iface eno1:0 inet static
address IPv4-B
netmask 255.255.255.0
gateway GWv6-B
Voici ce que cela donne avec un ifconfig : Les 2 IPv6, chacune dans un /64 sont bien dans la même interface sans alias.
$ ifconfig
eno1 Link encap:Ethernet HWaddr 00:26:b9:8b:b7:05
inet adr:IPv4-A Bcast: Masque:255.255.255.0
adr inet6: IPv6-A/64 Scope:Global
adr inet6: IPv6-B/64 Scope:Global
adr inet6: fe80::226:b9ff:fe8b:b705/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:492 erreurs:0 :0 overruns:0 frame:0
TX packets:141 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:46929 (46.9 KB) Octets transmis:21571 (21.5 KB)
eno1:0 Link encap:Ethernet HWaddr 00:26:b9:8b:b7:05
inet adr:IPv4-B Bcast: Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
-
J'ai arrêté d'utiliser Ifconfig perso, je fais tout avec ip directement et des post-up dans le interfaces (le petit protip de Jack :) )
-
J'ai cherché à faire plus propre et à mettre
eno1 : IPv4-A et IPv6-A
eno1:0 : IPv4-B et IPv6-B
Cela ne fonctionne pas, je ne récupère pas d'IPv6 sur l'alias en01:0
auto eno1
iface eno1 inet static
address IPv4-A
netmask 255.255.255.0
gateway GWv4-A
iface eno1 inet6 static
address IPv6-A
netmask 64
gateway GWv6-A
auto eno1:0
iface eno1:0 inet static
address IPv4-B
netmask 255.255.255.0
gateway GWv6-B
iface eno1:0 inet6 static
address IPv6-B
netmask 64
gateway GWv6-B
En résumé :
eno1 : IPv4-A et IPv6-A + eno1:0 : IPv4-B et IPv6-B => ne fonctionne pas car IPv6 refuse d'être sur un alias
eno1 : IPv4-A IPv4-B et IPv6-A IPv6-B => ne fonctionne pas car impossible de mettre deux IPv4 sans créer d'alias
eno1 : IPv4-A IPv4-B et IPv6-A + eno1:0 : IPv6-B => OK
-
il semble qu'en ipv4 il ne faut qu'un seul gateway par interface non ?
sinon la méthode recommandée est avec 'ip' et des ifup/ifdown.
-
J'ai donc testé le fait de mettre plusieurs IP sans mettre d'alias : cela ne fonctionne pas
Je précise que chaque IPv4 est dans un /24 différent avec une gateway différente.
Même chose pour IPv6 où chaque IPv6 est dans un /64 différent.
iface eno1 inet static
address IPv4-A
netmask 255.255.255.0
gateway GWv4-A
Je ne connais pas cette syntaxe!
Ce n'est pas du linux. Ce de la m...asse rajoutée.
-
il semble qu'en ipv4 il ne faut qu'un seul gateway par interface non ?
Pardon?
Le "gateway" c'est lié à une route, pas une interface.
-
Je ne connais pas cette syntaxe!
Ce n'est pas du linux. Ce de la m...asse rajoutée.
Tu mets quoi dans ton fichier /etc/network/interfaces ?
C'est l'unique syntaxe, non ?
/etc/network/interfaces issu d'un serveur pré-configuré par OVH :
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 37.187.131.220
netmask 255.255.255.0
network 37.187.131.0
broadcast 37.187.131.255
gateway 37.187.131.254
iface eth0 inet6 static
address 2001:41d0:000a:41dc::
netmask 64
dns-nameservers 2001:41d0:3:163::1
post-up /sbin/ip -family inet6 route add 2001:41d0:000a:41ff:ff:ff:ff:ff dev eth0
post-up /sbin/ip -family inet6 route add default via 2001:41d0:000a:41ff:ff:ff:ff:ff
pre-down /sbin/ip -family inet6 route del default via 2001:41d0:000a:41ff:ff:ff:ff:ff
pre-down /sbin/ip -family inet6 route del 2001:41d0:000a:41ff:ff:ff:ff:ff dev eth0
-
J'ai cherché à faire plus propre et à mettre
C'est pas plus propre, c'est une illusion parce que c'est parsé par le service 'networking', en vrai c'est déguelasse de faire des alias.
La vraie bonne solution c'est de mettre les autres IP en post-up et si tu veux plusieurs gateway en fonction, des post-up avec des 'src X.X.X.X', je fais ça pour le management de certaines VMs.
-
Tu nous donnes un fichier /etc/network/interfaces avec IP anonymisées en exemple ?
-
Tu mets quoi dans ton fichier /etc/network/interfaces ?
Rien, ça me gonfle (pour parler poliment), je n'utilise pas ces niaiseries.
La configuration directe des interfaces et des routes me convient parfaitement. Je n'ai pas envie que des outils se mettent en travers.
-
J'espère que tu respectes tes convictions jusqu'au bout et que tu utilises des cartes perforées à la place de ces niaiseries de clavier et d'écran. Et ne parlons pas de la souris...
-
une facon de faire. Certains preferent mettre les IP secondaires en post-up, pre-down plutot que up/down.
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
gateway 192.168.1.254
up ip addr add 192.168.1.2/24 dev $IFACE
down ip addr del 192.168.1.2/24 dev $IFACE
up ip addr add 10.1.1.1/24 dev $IFACE
post-up ip route add default via 10.1.1.254 src 10.1.1.1
pre-down ip route del default via 10.1.1.254 src 10.1.1.1
down ip addr del 10.1.1.1/24 dev $IFACE
mais en pratique on utilisera une table différente pour 10.1.1.1
par exemple:
post-up ip route add default via 10.1.1.254 src 10.1.1.1 table mgmtavec "mgmt" étant la table de routage pour le trafic de management par exemple (nb: "mgmt" est a ajouter dans /etc/iproute2/rt_tables)
pius ensuite des regles, par exemple:
ip rule add from 10.1.1.1/32 table mgmt
ip rule add to 10.1.1.254/32 table mgmt
bref c'est un exemple fait de tête, j'ai peut-etre oublié un truc ou 2 :p
-
Les label ne sont pas fortement recommandés pour éviter des pb avec certains drivers ?
Le wiki de debian propose
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.42
netmask 255.255.255.0
gateway 192.168.1.1
up ip addr add 192.168.1.43/24 dev $IFACE label $IFACE:0
down ip addr del 192.168.1.43/24 dev $IFACE label $IFACE:0
up ip addr add 192.168.1.44/24 dev $IFACE label $IFACE:1
down ip addr del 192.168.1.44/24 dev $IFACE label $IFACE:1
up ip addr add 10.10.10.14/24 dev $IFACE label $IFACE:2
down ip addr del 10.10.10.14/24 dev $IFACE label $IFACE:2
-
Tu nous donnes un fichier /etc/network/interfaces avec IP anonymisées en exemple ?
Flemme de trier, mais y'a un peu de tout ce dont je parle :
hugues@core:~$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*
auto lo iface lo inet loopback
auto ens18
iface ens18 inet static
address 192.168.1.231
netmask 255.255.255.0
gateway 192.168.1.1
iface ens18 inet6 static
address 2a03:4980:1b:b300:c0de::1
netmask 64
auto ens19
iface ens19 inet static
address 10.0.3.1
netmask 255.255.255.0
iface ens19 inet6 static
address 2a03:4980:1b:b300:cafe::1
netmask 80
# ____ ____ _____
#| _ \ / ___|___ /
#| | | | | |_ \
#| |_| | |___ ___) |
#|____/ \____|____/
#Tunnel DC3
post-up ip -6 tunnel add GRE-CSS-DC3 mode ip6gre remote 2001:bc8:2832::1 local 2a03:4980:1b:b300:c0de::1 ttl 255
post-up ip -6 link set GRE-CSS-DC3 up
post-up ip addr add 10.1.0.18/30 dev GRE-CSS-DC3
post-up ip -6 addr add 2001:bc8:2832:2::9/127 dev GRE-CSS-DC3
#Route DC3
post-up ip route add 2001:bc8:2832::1/128 via fe80::21e:80ff:fe1c:8b8a dev ens18
post-up ip route add 2001:bc8:2832::/48 via 2001:bc8:2832:2::8 src 2a03:4980:1b:b300:cafe::1
post-up ip route add 10.0.2.0/24 via 10.1.0.17
# _____ _ _ ____
#|_ _| | | |___ \
# | | | |_| | __) |
# | | | _ |/ __/
# |_| |_| |_|_____|
#Tunnel TH2
post-up ip -6 tunnel add GRE-CSS-TH2 mode ip6gre remote 2a03:4980:210:4000::c0de local 2a03:4980:1b:b300:c0de::1 ttl 255
post-up ip -6 link set GRE-CSS-TH2 up
post-up ip addr add 10.1.0.22/30 dev GRE-CSS-TH2
post-up ip -6 addr add 2001:bc8:2832:2::11/127 dev GRE-CSS-TH2
#Route TH2
post-up ip -6 route add 2a03:4980:210:4000::c0de/128 via fe80::21e:80ff:fe1c:8b8a dev ens18
post-up ip route add 10.0.1.0/24 via 10.1.0.21 dev GRE-CSS-TH2
post-up ip -6 route add 2a03:4980:210:4000:1::/50 via 2001:bc8:2832:2::10 dev GRE-CSS-TH2
# _ __ ___ _
#| | \ \ / / \ | |
#| | \ V /| \| |
#| |___| | | |\ |
#|_____|_| |_| \_|
post-up ip route add 10.0.0.0/24 via 10.1.0.17
-
J'espère que tu respectes tes convictions jusqu'au bout et que tu utilises des cartes perforées à la place de ces niaiseries de clavier et d'écran. Et ne parlons pas de la souris...
Je trouve que l'interface "graphique" est très souvent une abjecte perte de temps dans les interfaces de configuration par rapport à un unique fichier texte avec une syntaxe bien conçue et très lisible.
-
Pour ceux qui tombent sur ce sujet et qui cherchent une solution pour un Debian ou un Ubuntu, voici une configuration qui fonctionne avec 4 IPv4 sur un même /29 et 4 IPv6 sur un même /64
Les "label" en IPv4 sont facultatifs, mais conseillés pour que les IP s'affichent avec ifconfig (sinon vous ne voyez que la première IPv4, mais les autres fonctionnent).
Les "label" en IPv6 sont inutiles et ignorés, tout est mis à coté des autres IPv6, dans un ordre que je ne comprend pas toujours...
enp1s0f0 est mon interface réseau (cela pourrait être eth0)
# The loopback network interface
auto lo
iface lo inet loopback
# Interface Ethernet
auto enp1s0f0
# IPv4/IPv6 N°1
iface enp1s0f0 inet static
address 46.227.1.186
netmask 255.255.255.248
gateway 46.227.1.185
iface enp1s0f0 inet6 static
address 2A01:6E00:10:410::2
netmask 64
gateway 2A01:6E00:10:410::1
dns-nameservers 2001:860:b0ff:1::1 2001:860:b0ff:1::2
# IPv4/IPv6 N°2 :
up ip addr add 46.227.1.187/29 dev $IFACE label $IFACE:0
down ip addr del 46.227.1.187/29 dev $IFACE label $IFACE:0
up ip -6 addr add 2A01:6E00:10:410::3/64 dev $IFACE
down ip -6 addr del 2A01:6E00:10:410::3/64 dev $IFACE
# IPv4/IPv6 N°3 :
up ip addr add 46.227.1.188/29 dev $IFACE label $IFACE:1
down ip addr del 46.227.1.188/29 dev $IFACE label $IFACE:1
up ip -6 addr add 2A01:6E00:10:410::4/64 dev $IFACE
down ip -6 addr del 2A01:6E00:10:410::4/64 dev $IFACE
# IPv4/IPv6 N°4 :
up ip addr add 46.227.1.189/29 dev $IFACE label $IFACE:2
down ip addr del 46.227.1.189/29 dev $IFACE label $IFACE:2
up ip -6 addr add 2A01:6E00:10:410::5/64 dev $IFACE
down ip -6 addr del 2A01:6E00:10:410::5/64 dev $IFACE
-
Quelle utilité de la supprimer au down sachant que c'est volatile ?
-
Les "label" en IPv4 sont facultatifs, mais conseillés pour que les IP s'affichent avec ifconfig (sinon vous ne voyez que la première IPv4, mais les autres fonctionnent).
Qui utilise encore ifconfig?
-
Qui utilise encore ifconfig?
Tu préfères ip address show ?
C'est clairement différent comme information entre les deux utilitaires.
ip address show :
$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: em1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether d4:ae:52:ce:9a:9c brd ff:ff:ff:ff:ff:ff
3: em2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether d4:ae:52:ce:9a:9d brd ff:ff:ff:ff:ff:ff
4: p1p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 90:e2:ba:19:f7:50 brd ff:ff:ff:ff:ff:ff
inet 194.158.119.190/30 brd 194.158.119.191 scope global p1p1
valid_lft forever preferred_lft forever
inet6 2001:860:f70a:100::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::92e2:baff:fe19:f750/64 scope link
valid_lft forever preferred_lft forever
5: p1p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 90:e2:ba:19:f7:51 brd ff:ff:ff:ff:ff:ff
ifconfig n'affiche que les interfaces actives et donne des statistiques (erreurs, quantité de données transféré depuis le reboot)
$ ifconfig
lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:65536 Metric:1
Packets reçus:155294 erreurs:0 :0 overruns:0 frame:0
TX packets:155294 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1
Octets reçus:235414680 (235.4 MB) Octets transmis:235414680 (235.4 MB)
p1p1 Link encap:Ethernet HWaddr 90:e2:ba:19:f7:50
inet adr:194.158.119.190 Bcast:194.158.119.191 Masque:255.255.255.252
adr inet6: fe80::92e2:baff:fe19:f750/64 Scope:Lien
adr inet6: 2001:860:f70a:100::2/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:27773859999 erreurs:0 :0 overruns:0 frame:0
TX packets:59703120974 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:2084601697821 (2.0 TB) Octets transmis:88905105285422 (88.9 TB)
Quelle utilité de la supprimer au down sachant que c'est volatile ?
C'est plus propre, non ?
-
C'est clairement différent comme information entre les deux utilitaires.
Tu peux retrouver toutes les infos de ifconfig avec ip, mais ça prend beaucoup plus de temps...
C'est plus propre, non ?
Je n'ai jamais compris l'intéret, je monte tout à coup de post-up chez moi
auto eth0
iface eth0 inet static
address 178.250.208.130
netmask 27
gateway 178.250.208.142
iface eth0 inet6 static
address 2a03:4980:210:4000:1::1
netmask 50
gateway 2a03:4980:210:4000::1
post-up ip -6 addr add 2a03:4980:210:4000::c0de/50 dev eth0
post-up ip addr add 10.0.1.254/32 dev lo
-
c'est plus future proof et plus clean. ca permet aussi si on a d'autres scripts en up/post-up et/ou pre-down/down d’être toujours dans un état cohérent (par exemple si on met a jour des entrée DNS).
mais c'est sur que la l'exemple étant simple les 'down' ne sont pas forcement nécessaire.
Tu peux retrouver toutes les infos de ifconfig avec ip, mais ça prend beaucoup plus de temps...
Je n'ai jamais compris l'intéret, je monte tout à coup de post-up chez moi
auto eth0
iface eth0 inet static
address 178.250.208.130
netmask 27
gateway 178.250.208.142
iface eth0 inet6 static
address 2a03:4980:210:4000:1::1
netmask 50
gateway 2a03:4980:210:4000::1
post-up ip -6 addr add 2a03:4980:210:4000::c0de/50 dev eth0
post-up ip addr add 10.0.1.254/32 dev lo
ton indentation ne correspond pas a la facon dont est interprété le fichier.
le systeme le comprend et l'executera comme ca:
auto eth0
iface eth0 inet static
address 178.250.208.130
netmask 27
gateway 178.250.208.142
iface eth0 inet6 static
address 2a03:4980:210:4000:1::1
netmask 50
gateway 2a03:4980:210:4000::1
post-up ip -6 addr add 2a03:4980:210:4000::c0de/50 dev eth0
post-up ip addr add 10.0.1.254/32 dev lo
ca revient au meme sur un exemple trivial comme ca mais faut faire gaffe sur des configs plus complexes.
-
Moi j'aimerais bien trouver plus "future proof" que des post-up, ou autres, je trouve ça assez moche :/
-
Tu peux déjà utiliser $IFACE à la place de eth0 etc
-
@Hugues, suit mon exemple: https://lafibre.info/tcpip/plusieurs-ip-sur-1-seul-interface/msg437810/#msg437810
Quand on a plusieurs IP sur une même interface qui ont accès à l'Internet, il faut choisir celle qui sera utilisée quand le serveur a des requêtes à faire (DNS, mises à jour,...)
Quelle est la solution la plus propre pour choisir l'IP ?
Mettre des métriques pour chaque IP est toujours la solution ? (certains disent que c'est déprécié)
Comment se fait le choix de l'interface utilisée quand les métriques sont équivalent et l'adresse mac aussi vu qu'on est sur la même carte ?
Il me semble que en IPv6, c'est l'IPv6 la plus élevée qui est utilisée.
-
Quand tu rajoutes une route, par exemple ta default:
ip r a default via <ip> source <ip>
À voir s'il y a plus élégant
-
J'utilise source, mais pourquoi les métric seraient dépréciées ? C'est une des composantes du routage...
Vivien : je parle d'une solution qui n'impliquerait pas de taper des commandes "ip" à la main, comme le fichier "interfaces" de base.
-
Voila un début de solution pour toi, hugues:
Avant:
root@ole:~# cat /etc/network/interfaces
#
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 178.250.208.68
netmask 27
gateway 178.250.208.94
root@ole:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether aa:00:00:c9:03:22 brd ff:ff:ff:ff:ff:ff
inet 178.250.208.68/27 brd 178.250.208.95 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::a800:ff:fec9:322/64 scope link
valid_lft forever preferred_lft forever
Après:
root@ole:~# cat /etc/network/interfaces
#
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
post-up ip link add bidule link eth0 type macvlan mode bridge
post-up ip link add machin link eth0 type macvlan mode bridge
post-up ip link add truc link eth0 type macvlan mode bridge
auto eth0
iface eth0 inet static
address 178.250.208.68
netmask 27
gateway 178.250.208.94
auto bidule
iface bidule inet static
address 178.250.208.76
netmask 27
auto machin
iface machin inet static
address 178.250.208.77
netmask 27
auto truc
iface truc inet static
address 178.250.208.78
netmask 27
root@ole:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether aa:00:00:c9:03:22 brd ff:ff:ff:ff:ff:ff
inet 178.250.208.68/27 brd 178.250.208.95 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::a800:ff:fec9:322/64 scope link
valid_lft forever preferred_lft forever
3: bidule@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f2:e8:72:79:81:07 brd ff:ff:ff:ff:ff:ff
inet 178.250.208.76/27 brd 178.250.208.95 scope global bidule
valid_lft forever preferred_lft forever
inet6 fe80::f0e8:72ff:fe79:8107/64 scope link
valid_lft forever preferred_lft forever
4: machin@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3e:51:5a:59:58:33 brd ff:ff:ff:ff:ff:ff
inet 178.250.208.77/27 brd 178.250.208.95 scope global machin
valid_lft forever preferred_lft forever
inet6 fe80::3c51:5aff:fe59:5833/64 scope link
valid_lft forever preferred_lft forever
5: truc@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether de:50:fa:98:3e:f0 brd ff:ff:ff:ff:ff:ff
inet 178.250.208.78/27 brd 178.250.208.95 scope global truc
valid_lft forever preferred_lft forever
inet6 fe80::dc50:faff:fe98:3ef0/64 scope link
valid_lft forever preferred_lft forever
root@ole:~# ping -c1 -I 178.250.208.76 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 178.250.208.76 : 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=5.99 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 5.995/5.995/5.995/0.000 ms
root@ole:~# ping -c1 -I 178.250.208.78 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 178.250.208.78 : 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=6.00 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
-
@Hugues, suit mon exemple: https://lafibre.info/tcpip/plusieurs-ip-sur-1-seul-interface/msg437810/#msg437810
Quand on a plusieurs IP sur une même interface qui ont accès à l'Internet, il faut choisir celle qui sera utilisée quand le serveur a des requêtes à faire (DNS, mises à jour,...)
C'est toujours le code de routage qui définit l'adresse IP source quand elle n'est pas choisie par l'application.
-
Je remonte ce sujet : impossible de rajouter un métrique avec la commande ip :
ip addr add 192.168.10.1/24 dev enp1s0f0 label enp1s0f0:0 metric 12
Error: either "local" is duplicate, or "metric" is a garbage.
J'ai pourtant un vieux fichier de conf utilisé il y a 12 ans qui utilisait des métriques (par contre il y avait un port physique par IP)
# The loopback network interface
auto lo
iface lo inet loopback
# Internet
allow-hotplug eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 217.171.27.254
netmask 255.255.252.0
gateway 217.171.24.1
metric 0
# VoIP
allow-hotplug eth1
iface eth1 inet static
address 217.171.31.241
netmask 255.255.252.0
# gateway 217.171.28.1
metric 11
# VoD
allow-hotplug eth2
iface eth2 inet static
address 10.50.6.36
netmask 255.255.254.0
# gateway 10.50.6.1
metric 11
# Supervision Flamingo
allow-hotplug eth3
iface eth3 inet static
address 10.200.44.2
netmask 255.255.255.248
# gateway 10.200.44.1
metric 11
# Multicast
allow-hotplug eth4
iface eth4 inet static
address 192.168.10.2
netmask 255.255.255.0
# gateway 192.168.10.1
metric 12
-
Une metric sur une IP ?
La metric s'applique sur des routes, plutôt, non ?
-
J'ai pourtant un vieux fichier de conf utilisé il y a 12 ans qui utilisait des métriques (par contre il y avait un port physique par IP)
# The loopback network interface
auto lo
iface lo inet loopback
# Internet
allow-hotplug eth0
#iface eth0 inet dhcp
iface eth0 inet static
address 217.171.27.254
netmask 255.255.252.0
gateway 217.171.24.1
metric 0
# VoIP
allow-hotplug eth1
iface eth1 inet static
address 217.171.31.241
netmask 255.255.252.0
# gateway 217.171.28.1
metric 11
# VoD
allow-hotplug eth2
iface eth2 inet static
address 10.50.6.36
netmask 255.255.254.0
# gateway 10.50.6.1
metric 11
# Supervision Flamingo
allow-hotplug eth3
iface eth3 inet static
address 10.200.44.2
netmask 255.255.255.248
# gateway 10.200.44.1
metric 11
# Multicast
allow-hotplug eth4
iface eth4 inet static
address 192.168.10.2
netmask 255.255.255.0
# gateway 192.168.10.1
metric 12
En ce qui concerne ce "vieux fichier de config", je ne comprends pas...
On peut déclarer plusieurs "gateway" sur une même machine? Si oui, ça va fonctionner comment? Et surtout est-ce que ça sera répétable comme fonctionnement?
Ca me parait quand même très bizarre comme config, mais je suis loin d'être un expert, donc j'aimerais bien en savoir plus.
Leon.
-
Le vieux de fichier de config étais associé a des routes : chaque interface n'était utilisé que pour accéder à des plages IP précises.
Là dans ma conf actuelle, c'est un peu différent car chaque IP a accès à tous l'Internet. Si le serveur reçois une requête de l'IP A , il répond par l'IP A ect.. pour les autres IP. Cela fonctionne bien, sauf pour les connexions initiées par le serveurs qui sortent par la mauvaise IP.
Comme Metric apparaît au niveau de ifconfig, je pensais qu'on pouvais modifier le Metric d'une interface.
$ ifconfig | grep Metric
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
UP LOOPBACK RUNNING MTU:65536 Metric:1
-
Le vieux de fichier de config étais associé a des routes : chaque interface n'était utilisé que pour accéder à des plages IP précises.
OK, mais je ne comprends toujours pas. Une gateway, c'est une route très spéciale, c'est LA route par défaut vers tout le reste du monde, vers tout ce qui est à l'extérieur du réseau local. C'est donc très différent d'une route classique.
D'ailleurs, dans le fichier de config en question, nulle part tu ne déclares "les plages d'IP précises" vers lesquelles pointe chaque "gateway".
Bref, je ne comprends toujours pas ce que fait ce fichier de config. Si toi ou quelqu'un d'autre pouvait m'expliquer...
Perso, je fais bien attention à ne mettre qu'une seule gateway, qu'une seule route par défaut sur une machine qui a plusieurs interfaces. Mais si on peut faire autrement, alors ça m'intéresse, et j'aimerais comprendre comment ça fonctionne.
Leon.
-
On peut déclarer plusieurs "gateway" sur une même machine? Si oui, ça va fonctionner comment? Et surtout est-ce que ça sera répétable comme fonctionnement?
On peut, ça fait du loadbalancing entre les gateways si elles ont un poids/metric egal
Mais là dans l'exemple, elles sont commentées
-
Une gateway, c'est une route très spéciale, c'est LA route par défaut vers tout le reste du monde, vers tout ce qui est à l'extérieur du réseau local. C'est donc très différent d'une route classique.
Une gateway est une route, elle n'a absolument rien de plus, rien de moins, rien de différent, de toutes les autres routes
Tu peux voir ça comme un alias
-
metric dans ton fichier de conf vient d'un module optionnel ifmetric qui sert a manipuler la metric du routage a posteriori. ca permet notamment de changer la metric sur des routes attachées a une interface configurée par dhcp . voir man ifmetric ( 8 ).
Le 'metric' qui apparait dans ifconfig ne fonctionne pas sous Linux (SIOCGIFMETRIC n'est pas implèmenté sous Linux). En revanche il marche sur les variantes de BSD (d'ou la présence de ifmetric sur Linux).
-
Une gateway est une route, elle n'a absolument rien de plus, rien de moins, rien de différent, de toutes les autres routes
Tu peux voir ça comme un alias
OK, du coup, si je déclare plusieurs routes par défaut, est-ce que le système d'exploitation choisira systématiquement la première qui apparait dans la table de routage? Ou alors comme le suggère Hugues, il va faire du "load balancing"?
Si oui, c'est du vrai load balancing propre, qui maintient une connexion (TCP ou UDP) sur la même route?
Est-ce que tous les systèmes d'exploitation (windows/linux) acceptent ça et surtout est-ce qu'ils fonctionnent tous de la même façon?
Leon.
-
C’était le cas type c'est un PC en DHCP avec wifi + ethernet donc 2 connexion LAN identiques.
Par défaut les 2 routes par défaut seront de meme poids donc les flux vont se répartir en le wifi et l'ethernet (sauf si y'a Network Manager qui genere lui meme une métric plus forte pour le wifi).
Avec ifmetric on peut mettre un metric plus grande que 0 pour le wifi ce qui fait qu'il ne servira plus par défaut quand l'ethernet est branché.
-
OK, du coup, si je déclare plusieurs routes par défaut, est-ce que le système d'exploitation choisira systématiquement la première qui apparait dans la table de routage? Ou alors comme le suggère Hugues, il va faire du "load balancing"?
Si oui, c'est du vrai load balancing propre, qui maintient une connexion (TCP ou UDP) sur la même route?
Non, c'est purement et simplement un paquet de chaque coté, c'est assez inutilisable en fait.
(J'en ai fait les frais cet après midi en passant de mon xDSL Free à mon FTTH Orange, j'avais deux routes sur mon routeur, j'ai coupé Free : environ 1 ping sur 2 qui se perdait...)
-
Vous voyez où plusieurs gateway dans mes exemples ?
Dans mon vieux fichier de config, je rajoutais les routes à la main :
route add -net 10.50.0.0 netmask 255.255.0.0 gw 10.50.6.1
route add -net 10.200.0.0 netmask 255.255.0.0 gw 10.200.44.1
route add -net 225.0.0.0 netmask 255.0.0.0 gw 10.50.6.1
Sinon quand un même serveur porte plusieurs plages IP différentes sur une seule interface, une seule gateway est nécessaire et cela ne gêne pas Linux qu'elle ne soit pas dans le masque de sous réseau.
Dans mon exemple récent, le serveur porte deux plages IPv6 : une plage IPv6 unicast et une plage IPv6 anycast complètement différente.
Une seule gateway est déclarée. Le serveur répond bien aux requêtes en IPv6 anycast et en IPv6 unicast.
Par contre quand lui a besoin d'Internet (requêtes DNS par exemple), il utilise son IPv6 anycast par défaut. Si le serveur ciblé est proche aucun souci, mais si le serveur est plus proche d'un autre serveur avec la même plage IPv6 anycast, la réponse va au second serveur. Je pensais pouvoir m'en sortir avec des métriques, mais je vais rajouter des routes avec métriques.
-
Vous voyez où plusieurs gateway dans mes exemples ?
T'inquiètes pas, c'est juste moi qui ne sait pas lire les fichiers de conf linux.
Leon.
-
Dans mon exemple récent, le serveur porte deux plages IPv6 : une plage IPv6 unicast et une plage IPv6 anycast complètement différente.
Une seule gateway est déclarée. Le serveur répond bien aux requêtes en IPv6 anycast et en IPv6 unicast.
Par contre quand lui a besoin d'Internet (requêtes DNS par exemple), il utilise son IPv6 anycast par défaut. Si le serveur ciblé est proche aucun souci, mais si le serveur est plus proche d'un autre serveur avec la même plage IPv6 anycast, la réponse va au second serveur. Je pensais pouvoir m'en sortir avec des métriques, mais je vais rajouter des routes avec métriques.
Si tu essaye de suivre RFC 6724, ca donne quoi ? Toujours l'anycast ?
As-tu essaye de mettre l'Anycast sur une loopback ?
En effet, en IPv6, la source address selection n'est pas aussi simple qu'en v4, voir la RFC en question (6724).
-
Non, c'est purement et simplement un paquet de chaque coté, c'est assez inutilisable en fait.
(J'en ai fait les frais cet après midi en passant de mon xDSL Free à mon FTTH Orange, j'avais deux routes sur mon routeur, j'ai coupé Free : environ 1 ping sur 2 qui se perdait...)
Euh c'est faux, le load balancing fonctionne super bien... quand c'est bien configuré :)
Toi ton problème, c'est que tu as une IP différente sur chaque sortie et que ton routeur sort sur Orange avec une IP source Free ! Ca ne te choque pas ? En tout cas, c'est la raison de ta perte.
Chez moi (sur du Mikrotik) je créé une règle src-nat PAR interface (et pas de masquerade, je parle bien de src-nat, nuance), et sur mes routes 0.0.0.0/0 à poids égal, je force ma pref-src avec l'IP de l'interface concernée pour être sur. Et ça juste marche :)
Bon ça c'est bien pour le ping, mais en pratique, il faut load-balancer par connexion et non par paquet. Et là pareil, un p'tit coup de règle "mangle" dans le firewall pour dispatcher ça selon tes goûts, sans craindre le loss en cas de perte d'un lien (quand un lien tombe chez moi, ça enlève les routes correspondantes, donc même si mon firewall load-balance, ça sort tout sur le seul lien avec la bonne IP source quand même).
-
Dans mon exemple récent, le serveur porte deux plages IPv6 : une plage IPv6 unicast et une plage IPv6 anycast complètement différente.
Une seule gateway est déclarée. Le serveur répond bien aux requêtes en IPv6 anycast et en IPv6 unicast.
Par contre quand lui a besoin d'Internet (requêtes DNS par exemple), il utilise son IPv6 anycast par défaut. Si le serveur ciblé est proche aucun souci, mais si le serveur est plus proche d'un autre serveur avec la même plage IPv6 anycast, la réponse va au second serveur. Je pensais pouvoir m'en sortir avec des métriques, mais je vais rajouter des routes avec métriques.
Tu peux mettre le preferred_lft a 0 sur l'adresse anycast comme elle ne sera jamais sélectionnée pour sortir.
ou alors activer une ipv6 temporaire elle sera toujours choisie pour sortir (en plus cela limite l'exposition de ton serveur).
-
Euh c'est faux, le load balancing fonctionne super bien... quand c'est bien configuré :)
Ce qui n'est pas le cas ici présent oui
-
Tu peux mettre le preferred_lft a 0 sur l'adresse anycast comme elle ne sera jamais sélectionnée pour sortir.
ou alors activer une ipv6 temporaire elle sera toujours choisie pour sortir (en plus cela limite l'exposition de ton serveur).
Merci, rajouter preferred_lft 0 semble parfait pour mon pb.
C'est très pratique aussi quand on a une IPv6 dédié à l'administration, afin d'éviter que le serveur l'utilise en sortie.
Je pense mettre preferred_lft 0 sur toutes les IPv6, hors de celle qui doit être utilisée en sortie.
Avec ip -6 addr, le mot deprecated + un ttl de 0 seconde est rajouté sur les IPv6 avec preferred_lft 0
# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
4: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2001:a:a:1001::2/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:a:a:1101:a:a:a:a/64 scope global deprecated
valid_lft forever preferred_lft 0sec
inet6 2001:a:a:1101::4/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:a:a:1101::3/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:a:a:1101::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::3efd:feff:fe1d:7660/64 scope link
valid_lft forever preferred_lft forever
Un peu de doc en anglais : IPv6 Source Address Selection on Linux (http://www.davidc.net/networking/ipv6-source-address-selection-linux)