2 сетевые карты на 1 сервере Ubuntu netplan config

Question 1

Я пытаюсь запустить сервер с двумя сетевыми картами. Одна сетевая карта будет иметь динамический IP (DHCP), а другая будет иметь статический IP 192.168.0.24. У меня на этом сервере две сетевые карты, 1ГБ (enp4s0) и 10ГБ (enp5s0).

Текущая новая установка ОС:

oven@oven-f1:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:    22.04
Codename:   jammy

Этот netplan является стандартным, который устанавливается с новой ОС, используя стандартные настройки сети:

oven@oven-f1:~$ sudo cat /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 reboot.  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:
        enp4s0:
            dhcp4: true
    version: 2
    wifis: {}

статус сетевых карт с этим netplan:

oven@oven-f1:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether d8:43:ae:90:b8:2e brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 74:fe:ce:ea:db:b5 brd ff:ff:ff:ff:ff:ff

стандартные маршруты с этой конфигурацией netplan:

oven@oven-f1:~$ ip route
default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.27 metric 100 
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100 
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.27 metric 100

Ниже приведена новая конфигурация netplan, которую я пытаюсь реализовать:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: true
    enp5s0:
      dhcp4: true
      addresses:
        - 192.168.0.24/24
      routes:
        - to: 0.0.0.0/0
          via: 192.168.0.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

Проблема возникает, когда я выполняю sudo netplan --debug apply с новым конфигом:

oven@oven-f1:~$ sudo netplan --debug apply
    ** (generate:1778): DEBUG: 07:51:08.869: starting new processing pass
** (generate:1778): DEBUG: 07:51:08.869: enp5s0: adding new route
** (generate:1778): DEBUG: 07:51:08.869: starting new processing pass
** (generate:1778): DEBUG: 07:51:08.869: We have some netdefs, pass them through a final round of validation
** (generate:1778): DEBUG: 07:51:08.869: enp4s0: setting default backend to 1
** (generate:1778): DEBUG: 07:51:08.869: Configuration is valid
** (generate:1778): DEBUG: 07:51:08.869: enp5s0: setting default backend to 1
** (generate:1778): DEBUG: 07:51:08.869: Configuration is valid
** (generate:1778): DEBUG: 07:51:08.869: Generating output files..
** (generate:1778): DEBUG: 07:51:08.869: Open vSwitch: definition enp4s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: NetworkManager: definition enp4s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: Open vSwitch: definition enp5s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: NetworkManager: definition enp5s0 is not for us (backend 1)
** (process:1776): DEBUG: 07:51:09.042: starting new processing pass
** (process:1776): DEBUG: 07:51:09.042: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.042: starting new processing pass
** (process:1776): DEBUG: 07:51:09.042: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.042: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.042: Configuration is valid
** (process:1776): DEBUG: 07:51:09.042: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.042: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.128: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.128: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid

статус сетевых карт с этим новым netplan:

oven@oven-f1:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether d8:43:ae:90:b8:2e brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 74:fe:ce:ea:db:b5 brd ff:ff:ff:ff:ff:ff

стандартные маршруты с этой новой конфигурацией netplan:

oven@oven-f1:~$ ip route
default via 192.168.0.1 dev enp5s0 proto static 
default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.27 metric 100 
192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.24 
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100 
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.27 metric 100

Ошибок в моей конфигурации нет, но я теряю доступ к серверу по ssh. Я все еще могу получить доступ к интернету с сервера и подключиться по ssh к другим машинам, но не могу подключиться по ssh к серверу с моего ноутбука.

Я не могу пинговать сервер, но все равно вижу его адрес:

s@M1 ~ % nslookup oven-f1
Server:     2001:8003:d44e:7600::1
Address:    2001:8003:d44e:7600::1#53

Name:   oven-f1.modem
Address: 192.168.0.27

s@M1 ~ % ping oven-f1
PING oven-f1.modem (192.168.0.27): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- oven-f1.modem ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

Я не уверен, почему после активации 2-х сетевых карт я не могу подключиться по ssh к серверу, любая помощь будет очень полезна, так как я застрял.

Редактировать обновление ответа

ниже приведена рабочая конфигурация netplan. Я просто разделил 10ГБ карты и 10ГБ коммутатор на разные подсети 192.168.1.0/24 и оставил 1ГБ карты и коммутатор на 192.168.0.0/24.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: true
    enp5s0:
      dhcp4: false
      addresses:
        - 192.168.1.24/24

также обновил файл hosts на серверах, чтобы отобразить хосты в подсети 192.168.1.0/24.

Question 2

Первая проблема здесь в том, что у вас есть две независимые подсети, которые используют одну и ту же схему адресации.
Не делайте этого. Если 10Гбит¹ коммутатор не имеет соединения с основным 1Гбит LAN коммутатором, тогда они должны использовать разные номера сети – например, 192.168.1.0/24 для одного и 192.168.10.0/24 для другого – независимо от того, является ли это корнем вашей проблемы.

Это связано с тем, что операционные системы в первую очередь обрабатывают свои локальные подсети как единое целое, а также потому, что они направляют ответные пакеты независимо от запросов (с некоторыми исключениями). Так что, когда вы пытаетесь установить связь с 192.168.0.26, но у вас две сетевые карты, подключенные к двум разным подсетям 192.168.0.0/24, ОС не будет пытаться определить, в какой сети находится такой адрес (с Windows, возможно, исключение) – вместо этого весь маршрут /24 через карту A настраивается с более высоким приоритетом, чем идентичный маршрут через карту B.

Например, когда у вашего Linux сервера такие маршруты:

