Réseau : problème de conf réseau debian 10

Support Debian
, ,
Tags: #<Tag:0x00007f63f5fa9fa0> #<Tag:0x00007f63f5fa9e60> #<Tag:0x00007f63f5fa9d48>
#1

Bonjour,

je cherche à mettre à jour ma structure vers les nouvelles versions proxmox/debian et refais donc des installations propres.
Je suis confronté à des difficultés sur la configuration réseau.
Ma structure : un serveur proxmox sur lequel tourne des VM debian 10
A chaque démarrage de ma VM, j’ai un message
FAILED TO START Raise network interfaces
Je termine le boot et me logue.
Je ping tout de même internet, en ipv4 et ipv6.
L’exécution de la commande systemctl status networking.service donne

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-07-21 13:55:04 CEST; 8min ago
     Docs: man:interfaces(5)
  Process: 380 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 380 (code=exited, status=1/FAILURE)

Jul 21 13:55:02 web2 systemd[1]: Starting Raise network interfaces...
Jul 21 13:55:04 web2 ifup[380]: Waiting for DAD... Done
Jul 21 13:55:04 web2 ifup[380]: RTNETLINK answers: File exists
Jul 21 13:55:04 web2 ifup[380]: ifup: failed to bring up ens18
Jul 21 13:55:04 web2 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Jul 21 13:55:04 web2 systemd[1]: networking.service: Failed with result exit-code.
Jul 21 13:55:04 web2 systemd[1]: Failed to start Raise network interfaces.

Mon fichier interfaces est le suivant :

# 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 ens18
iface lo inet loopback
iface ens18 inet static
    address ABC.DE.EFG.HI
    netmask 255.255.255.255
    broadcast ABC.DE.EFG.HI
#    pre-up iptables-restore < /etc/iptables.rules
    post-up ip route add XYZ.XFYZ.XYZ.254 dev ens18
    post-up ip route add default via XYZ.XFYZ.XYZ.254
    pre-down ip route del XYZ.XFYZ.XYZ.254 dev ens18
    pre-down ip route del default via XYZ.XFYZ.XYZ.254
iface ens18 inet6 static
    address JFHZ:GFRE:FREZ::4
    netmask 64
#    pre-up ip6tables-restore < /etc/ip6tables.rules
    post-up ip -f inet6 route add JFHZ:GFRE:FRff:ff:ff:ff:ff dev ens18
    post-up ip -f inet6 route add default via JFHZ:GFRE:FRff:ff:ff:ff:ff
    pre-down ip -f inet6 route add JFHZ:GFRE:FRff:ff:ff:ff:ff dev ens18
    pre-down ip -f inet6 route add default via JFHZ:GFRE:FRff:ff:ff:ff:ff

Je ne parviens pas à comprendre ce qui plante. J’ai déjà remarqué que ma ligne pre-up ip6tables-restore < /etc/ip6tables.rules ne lui plaisait pas, c’est pourquoi je l’ai mis en commentaire, mais pour le reste…
Merci par avance !
Neibaf

#2

« RTNETLINK answers: File exists » peut signifier qu’une commande essaie d’ajouter une adresse ou une route en doublon. Pour voir laquelle tu peux exécuter ifup avec l’option -v (verbose).

ifdown --force ens18
ifup -v ens18
#3

Bonjour,

merci de ce retour, cela dit j’ai l’impression que mes difficultés sont plus profondes.
J’ai redémarré la VM sans faire aucune modification et je n’avais plus le problème. Par contre, au bout d’un certain temps, je ne sais pas pourquoi, plus de connexion en ipv6, mais l’ipv4 fonctionnait encore.
J’ai redémarré, et là ok depuis hier après midi. Là je me remets en ssh et me rends compte qu’iptables est « à poil » en ipv4 comme en ipv6 alors que je n’ai pas fait de reboot de la machine.
De plus, quand j’essaie de lancer mon script pour ipv6 avec ip6tables-restore < monfichier il me sort
ip6tables-restore v1.8.2 (nf_tables): host/network IPV6' not found Error occurred at line: 54 Try ip6tables-restore -h’ or ‹ ip6tables-restore --help › for more information.
alors que je suis connecté en ssh via ipv6 et que je ping google en ipv6
Si vous avez des idées, je suis preneur…
Merci !

