Создайте мостовой интерфейс на отдельной сетевой карте, но в той же подсети, что и шлюз хоста [дубликат]

Примечание. Я не смог найти прямого ответа ни в одном из дубликатов, отмеченных для этого вопроса. Проблема в том, что «правильный ответ», похоже, очень сильно зависит от того, какой выпуск вы используете, и есть ли у вас профиль рабочего стола или сервера. У меня есть немного и того, и другого, потому что я установил lubuntu-core для обеспечения некоторых основных функций удаленного X, и кажется, что NetworkManager также был установлен, но мы предпочитаем редактировать нашу сетевую конфигурацию вручную, а не использовать инструменты графического интерфейса.

Ситуация такова, что у меня есть удаленный сервер Ubuntu 14.04, на котором мне нужно перенастроить сеть. Мне нужно безопасно добавить мостовой интерфейс eth1 к удаленной системе, не нарушая удаленного подключения. У меня есть новый файл / etc / network / interfaces, который я хочу загрузить, но поскольку у меня нет эквивалентной машины для его тестирования или физического доступа к серверу, у меня есть несколько вопросов о моей новой конфигурации:

1. Является ли шлюз конфигурация и метрика в приведенном ниже файле действительны для того, что я пытаюсь сделать и,
2. Будет ли сетевой менеджер отменять или мешать тому, что я здесь делаю? В настоящее время, когда я ifup eth1 , сетевой менеджер просто автоматически отключает его .Я боюсь отключать NM, если он убивает удаленное соединение , и
3. Если я перезагружу систему с обновленным файлом и моей текущей конфигурацией, сможет ли она получить удаленное SSH-соединение, когда оно появится резервное копирование?

На сервере уже запущен NetworkManager, но он мне не нужен. Меня интересует только то, что используется конфигурация в / etc / network / interfaces и что машина остается доступной для удаленного входа в систему SSH на всех этапах реконфигурации (т. Е. Я не хочу, чтобы меня заблокировали из-за неправильной конфигурации или отключения обоих интерфейсов. без скрипта или перезагрузить автоматически и правильно их вернуть).

eth0 - интерфейс по умолчанию для трафика хоста. eth1 будет мостом для виртуальной машины KVM с собственным внешним IP-адресом. Оба интерфейса подключаются к одному и тому же физическому коммутатору и совместно используют подсеть X.X.X.0 / 24. Насколько я понимаю, мне нужен мост, чтобы это работало, НО мне также нужно быть осторожным с моими шлюзами и метриками, потому что у меня есть 2 интерфейса в одной сети.

Хост в настоящее время имеет следующий статус NetworkManager:

# nmcli d status
DEVICE     TYPE              STATE
eth1       802-3-ethernet    unavailable
eth0       802-3-ethernet    unmanaged

И конфигурация в NetworkManager.conf:

[ifupdown]
managed=false

Я создал новую конфигурацию ниже:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address X.X.X.4
        netmask 255.255.255.0
        network X.X.X.0
        broadcast X.X.X.255
        gateway X.X.X.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers X.X.X.2
        dns-search example.com
        # Interfaces with lower values get used first
        metric 10

### NEW BRIDGED INTERFACE ON ETH1 ###
auto eth1
iface eth1 inet static
        address X.X.X.7
        netmask 255.255.255.0
        network X.X.X.0
        broadcast X.X.X.255
        # do I need gateway here or will it conflict with eth0 ?
        # gateway X.X.X.1
        metric 20

auto br0
iface br0 inet static
        address X.X.X.200
        netmask 255.255.255.0
        network X.X.X.0
        broadcast X.X.X.255
        gateway X.X.X.1
        bridge_ports eth1
        bridge_stp off
        bridge_maxwait 5
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers X.X.X.2
        dns-search example.com
        metric 30

Как я уже сказал, с этой новой конфигурацией, только что добавленной в сервер ifup eth1 работает только до тех пор, пока NM не решит удалить его. Это делает тестирование чего-либо проблематичным, но я беспокоюсь, что простое отключение NM может быть намного хуже.