web-dev-qa-db-fra.com

Route par défaut IPv6 perdue après 30 minutes

J'ai un système Ubuntu 16.04 (noyau 4.7.3) qui perd son itinéraire IPv6 par défaut après l'expiration du premier RA reçu (30 minutes).

Voici à quoi ressemblait la table de routage au démarrage du système:

# ip -6 route
2001:xxxx:xxxx:xxxx::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium
fe80::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium
default via fe80::ce46:d6ff:feb0:f6b1 dev ens192  proto ra  metric 1024  expires 1747sec mtu 1480 hoplimit 64 pref high

30 minutes plus tard, j'ai vu ceci:

# ip -6 route
2001:xxxx:xxxx:xxxx::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium
fe80::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium
default via fe80::ce46:d6ff:feb0:f6b1 dev ens192  proto ra  metric 1024  expires -8sec mtu 1480 hoplimit 64 pref high

Et puis, quelques secondes après, j'ai vu ceci:

# ip -6 route
2001:xxxx:xxxx:xxxx::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium
fe80::/64 dev ens192  proto kernel  metric 256  mtu 1480 pref medium

tcpdump indique que le système reçoit des RA:

#tcpdump -vv ip6
tcpdump: listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
15:34:21.842483 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 96) fe80::ce46:d6ff:feb0:f6b1 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 96
        hop limit 64, Flags [none], pref high, router lifetime 1800s, reachable time 0s, retrans time 0s
          source link-address option (1), length 8 (1): cc:46:d6:b0:f6:b1
            0x0000:  cc46 d6b0 f6b1
          advertisement interval option (7), length 8 (1):  30000ms
            0x0000:  0000 0000 7530
          mtu option (5), length 8 (1):  1480
            0x0000:  0000 0000 05c8
          rdnss option (25), length 24 (3):  lifetime 60s, addr: ordns.he.net
            0x0000:  8075 0000 003c 2001 0470 0020 0000 0000
            0x0010:  0000 0000 0002
          prefix info option (3), length 32 (4): 2001:xxxx:xxxx:xxxx::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s
            0x0000:  40c0 0027 8d00 0009 3a80 0000 0000 2001
            0x0010:  XXXX XXXX XXXX 0000 0000 0000 0000

J'ai donc supposé que, puisque tcpdump voit les RA, le pare-feu doit laisser tomber les RA (j'utilise UFW pour gérer iptables).

J'ai donc désactivé ufw et attendu jusqu'à ce que je voie une autre PR dans tcpdump. Toujours pas de route par défaut.

Que se passe-t-il? Est-ce que je manque quelque chose de simple?

Modifier:

Après avoir creusé davantage dans le système ... Il semble que le service réseau ne démarre pas au démarrage.

# systemctl status networking
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/networking.service.d
           └─50-insserv.conf-$network.conf
   Active: failed (Result: exit-code) since Sun 2016-09-11 16:47:36 MST; 1min 39s ago
     Docs: man:interfaces(5)
  Process: 5650 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 5599 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle (cod=exited, status=0/SUCCESS)
 Main PID: 5650 (code=exited, status=1/FAILURE)

Sep 11 16:47:31 asdf systemd[1]: Starting Raise network interfaces...
Sep 11 16:47:33 asdf ifup[5650]: /sbin/ifup: waiting for lock on /run/network/ifstate.ens192
Sep 11 16:47:35 asdf ifup[5650]: RTNETLINK answers: File exists
Sep 11 16:47:35 asdf ifup[5650]: Failed to bring up ens192.
Sep 11 16:47:36 asdf systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Sep 11 16:47:36 asdf systemd[1]: Failed to start Raise network interfaces.
Sep 11 16:47:36 asdf systemd[1]: networking.service: Unit entered failed state.
Sep 11 16:47:36 asdf systemd[1]: networking.service: Failed with result 'exit-code'.

# journalctl -xe

Sep 11 16:47:35 asdf sh[5593]: RTNETLINK answers: File exists
Sep 11 16:47:35 asdf sh[5593]: Failed to bring up ens192.
Sep 11 16:47:35 asdf systemd[1]: [email protected]: Main process exited, code=exited, status=1/FAILURE
Sep 11 16:47:35 asdf ifup[5650]: RTNETLINK answers: File exists
Sep 11 16:47:35 asdf ifup[5650]: Failed to bring up ens192.
Sep 11 16:47:36 asdf systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Sep 11 16:47:36 asdf systemd[1]: Failed to start Raise network interfaces.

Maintenant ... Ce qui est intéressant pour moi, c’est que si je fais ceci:

# ifdown --force ens192 && ifup ens192
RTNETLINK answers: No such process
RTNETLINK answers: Cannot assign requested address
Waiting for DAD... Done
root@az-unixweb-1:~# ip -6 route
2001:xxxx:xxxx:xxxx::/64 dev ens192  proto kernel  metric 256  pref medium
fe80::/64 dev ens192  proto kernel  metric 256  mtu 1500 pref medium
default via 2001:xxxx:xxxx:xxxx::1 dev ens192  metric 1024  pref medium

Je peux également démarrer et arrêter le service de réseau avec succès après avoir exécuté ifforce --force.

Comme vous pouvez le constater, il prend maintenant la configuration de mon fichier/etc/network/interfaces, qui ressemble à ceci:

auto lo
iface lo inet loopback
iface ens192 inet static
        address a.b.c.d
        netmask 255.255.255.224
        gateway a.b.c.r
        dns-nameserver a.b.c.dns
iface ens192 inet6 static
        address 2001:xxxx:xxxx:xxxx::44
        netmask 64
        gateway 2001:xxxx:xxxx:xxxx::1
        dns-nameserver 2001:xxxx:xxxx:xxxx::42
        dns-nameserver 2001:470:20::2
auto ens192

Avec cette configuration, j'attends exactement ce que me donne la table de routage ci-dessus. Cette configuration est restée inchangée depuis que j'ai initialement posé la question. Si je redémarre, le service échoue à nouveau et il recommence à utiliser une adresse configurée automatiquement, ainsi que l'adresse configurée, ainsi que l'utilisation de l'itinéraire annoncé par l'autorité responsable (pendant 30 minutes).

Donc ... Il est toujours défectueux et les services qui dépendent du service de réseau pour démarrer échouent également au démarrage.

networkingfirewallipv6
5
dodexahedron

Ok, ce n’est pas vraiment la solution idéale, car je voulais une configuration totalement statique, mais j’ai une configuration fonctionnelle, maintenant.

J'ai enlevé la ligne de passerelle de mon fichier /etc/network/interfaces et l'ai redémarré. Cela a permis au service réseau de démarrer au démarrage et m'a permis de configurer un itinéraire par défaut via le mécanisme de l'autorité d'enregistrement. La différence maintenant est que la route est actuellement actualisée toutes les 30 secondes, lorsque mon routeur envoie un RA, alors qu'avant, avec la ligne de passerelle spécifiée dans ce fichier, la route du RA n'était jamais rafraîchie et finalement expirée.

Honnêtement, cela ressemble à un bug pour moi, à moins que je ne manque quelque chose de fondamental ...

1
dodexahedron