it-swarm.com.de

IPv6-Standardroute geht nach 30 Minuten verloren

Ich habe ein Ubuntu 16.04 (Kernel 4.7.3) -System, das seine IPv6-Standardroute verliert, nachdem die erste empfangene RA abgelaufen ist (30 Minuten).

So sah die Routing-Tabelle beim Systemstart aus:

# 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 Minuten später sah ich Folgendes:

# 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

Und ein paar Sekunden später sah ich Folgendes:

# 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 zeigt an, dass das System RAs empfängt:

#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

Da tcpdump die RAs erkennt, ging ich davon aus, dass die Firewall die RAs löschen muss (ich verwende UFW, um iptables zu verwalten).

Also habe ich ufw deaktiviert und gewartet, bis ich eine andere RA in tcpdump gesehen habe. Immer noch keine Standardroute.

Was ist los? Vermisse ich etwas Einfaches?

Bearbeiten:

Nach weiteren Eingriffen in das System ... Es sieht so aus, als ob der Netzwerkdienst beim Start nicht gestartet werden kann.

# 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.

Nun ... Was mich daran interessiert, ist, wenn ich das mache:

# ifdown --force ens192 && ifup ens192
RTNETLINK answers: No such process
RTNETLINK answers: Cannot assign requested address
Waiting for DAD... Done
[email protected]:~# 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

Ich kann den Netzwerkdienst auch erfolgreich starten und stoppen, nachdem ich ifdown --force ausgeführt habe.

Wie Sie sehen, übernimmt es jetzt die Konfiguration aus meiner/etc/network/interfaces-Datei, die so aussieht:

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

Mit dieser Konfiguration erwarte ich genau das, was mir die obige Routing-Tabelle gibt. Diese Konfiguration ist unverändert geblieben, seitdem ich die Frage gestellt habe. Wenn ich neu starte, schlägt der Dienst erneut fehl und es wird wieder eine automatisch konfigurierte Adresse plus meine konfigurierte Adresse plus nur die von RA angekündigte Route verwendet (für 30 Minuten).

Also ... Es ist immer noch kaputt und Dienste, deren Start vom Netzwerkdienst abhängt, schlagen auch beim Start fehl.

5
dodexahedron

Ok, es ist nicht wirklich die ideale Lösung, da ich eine vollständig statische Konfiguration wollte, aber ich habe jetzt eine funktionierende Konfiguration.

Ich habe die Gateway-Leitung aus meiner /etc/network/interfaces -Datei entfernt und neu gestartet. Dadurch konnte der Netzwerkdienst beim Start gestartet werden, und ich hatte eine Standardroute, die über den RA-Mechanismus konfiguriert wurde. Der Unterschied besteht nun darin, dass die Route tatsächlich alle 30 Sekunden aktualisiert wird, wenn mein Router eine RA sendet, wohingegen zuvor mit der in dieser Datei angegebenen Gateway-Leitung die RA-Route nie aktualisiert wurde und schließlich eine Zeitüberschreitung auftrat.

Ehrlich gesagt fühlt sich das für mich wie ein Käfer an, es sei denn, ich vermisse etwas Grundlegendes ...

1
dodexahedron