#4

Bon… je me réponds, une bête erreur dans mon script ip6, mais je ne comprends pas le reste… advienne que pourra !

#5

Quel reste ?

#6

Bonjour,

donc, j’ai fait le ifdown --force ens18, il n’est pas content:
Error: Nexthop device is not up.
RTNETLINK answers: No route to host
RTNETLINK answers: cannot assign requested address

Ensuite je fais le ifup -v ens18 et là ça donne (je copie une image car je ne peux pas le faire en ssh)
image
Il est question des contenus des dossiers if-up., if-pre-up.d, mais ils sont vides.
Merci !

#7

Je ne vois aucune erreur dans l’exécution d’ifup.
Concernant les erreurs d’ifdown, il aurait fallu l’exécuter avec l’option -v pour afficher les détails.

#8

Quand il indique, à la dernière ligne par exemple,
/bin.run-parts --exit-on-error --verbose /etc/networl/if-up.d
ça ne veut pas dire qu’il y a eu une erreur ?
J’ai refait un ifdown et un ifup avec l’option -v et voilà ce que ça donne (toujours en image, désolé)
image
et pour le ifup (le résultat n’est d’ailleurs pas le même que précédemment…)
image
Merci pour toute cette aide !

#9

Dans la partie IPv6 de ta configuration réseau pour pre-down tu ajoutes la route (add) au lieu de la supprimer (del). C’est ce qui provoque une erreur lorsque tu désactives l’interface.

#10

Non. --exit-on-error est une option de la commande exécutée (« en cas d’erreur, arrêter »), pas un résultat. C’est comme l’option de montage errors=remount-ro (« en cas d’erreur, remonter en lecture seule ») pour la racine dans le fichier /etc/fstab.

En effet. D’ailleurs il est inutile d’effacer explicitement les routes, elles le sont déjà implicitement lorsque l’interface est désactivée.

Oui, apparemment une route IPv6 par défaut existerait déjà. Tu peux vérifier avec

ip -6 route
#11

Il faut regarder si les retours de ces commandes correspondent à ta configuration réseau :

ip a
ip route
ip -6 route

Il faut vérifier comment est géré le réseau :

systemctl status networking
systemctl status systemd-networkd

et éventuellement :

systemctl status networkmanager
#12

Merci à tous les 2 de votre aide, ça me permet vraiment de bien avancer (et d’apprendre/comprendre des choses en plus).
Pour le add au lieu du del, désolé, vraiment une erreur bête.
J’ai fait l’ensemble des commandes indiquées par Bruno1, voici les résultats :
ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether MAC_ADRESSE brd ff:ff:ff:ff:ff:ff
    inet XXX.XXX.XXX.51/32 brd XXX.XXX.XXX.51 scope global ens18
       valid_lft forever preferred_lft forever
    inet6 1234:5678:1234:5678::4/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::ff:fee8:289e/64 scope link
       valid_lft forever preferred_lft forever

ip route

default via XXX.XXX.XXX.254 dev ens18
XXX.XXX.XXX.254 dev ens18 scope link

ip -6 route

::1 dev lo proto kernel metric 256 pref medium
1234:5678:1234:5678::/64 dev ens18 proto kernel metric 256 pref medium
1234:5678:1234:56ff:ff:ff:ff:ff dev ens18 metric 1024 pref medium
1234:5678:1234:5600::/56 dev ens18 proto kernel metric 256 expires 2591967sec pref medium
fe80::/64 dev ens18 proto kernel metric 256 pref medium
default via 1234:5678:1234:56ff:ff:ff:ff:ff dev ens18 metric 1024 pref medium
default via fe80::205:73ff:fea0:1 dev ens18 proto ra metric 1024 expires 1767sec hoplimit 64 pref medium

systemctl status networking -> si j’interprète bien, ça va plutôt bien

● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor prese
   Active: active (exited) since Fri 2020-07-24 16:23:18 CEST; 10min ago
     Docs: man:interfaces(5)
  Process: 520 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0
 Main PID: 520 (code=exited, status=0/SUCCESS)
Jul 24 16:23:17 web2 systemd[1]: Starting Raise network interfaces...
Jul 24 16:23:18 web2 ifup[520]: Waiting for DAD... Done
Jul 24 16:23:18 web2 systemd[1]: Started Raise network interfaces.

systemctl status systemd-networkd-> si j’interprète bien, ça va plutôt bien

● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-networkd.service(8)

systemctl status networkmanager
Unit networkmanager.service could not be found.

Voilà voilà.
Je ne comprends pas bien le résultat de ip -6 route qui me parait bien compliqué… En particulier, je me demande d’où vient la ligne
1234:5678:1234:5600::/56 dev ens18 proto kernel metric 256 expires 2591967sec pref medium
Autant l’adresse 1234:5678:1234:56ff:ff:ff:ff:ff sur la ligne juste au-dessus, ok (j’ai suivi la doc OVH), mais cette adresse en 00::/56 ?

#13

Ainsi que la seconde route par défaut :

Je dirais que ces routes ont été ajoutées par l’auto-configuration sans état à partir d’une annonce de routeur IPv6 (RA) diffusée sur le réseau. On voit dans les captures d’écran que le paramètre autoconf est mis à 0 sur l’interface mais celui-ci ne désactive que l’autoconfiguration des adresses et non des routes. Pour ignorer totalement les annonces de routeur il faut ajouter l’option accept_ra=0 dans le bloc de configuration IPv6 de l’interface dans le fichier /etc/network/interfaces.

#14

Je viens de le faire, j’ai redémarré la VM et il n’a pas du tout aimé :frowning:
L’interface ne démarrait plus du tout, que ce soit en ip4 ou ip6, j’ai retiré la ligne.
La doc OVH indique :

Par mesure de précaution, nous suggérons fortement à nos clients de désactiver l’autoconf IPv6 et l’annonce de routage afin d’éviter tout dysfonctionnement. Vous pouvez le faire en ajoutant les lignes suivantes à votre fichier sysctl.conf:

bash net.ipv6.conf.eth0.autoconf=0 net.ipv6.conf.eth0.accept_ra=0

Une fois complété, vous pouvez appliquer ces règles en éxécutant la commande suivante: sh sysctl -p
Actuellement, dans mon fichier /etc/sysctl.conf, il n’y a rien d’activé (tout est en commentaire).
Je n’ai pas suivi cette instruction d’OVH car je trouve bizarre que ce fichier de conf contienne une ligne commençant par bash. De plus, toutes les autres lignes (en commentaire donc) sont sans le bash.
Cela signifie-t-il que je doive rajouter

net.ipv6.conf.eth0.autoconf=0
net.ipv6.conf.eth0.accept_ra=0

au bas de mon fichier ?
Merci.

#15

Ma faute, ça devrait plutôt être

accept_ra 0

C’est n’importe quoi. Syntaxe délirante.

Premier problème : il faut remplacer « eth0 » par le véritable nom de l’interface, ici « ens18 ».
Deuxième problème de cette méthode : il n’est pas garanti que l’interface existe déjà quand ce fichier est appliqué, et si l’interface n’existe pas encore le réglage ne sera pas appliqué.

Notes :
La méthode « static » implique déjà autoconf=0.
accept_ra=0 implique aussi autoconf=0.

#16

OK, ça marche, merci beaucoup pour le dépannage.
Maintenant je vais tacher d’avance sur le serveur de mail… La dernière fois que j’ai fait ça, c’était il y a 8 ans, toutes mes notes sont à remettre au goût du jour, je rame !
Merci !