[Wheezy] Deux ip de réseaux différents une interface

Gring · Février 21, 2016, 2:38pm

Bonjour !

J’ai posé cette question sur les forums anglophones, mais je n’ai aucune réponse, pourtant ça devrait concerner beaucoup de monde…

Comment faire pour ajouter une adresse ip d’un réseau différent sur une même interface ?

Sur l’ancienne machine (ubuntu 9), j’avais la configuration suivante dans /etc/network/interfaces (j’ai changé les ip)

[code]auto eth0
iface eth0 inet static
address 95.125.209.64
netmask 255.255.255.0
network 95.125.209.0
broadcast 95.125.209.255
gateway 95.125.209.254

auto eth0:0
iface eth0:0 inet static
…

auto eth0:1
iface eth0:1 inet static
address 84.96.133.38
netmask 255.255.255.0
network 84.96.133.0
broadcast 84.96.133.255
gateway 84.96.133.254[/code]

Seulement, ça ne marche plus sur Wheezy.

[code]root@xxx:/# /etc/init.d/networking stop && /etc/init.d/networking start
[…] Deconfiguring network interfaces…RTNETLINK answers: No such process
done.
[…] Configuring network interfaces…RTNETLINK answers: File exists
Failed to bring up eth0:1.
done.

root@xxx:/# cat /etc/network/run/ifstate
lo=lo
eth0=eth0

root@xxx:/# ifconfig -a
eth0 Link encap:Ethernet HWaddr …

eth0:1 Link encap:Ethernet HWaddr 4c:72:b9:7b:b3:4d
inet addr:84.96.133.38 Bcast:84.96.133.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20 Memory:fe500000-fe520000

lo Link encap:Local Loopback …[/code]

Vous remarquerez qu’ifconfig déclare que l’interface est là, alors qu’elle n’est pas censée exister.

J’ai lu dans diverses documentations qu’il fallait utiliser ip et non plus ifconfig

root@xxx:/# ifdown eth0 && ifup eth0 RTNETLINK answers: No such process
Euh ? C’est normal ça ?

Du coup, la nouvelle configuration devrait ressembler à cela :

auto eth0
allow-hotplug eth0
iface eth0 inet static
        address x.x.x.x
        netmask 255.255.255.0
        network x.x.x.x
        broadcast x.x.x.x
        gateway x.x.x.x
        up ip addr add dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1
        up ip route add 84.96.133.38 proto static scope host dev eth0:1
        #up ip route add 84.96.133.0/24 proto static scope host dev eth0:1 src 84.96.133.38
        #up ip route add 0.0.0.0/0 proto static scope link dev eth0:1 via 84.96.133.254 src 84.96.133.38
        down ip addr del dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1
        down ip route del 84.96.133.38 scope link dev eth0:1
        #down ip route del 84.96.133.0/24 proto kernel scope link dev eth0:1 src 84.96.133.38
        #down ip route del 0.0.0.0/0 proto kernel scope link dev eth0:1 via 84.96.133.254 src 84.96.133.38

Alors, ça marchouille, mais seulement au reboot ( /etc/init.d/networking stop && /etc/init.d/networking start provoque une erreur, qui subsiste quels que soient les changements que l’on fait à /etc/network/interfaces. Est ce un bug ? )

root@xxx:~# /etc/init.d/networking stop && /etc/init.d/networking start
[ ok ] Deconfiguring network interfaces...done.
[....] Configuring network interfaces...RTNETLINK answers: File exists
Failed to bring up eth0.
RTNETLINK answers: File exists
Failed to bring up eth0.
done.

Euh (comment se fait il que je sois encore connecté ?)

Les lignes commentées ne fonctionnent pas, comment ajouter les passerelles pour les ip supplémentaires ? Suis je sur la bonne voie en essayant de créer des routes ?

Gring · Février 21, 2016, 2:38pm

Nouvel essai : auto eth0 allow-hotplug eth0 iface eth0 inet static address x.x.x.x netmask 255.255.255.0 network x.x.x.x broadcast x.x.x.x gateway x.x.x.x up ip addr add dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1 up ip route add 84.96.133.38 proto static scope host dev eth0:1 up ip route add default via 84.96.133.254 dev eth0:1 proto static table 101 up ip rule add from 84.96.133.38 table 101 down ip addr del dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1 down ip route del 84.96.133.38 proto static scope host dev eth0:1 down ip route del default via 84.96.133.254 dev eth0:1 proto static table 101 down ip rule del from 84.96.133.38 table 101

