Спустя семнадцать лет с момента последнего прикосновения к 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 (с моего ноутбука), но нет исходящего ответа.
Хорошо похож согласно исходной старой статье, эти дополнительные маршруты действительно должны быть определены в таблицы отдельной маршрутизации, вместе с явными директивами политики маршрутизации для "силы" ОС для маршрутизации трафика к/от 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.