☰

18.04 服务器在辅助网络接口上无法访问

tag-icon • tag-icon netplan systemd-networkd
18.04 服务器在辅助网络接口上无法访问

自从上次接触 Linux（Red Hat）以来已经过去了 17 年，现在我又回来在 Ubuntu 18.04 服务器上工作了。我明白了充足已经发生了变化，包括基础的 init 系统systemd，这似乎在社区中引起了一些争议和分歧。

我了解到网络接口配置现在由一个名为网络计划，其中我已经能够编辑/etc/netplan/50-cloud-init.yaml文件来保留接口设置，例如下面我的简单虚拟机：

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled} network:
    ethernets:
        eth0:
            addresses:
            - 192.168.0.21/24
            gateway4: 192.168.0.1
            nameservers:
                addresses:
                - 165.21.100.88
                - 165.21.83.88
        eth1:
             addresses:
             - 192.168.7.11/24
    version: 2

然而，该文件的注释让我感到困惑；它声称此设置取自其他“数据源”——在哪里？但当我读到https://netplan.io/design表明这是网络配置的权威来源。

据我所知，这些将被交给“网络渲染器”，我猜这意味着将 netplan 的配置格式渲染成另一种文本格式systemd-networkd(8)（与systemd.网络(5)？不确定 8 vs 5 是什么意思。）或网络管理器来处理实际的运行时设备/网络配置，而不是 Google 建议的更传统意义上的分布式图像/3D 渲染。

无论如何，在实际生产服务器的环境中，它们可以配置一到三个辅助以太网接口，每个接口都有自己的子网。简单的例子：

network:
    ethernets:
        eth0:
            addresses:
            - 10.0.1.100/24
            gateway4: 10.0.1.1
            nameservers:
                addresses:
                - 8.8.8.8
                - 8.8.4.4
        eth1:
            addresses:
            - 10.0.2.100/24
            nameservers:
                addresses:
                - 8.8.8.8
                - 8.8.4.4
    version: 2

从我们的控制网络（例如 10.0.0.0/24）出发，我们可以路由到 10.0.1.0/24 和 10.0.2.0/24。但是上面的服务器实际上只能在 eth0 10.0.1.100 上进行连接（无论是 HTTP 还是 ICMP ping）。到 10.0.2.100 的流量永远不会连接。

https://brainscraps.fandom.com/wiki/Setup_Gateway_Routing_On_Multiple_Network_Interfaces解释说这是因为如果接收方目的地是 10.0.2.100 (eth1)，Linux 本身不知道如何路由回复。它（每个额外的接口）需要自己的路由表才能通过其正确的网关 10.0.2.1 进行响应，就像 eth0 的 10.0.1.1 一样。但是，该页面涉及 netplan 已取代的传统网络配置样式。此外，我读到 netplan 不支持 rt2 表？（iproute2？）

对于 netplan 来说，正确的做法应该是怎样的？ 是否只要提供自己的网关4 就够简单了？

        eth1:
            addresses:
            - 10.0.2.100/24
            gateway4: 10.0.2.1

或者它是否需要更多类似于 iproute2 的配置？我不确定如何在实际服务器上进行测试（无法在我自己的虚拟机上进行测试，因为我的笔记本电脑中没有相同的多网络硬件和环境。）因为担心配置错误后会失去与它的连接（SSH）。

9 月 17 日更新：今天我们讨论并继续直接修改服务器的 50-cloud-init.yaml 配置以包含 eth1 的上述额外网关，但服务器仍然无法从该接口路由出响应。

9 月 17 日晚上更新：尝试使用显式路由代替网关 4

        eth0:
            addresses:
            - 10.0.2.100/24
#            gateway4: 10.0.2.1
            routes:
            - to: 0.0.0.0/0
              via: 10.0.2.1
              metric: 100

但仍然无法路由。从 tcpdump 中我可以看到 ICMP ping 进来（来自我的笔记本电脑），但没有传出回复。

答案1

好的，看起来与原始旧文章一样，这些额外的路由确实需要定义为单独的路由表，并结合明确的路由策略指令来“强制”操作系统使用这些额外的表将流量路由到/从接口 IP 地址。

network:
    ethernets:
        eth0:
            addresses:
            - 10.0.1.100/24
            gateway4: 10.0.1.1
            nameservers:
                addresses:
                - 8.8.8.8
                - 8.8.4.4
        eth1:
            addresses:
            - 10.0.2.100/24
# Simply defining gateway for secondary interface is not good enough.
#            gateway4: 10.0.2.1

# Needs a separate route table with a to-ANY route that specifies its default gateway.
# Metric doesn't matter since it's not supposed to compete with primary interface.
            routes:
            - to: 0.0.0.0/0
              via: 10.0.2.1
              metric: 100
              table: 100

# Declare the cases when the other route table is to be used.
# Whenever the dest = interface IP address
# Whenever the src = interface IP address
            routing-policy:
            - to: 10.0.2.100/24
              table: 100
            - from: 10.0.2.100/24
              table: 100
            nameservers:
                addresses:
                - 8.8.8.8
                - 8.8.4.4
    version: 2

现在可以联系第二个网络接口和 IP 地址。

相关内容