un reboot avec cette configuration semble fonctionner :

root@xxx:~# ip rule show
0:      from all lookup local
32765:  from 84.96.133.38 lookup 101
32766:  from all lookup main
32767:  from all lookup default

root@xxx:~# ip route show table 101
default via 84.96.133.254 dev eth0  proto static

root@xxx:~# ip route show
default via x.x.x.x dev eth0
x.x.x.0/24 dev eth0  proto kernel  scope link  src x.x.x.x
84.96.133.0/24 dev eth0  proto kernel  scope link  src 84.96.133.38
84.96.133.38 dev eth0  proto static  scope host

root@xxx:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr...

eth0:1    Link encap:Ethernet  HWaddr ...
          inet addr:84.968.133.38  Bcast:84.96.133.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:20 Memory:fe500000-fe520000

lo        Link encap:Local Loopback

C’est bon signe
Mais si j’éssaie de router le trafic HTTP vers une machine virtuelle :

iptables -t nat -A PREROUTING -p tcp -i eth0:1 --dport 80 -j DNAT --to 192.168.2.10
=> Ne fonctionne pas, pas de réponse du serveur quand on se connecte avec un navigateur

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 192.168.2.10
=> ça marche, cela signifie que les paquets envoyés à 84.96.133.38 arrivent, mais pas dans l’interface spécifique eth0:1.

Phyliares · Février 21, 2016, 2:38pm

Salut,

Ce comportement est normal puisque /etc/init.d/networking monte les interfaces avec ifup, or eth0:1 n’est pas une interface mais un alias d’interface.

Si si elle est censée exister mais pas en tant qu’interface…

Oui c’est normal tu ne peux pas démonter ton interface qui a un alias, par contre tu peux la déconnecter en lui assignant l’adresse 0.0.0.0

Idem pour supprimer l’alias, ou sans qu’il râle:

[quote]

Du coup, la nouvelle configuration devrait ressembler à cela :

auto eth0
allow-hotplug eth0
iface eth0 inet static
        address x.x.x.x
        netmask 255.255.255.0
        network x.x.x.x
        broadcast x.x.x.x
        gateway x.x.x.x
        up ip addr add dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1
        up ip route add 84.96.133.38 proto static scope host dev eth0:1
        #up ip route add 84.96.133.0/24 proto static scope host dev eth0:1 src 84.96.133.38
        #up ip route add 0.0.0.0/0 proto static scope link dev eth0:1 via 84.96.133.254 src 84.96.133.38
        down ip addr del dev eth0 local 84.96.133.38/24 broadcast 84.96.133.255 label eth0:1
        down ip route del 84.96.133.38 scope link dev eth0:1
        #down ip route del 84.96.133.0/24 proto kernel scope link dev eth0:1 src 84.96.133.38
        #down ip route del 0.0.0.0/0 proto kernel scope link dev eth0:1 via 84.96.133.254 src 84.96.133.38

Alors, ça marchouille, mais seulement au reboot ( /etc/init.d/networking stop && /etc/init.d/networking start provoque une erreur, qui subsiste quels que soient les changements que l’on fait à /etc/network/interfaces. Est ce un bug ? )

root@xxx:~# /etc/init.d/networking stop && /etc/init.d/networking start
[ ok ] Deconfiguring network interfaces...done.
[....] Configuring network interfaces...RTNETLINK answers: File exists
Failed to bring up eth0.
RTNETLINK answers: File exists
Failed to bring up eth0.
done.

Euh (comment se fait il que je sois encore connecté ?)

Les lignes commentées ne fonctionnent pas, comment ajouter les passerelles pour les ip supplémentaires ? Suis je sur la bonne voie en essayant de créer des routes ?[/quote]

C’est trop le bord…

tu ne peux pas mélanger auto et allow-hotplug, ta première config est la bonne mais tu ne peux pas avoir plusieurs passerelles sans utiliser les metriques…
Dans tes routes tu ne doit pas utiliser l’alias mais l’interface.

