18.04 сервер недоступен на вторичных сетевых интерфейсах

Спустя семнадцать лет с момента последнего прикосновения к Linux (Red Hat) я вернулся к работе на серверах Ubuntu 18.04. Я вижу множество изменилось, в том числе основополагающая система инициализации systemd , которая, казалось, вызвала некоторые противоречия и разногласия среди сообщества.

Я узнал, что настройка сетевого интерфейса теперь выполняется программой netplan , из которой я смог отредактировать /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.network (5) ? Вы не уверены, что 8 или 5 означает либо.), либо NetworkManager для обработки фактической конфигурации устройства / сети во время выполнения, а не более традиционного значения распределенного изображения / 3D рендеринг, который предлагает Google.

В любом случае, в контексте реальных производственных серверов они могут быть сконфигурированы с одним-тремя дополнительными интерфейсами Ethernet, каждый со своей собственной подсетью. Простой пример:

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. Однако вышеупомянутый сервер действительно может быть доступен только для связи (будь то HTTP или пинг ICMP) на eth0 10.0.1.100. Трафик к 10.0.2.100 никогда не подключается.

https://brainscraps.fandom.com/wiki/Setup_Gateway_Routing_On_Multiple_Network_Interfaces объясняет это тем, что Linux сам по себе не знает, как маршрутизировать ответы, если адресат получателя 10.0.2.100 (eth1). Он (каждый дополнительный интерфейс) нуждается в своей собственной таблице маршрутизации, чтобы отвечать через соответствующий шлюз 10.0.2.1, как в eth0's 10.0.1.1. Однако эта страница имеет дело с традиционным стилем конфигурации сети, который заменил netplan. Кроме того, я прочитал, что netplan не поддерживает таблицы RT2? (iproute2?)

Каким должен быть кошерный подход для нетплана? Может ли это быть так же просто, как предоставление собственного шлюза4?

        eth1:
            addresses:
            - 10.0.2.100/24
            gateway4: 10.0.2.1

Или это намного более сложная конфигурация, аналогичная работе iproute2? Я не уверен, как тестировать на реальном сервере (не могу проверить это на моей собственной виртуальной машине, поскольку у меня нет такого же многосетевого оборудования и среды на моем ноутбуке.) Из-за страха потерять соединение с ним (SSH) после неправильная конфигурация.

ОБНОВЛЕНИЕ 17 СЕНТЯБРЯ: Сегодня мы обсудили и приступили к непосредственному изменению конфигурации сервера 50-cloud-init.yaml для включения вышеуказанного дополнительного шлюза для eth1, но сервер по-прежнему не может маршрутизировать ответы от этого интерфейса.

ОБНОВЛЕНИЕ 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 (с моего ноутбука), но нет исходящего ответа.

2
задан 17 September 2019 в 12:45

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-адрес теперь contactable.

0
ответ дан 23 October 2019 в 11:49

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

Похожие вопросы: