Linux: соединение двух Ethernet-соединений вместе, чтобы позволить второму хосту в первой сети

Ситуация:

Сеть A <-> Сервер <-> Клиентский хост

Я хочу разрешить клиентскому хосту доступ к сети A через мост, позволяя обоим хостам получать доступ к сети A через одно соединение Ethernet.

Все это физические устройства, и я использую машины Linux / Ubuntu.

Итак, я создал мост, ntlbridge0 и поработил два Ethernet-устройства на Сервере, eth0 (в сеть A) и eth1 (клиенту).

И Сервер, и Клиент получают свои IP-адреса через DHCP. (которые назначаются маршрутизатором по Mac-адресу)

Как мне настроить это соединение, чтобы Клиент мог получить аренду DHCP из сети?

Пока клиент пытается подключиться, у него еще нет IP-адреса, поэтому я не уверен, как я могу создать правило брандмауэра, чтобы разрешить трафик от eth1 к eth0 без указания ufw / iptables IP-адреса для маскировки или пересылки.

В идеале я бы хотел, чтобы и сервер, и клиент были видимы для сети A на одном уровне. (У каждого должен быть свой IP-адрес, поэтому сетевой менеджер «Share Internet» не будет работать.) И MAC-адрес клиента должен быть видим в сети (чтобы он получил правильный IP-адрес от маршрутизатора.

У меня это работало раньше (с помощью чего я теперь не уверен), но теперь я больше не могу заставить его работать даже после того, как я отключил брандмауэры и повторно создал соединения.

Подробнее:

Использование сетевого менеджера для всех упомянутых устройств
UFW должен оставаться включенным на обоих хостах в целях безопасности
Я использую соединительный кабель между сервером и клиентом (это все еще имеет значение?)
Все подключения к серверу работают нормально, а клиент подключается правильно, если не используется мост через сервер.

На сервере:

route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.10.1    0.0.0.0         UG    426    0        0 ntlbridge0
192.168.10.0    *               255.255.255.0   U     425    0        0 ntlbridge0
192.168.10.0    *               255.255.255.0   U     426    0        0 ntlbridge0

nmcli dev status
DEVICE      TYPE      STATE      CONNECTION
ntlbridge0  bridge    connected  bridge ntl
enp1s0f0    ethernet  connected  ntlbridge0 slave enp1s0f0 
enp1s0f1    ethernet  connected  ntlbridge0 slave enp1s0f1

Требуется дополнительная информация:

ip link show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0f0:  mtu 1500 qdisc mq master ntlbridge0 state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1:  mtu 1500 qdisc mq master ntlbridge0 state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:41 brd ff:ff:ff:ff:ff:ff
9: ntlbridge0:  mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff

ip addr show
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    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: enp1s0f0:  mtu 1500 qdisc mq master ntlbridge0 state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
3: enp1s0f1:  mtu 1500 qdisc mq master ntlbridge0 state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:41 brd ff:ff:ff:ff:ff:ff
9: ntlbridge0:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d0:27:xx:xx:xx:40 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.67/24 brd 192.168.10.255 scope global dynamic ntlbridge0
       valid_lft 50187sec preferred_lft 50187sec
    inet6 2601:844:4000:xxx:xxx:xxxx:xxxx:ac61/64 scope global noprefixroute dynamic 
       valid_lft 2367sec preferred_lft 2367sec
    inet6 fe80::1e94:xxxx:xxxx:77ba/64 scope link 
       valid_lft forever preferred_lft forever

ip route show
default via 192.168.10.1 dev ntlbridge0  proto static  metric 425 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown 
192.168.10.0/24 dev ntlbridge0  proto kernel  scope link  src 192.168.10.67  metric 425 
192.168.10.0/24 dev ntlbridge0  proto kernel  scope link  src 192.168.10.67  metric 426 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown

brctl show
bridge name     bridge id       STP enabled interfaces
docker0         8000.0242910e3b7a   no      
ntlbridge0      8000.d027xxxxxx40   yes     enp1s0f0
                                enp1s0f1

Таааааааааааааааааааааа в мосту в современные ядра ... ты жестяная банка указать ядру отправлять пакеты, которые проходят через мост через iptables, и они обрабатываются точно так же, как если бы они были перенаправлены на уровне 3. Редко, когда вы действительно этого хотите, и все же некоторые дистрибутивы, версии ядра или что-то еще эта функция включена по умолчанию (возможно, для безопасности, что понятно, если это вас расстраивает).

Проверьте значения sysctls /proc/sys/net/bridge/bridge-nf-call-*; если любой из них 1, то соответствующая система фильтрации используется для сопоставления пакетов (iptables для пакетов IPv4, ip6tables для пакетов IPv6). Установите их на 0 выключить эту штуку, и вы можете увидеть приятное улучшение.

В вашем вопросе действительно недостаточно, чтобы точно сказать, что происходит, но bridge-nf-call-* sysctls - это всегда первое место, куда я обращаю внимание, когда налаживается мост.

Кроме того, без pcap на всех задействованных интерфейсах практически невозможно определить, что происходит и в чем может заключаться проблема.