Toutes ces options me donnent le tournis, et … spécifier le broadcast ne sert a rien
pour ajouter une route:

pour la supprimmer:

Et basta…

Les erreurs que tu as sont liées au fait qu’il ne peux pas utiliser ifupdown sur les alias… rien de bien méchant. Reviens a ta conf initiale

Gring · Février 21, 2016, 2:38pm

Merci pour ton aide, je commençais à devenir fou

Si je comprends bien, on ne peut plus traiter les alias d’interfaces comme des interfaces…

Effectivement, je peux carrément enlever toute référence à la seconde adresse IP, (et à eth0:1), et spécifier l’adresse IP dans iptables comme ceci :

Et ça marche comme je l’espérais pour les connexions entrantes. (J’imagine que ça marche parce que mon hébergeur utilise un autre mécanisme qu’ARP pour des raisons de sécurité).

Par contre si j’essayais de faire des règles de routage, c’était pour pouvoir utiliser des règles SNAT sur les machines virtuelles, pour décider de leur adresse IP en sortie (Par exemple, il vaut mieux que le serveur SMTP ait la même ip en entrée et en sortie pour éviter de se faire cataloguer comme spammeur par certains).

voici mes nouvelles règles :

auto eth0
iface eth0 inet static
        address x.x.x.x
        netmask 255.255.255.0
        network x.x.x.x
        broadcast x.x.x.x
        gateway x.x.x.x metric 1
        post-up ip addr add dev eth0 84.96.133.38/24
        post-up ip route add default via 84.96.133.254 dev eth0 proto static metric 2 src 84.96.133.38
        pre-down ip addr del dev eth0 84.96.133.38/24
        pre-down ip route del default via 84.96.133.254 dev eth0 proto static metric 2 src 84.96.133.38

Mais le SNAT ne marche pas, les machines virtuelles prennent systématiquement la passerelle avec la métrique la plus faible.
Les outils XEN ont automatiquement mis en place du masquerading, je vais essayer de déterminer si celui ci est prioritaire par rapport au SNAT.

Sinon, sur l’ancienne machine, il y a deux passerelles avec des métriques égales.

root@ancienne_machine:~# ip route show <réseau ip principale>/24 dev eth0 proto kernel scope link src <ip principale> <réseau ip secondaire>/24 dev eth0 proto kernel scope link src <ip secondaire> default via <passerelle secondaire> dev eth0 src <ip secondaire> metric 100 default via <passerelle principale> dev eth0 metric 100

Edit : Le SNAT avait une priorité inférieure au MASQUERADING créé automatiquement par xen tools.

Pour que ça marche, il faut utiliser -I (insert) plutôt que -A (append)

En tous cas, merci

mazarini · Février 21, 2016, 2:38pm

Bonjour,

Je suis en train de galérer avec xen.

j’ai mis eth0 en manuel sans montage auto et sans caractéristiques
j’ai ajouter

une interface dummy0 en manuel sans montage auto
une interface xenbr0 qui reprend les caractéristiques d’avant de eth0 et bridgée eth0
une interface xenbr1 avec une définition de réseau local et bridgée dummy0

Pour les machines sans IP public :
le masquerade se fait sur xenbr0 et pas sur le eth0
il faut que le firewall accepte le FORWARD

Pour mes config de machines vituelles ( :
vif = [
‘vifname=wan1.0,ip=IP sup,mac=02:100:00:d1:c7:29,bridge=xenbr0’,
‘vifname=lan1.1,ip=192.168.201.1,mac=00:16:3E:CA:49:4D,bridge=xenbr1’
]

Dans le fichier interfaces des VM, je paramètre

eth0 avec l’ip sup (adresse et broadcast) et la gateway de la domU
eth1 avec 192.168.201.1 et ce qui va avec

Ca marche bien pour le moment, mais je dois jongler avec les fichiers de config xen des vm et (ligne “vif=…”) avec le fichier interface des vm (échanger/supprimer eth0 et eth1) manuellement .

Je dois encore affiner mais ca marche pas mal, j’espère que ca peut t’aider.

Un détail, je fais ca chez OVH et il faut utiliser une adresse mac virtuel fournie par OVH.