☰

SLAAC 在内核为 5.15.0-56-generic 的 Jammy 中突然启用 #62-Ubuntu

tag-icon • tag-icon networking ipv6
SLAAC 在内核为 5.15.0-56-generic 的 Jammy 中突然启用 #62-Ubuntu

昨晚，我的基于 Ubuntu 的 VPS 自行更新Linux smtp 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux，从那时起，SLAAC 似乎无条件启用。

由于一些奇怪的原因，提供商决定使用静态 IPv6 配置，并使用以下方式设置 VPS：

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

据我了解，这应该禁用 SLAAC 地址。

但是，自从最近更新以来，我确实在net0界面上看到了 SLAAC 地址。这本身不是问题，但它会以某种方式破坏部分（但不是全部）来源的 IPv6 连接。

在我的日志文件中，我可以在重启之前看到与 smtp 服务的成功 IPv6 连接，但之后却看不到。

我尝试手动删除这些地址，但一段时间后它们又会重新出现。

rhialto@smtp:/var/log$ 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: net0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:26:48 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    altname ens3
    inet xxx.xxx.xxx.129/24 brd xxx.xxx.xxx.255 scope global dynamic net0
       valid_lft 60541sec preferred_lft 60541sec
    inet6 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:2648/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591895sec preferred_lft 604695sec
    inet6 2a02:xxxx:xxxx:xxxx:yyyy:xxxx:xxxx:2648/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591895sec preferred_lft 604695sec
    inet6 2a02:zzzz:zzzz:zzzz::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:2648/64 scope link 
       valid_lft forever preferred_lft forever

所需地址位于底部附近：2a02：zzzz：zzzz：zzzz::1/64

这也会导致 traceroute6 等工具选择错误的源地址，并且传出的 IPv6 连接使用错误的源地址：

rhialto@smtp:$ ip -6 route get 2a00:1450:400e:810::2004
2a00:1450:400e:810::2004 from :: via fe80::wwww:wwww:wwww:f03d dev net0 proto ra src 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:2648 metric 1024 pref high

Ubuntu 用户是否已经意识到了这个问题？什么时候修复？

补充：当我重新启动回以前的版本时，一切又恢复正常了，但只持续了几分钟。就是这样Linux smtp 5.15.0-53-generic #59-Ubuntu SMP Mon Oct 17 18:53:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux。然后 SLAAC 地址又回来了。所以也许问题存在的时间比我想象的要长。

答案1

我想我可以回答我自己的问题。罪魁祸首是 netplan 及其同伙 system-networkd。某个非常聪明的人决定，他们显然应该完全忽略 sysctl 设置accept_ra=0，autoconf=0尽管我发现的几乎所有文档都声称这些 sysctl 就是为此目的而存在的。

相反，他们有自己的、不同的设置方式accept_ra=0，甚至没有设置方式autoconf=0。

这使得 netplan 成为一种令人讨厌的抽象，其功能比 systemd-networkd 少。而后者又是一种令人讨厌的抽象，其功能比 ifconfig 和 route 少。无论处理什么，它都/etc/network/interfaces.d/net0.cfg运行良好，但显然已被抛弃。该文件很好地描述了有效的配置，但似乎 Ubuntu 不再使用它了。

所以我通过添加一个文件解决了这个问题/etc/netplan/60-static.yaml，该文件将配置添加到50-cloud-init.yamlcloud-init 生成的文件中。有帮助的是，在创建和测试此文件时，netplan-get接受了我之前的尝试，尽管netplan-try完全不同意，但坚决拒绝了它们。非常有帮助。

你能看出我是这些包装的超级粉丝吗？

network:
    version: 2
    ethernets:
        net0:
            addresses:
            - "2a02:..../64"
            routes:
                - to: ::/0
                  via: "2a02:..."
                  on-link: true
            accept-ra: false

相关内容