Маршрут по умолчанию IPv6 потерян через 30 минут

У меня есть система Ubuntu 16.04 (ядро 4.7.3), которая теряет свой маршрут по умолчанию IPv6 после истечения первого полученного RA (30 минут).

Вот как выглядела таблица маршрутизации при загрузке системы:

# 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 минут спустя я увидел это:

# 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

И затем, через несколько секунд, я увидел это:

# 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 показывает, что система получает 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

Поэтому я предположил, что, поскольку tcpdump видит RA, брандмауэр должен сбрасывать RA (я использую UFW для управления iptables).

Так что я отключил UFW и ждал, пока я не увидел еще один RA в tcpdump. Все еще нет маршрута по умолчанию.

В чем дело? Я скучаю по чему-то простому?

Редактировать:

После еще большего погружения в систему... Похоже, что сетевой сервис не запускается при загрузке.

# 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]: ifup@ens192.service: 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.

Теперь... Что мне интересно в этом, если я сделаю это:

# 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

Я также могу успешно запускать и останавливать сетевой сервис после выполнения команды ifdown --force.

Как вы можете видеть, теперь он берет конфигурацию из моего файла /etc/network/interfaces, который выглядит следующим образом:

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

С этой конфигурацией я ожидаю именно то, что дает мне приведенная выше таблица маршрутизации. Эта конфигурация осталась неизменной, так как я изначально задал вопрос. Если я перезагружаюсь, служба снова перестает работать, и она возвращается к использованию автоматически настроенного адреса плюс мой настроенный адрес плюс только использование объявленного RA маршрута (в течение 30 минут).

Итак... Он все еще не работает, и службы, которые зависят от запуска сетевого сервиса, также не работают при запуске.

1 ответ

Решение

Хорошо, это не совсем идеальное решение, так как я хотел полностью статическую конфигурацию, но сейчас у меня есть рабочая конфигурация.

Я удалил линию шлюза из моего /etc/network/interfaces файл и перезагрузил. Это позволило запустить сетевой сервис при загрузке и привело к тому, что я настроил маршрут по умолчанию, настроенный с помощью механизма RA. Разница теперь в том, что маршрут фактически обновляется каждые 30 секунд, когда мой маршрутизатор отправляет RA, тогда как раньше, когда в этом файле была указана линия шлюза, маршрут RA никогда не обновлялся и в итоге не превышался.

Честно говоря, для меня это похоже на ошибку, если я не пропущу что-то фундаментальное...

Другие вопросы по тегам