192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.24 
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100

и ему нужно ответить на запрос соединения SSH с вашего ПК, он отправит этот ответ через dev enp5s0 (ваша 10Gbit карта), потому что этот маршрут имеет такой же префикс (/24) и меньшую метрику (меньшую стоимость); и поскольку 10Gbit карта не имеет соединения с 1Gbit подсетью, этот пакет так и не дойдет до ПК.

Подключение 10Gbit коммутатора к 1Gbit коммутатору было бы самым простым способом сделать это, объединив их в одну сеть (без потери производительности) – хотя это сделало бы 1Gbit карту по сути ненужной.

Но поскольку у вас больше нет свободных портов на 10Gbit коммутаторе и вам необходимо сохранить подсети раздельными, тогда вы должны перенумеровать одну из них – и это само по себе должно сделать все рабочим, по крайней мере, пока у вас всего две подсети в общем.

В качестве побочного примечания (как только вы приведете в порядок схемы нумерации подсетей), технически достаточно иметь вторую карту только на одном сервере, который может тогда действовать как маршрутизатор между подсетями “1Gbit” и “10Gbit” – хотя если у вас достаточно портов и карт, установка второй карты на каждом сервере, безусловно, упростит конфигурацию.

Еще одна проблема в том, что у вас есть маршрут по умолчанию на enp5s0, несмотря на то, что вы говорите, что он подключается к коммутатору, не подключенному к какому-либо маршрутизатору – что означает, что 192.168.0.1, вероятно, не существует в этой сети, и даже если он существует, он все равно не будет иметь доступа в интернет. Это, скорее всего, приведет к повторению ранее описанной проблемы, то есть, что бесполезный маршрут “0.0.0.0/0 через enp5s0” имеет более высокий приоритет, чем рабочий маршрут “0.0.0.0/0 через enp4s0”.

Не настраивайте шлюз по умолчанию, если в сети его нет. Маршрут по умолчанию не требуется для функционирования интерфейса. (Связь в пределах одной подсети происходит без использования шлюза по определению!)

¹ Заметьте, что “GB” (с заглавной буквы) означает “гигабайт“, что отличается в 8–10 раз от “Gb” (гигабит).

Question 3

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

Вы пытаетесь получить доступ к серверу (ssh) из той же подсети, поэтому маршрут по умолчанию не будет учитываться, будут учитываться только маршруты 192.168.0.0/24.

На статическом интерфейсе у вас есть маршрут:
192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.24

На DHCP у вас:
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100

Поскольку метрика на DHCP равна 100, а на статике 0 из-за отсутствия назначенной метрики, маршрут 0 будет использоваться. Это означает, что весь трафик для 192.168.0.0/24 будет отправлен через enp5s0. Это вызывает проблемы, так как MAC-адрес, который клиент получит, отличается от того, на который он отправлялся, также если вы не включили route_localnet, два интерфейса не могут маршрутизировать трафик между собой.

Если вы хотите, чтобы две сетевые карты находились в одной подсети, у вас есть множество вариантов, некоторые из них зависят от типа коммутатора, который вы используете. Два варианта, которые будут работать вне зависимости от коммутатора, который вы используете.

Измените одну из сетевых карт на подсеть 255.255.255.255. Предположу, что вы захотите, чтобы 1ГБ карта имела эту.

ip a add 192.168.0.27/32 dev enp4s0
ip a del 192.168.0.27/24 dev enp4s0

вам нужно будет обновить конфигурацию netplan, чтобы применить новый IP-адрес, и отключить DHCP на этом интерфейсе. В противном случае он снова получит подсеть /24.

вам также нужно будет включить route_localnet

sysctl -w net.ipv4.conf.all.route_localnet=1

Чтобы сделать это постоянным после перезагрузок

echo net.ipv4.conf.all.route_localnet=1 >> /etc/sysctl.conf

Это приведет к тому, что любые пакеты, адресованные 192.168.0.27, будут отправляться с этого интерфейса, метрика не будет иметь значения, так как всегда будет использоваться более высокая подсеть, метрика является фактором только когда подсети одинаковы. Использование адреса /32 также отключит широковещание на этом интерфейсе, что предотвратит замыкание широковещательных рассылок.

Связывание интерфейсов. Самый простой способ для этого – установить bridge-utils

На Ubuntu:
apt install bridge-utils

brctl addbr br0
brctl addif br0 enp4s0
brctl addif br0 enp5s0

ip link set enp4s0 promisc on
ip link set enp5s0 promisc on

ip link set br0 up
dhclient br0
ip a del 192.168.0.27/24 dev enp4s0
ip a del 192.168.0.24/24 dev enp5s0

Это даст интерфейсу мостового соединения новый IP-адрес.

Эта настройка может вызвать петлю широковещательной рассылки, если это произойдет, попробуйте включить STP.

brctl stp br0 on

убедитесь, что у вас есть доступ к терминалу либо локально, либо с помощью какого-либо управления вне диапазона, такого как iDrac или iLo, переключение на мост может вызвать разрыв связи во время процесса переключения.

****Примечание, я не рекомендую такую настройку, у вас не должно быть 2 сетевые карты в одном широковещательном сегменте (VLAN’ы – это один из способов создания отдельных широковещательных сегментов). Объединение соединений будет лучшим решением.

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

2 сетевые карты на 1 сервере Ubuntu netplan config

Вопрос или проблема

Ответ или решение

Описание проблемы

Почему это происходит?

Решение

1. Использование разных подсетей

2. Избегайте установки дублирующегося шлюза по умолчанию

Подведение итогов