Не удается установить соединение через второй сетевой адаптер (два прыжка)

Question

Не удается установить соединение через второй сетевой адаптер (два прыжка)

У нас проблемы с настройкой сетевой маршрутизации в Ubuntu Xenial.

У нас есть много серверов с Debian 8.4 (Jessie) и Ubuntu 16.04.2 (xenial) и точно такими же сетевыми настройками (или, по крайней мере, насколько мы видим).

Все они имеют два сетевых адаптера, подключенных к двум VLAN (скажем, "A" и "B"), оба доступны, хотя другие VLAN говорят, например, из VLAN "C".

И то и другое /etc/network/interfaces файлы имеют вид:

ПРИМЕЧАНИЕ: я подделал имена и IP-адреса ради лучшей читабельности.

# VLAN A
auto eth0
iface eth0 inet static
address 192.168.111.xxx
netmask 255.255.255.0
broadcast 192.168.111.255
network 192.168.111.0
gateway 192.168.111.254
dns-nameservers 192.168.111.25 192.168.111.26

# VLAN B
auto eth1
iface eth1 inet static
address 192.168.222.xxx
netmask 255.255.255.0
broadcast 192.168.222.255
network 192.168.222.0
gateway 192.168.222.254 # <-- (Commented out in Ubuntu machine)
dns-nameservers 192.168.111.25 192.168.111.26

...сказать xxx 100 для машины Debian и 200 для машины Ubuntu, и я пытаюсь пропинговать 192.168.1.10 в VLAN "C" по следующим адресам:

192.168.111.100: Работает нормально.
192.168.222.100: Работает нормально.
192.168.111.200: отлично работает.
192.168.222.200: НЕТ ответа!!

Влан "B" в основном используется для резервного копирования и другого "фонового" трафика, чтобы избежать проблем с насыщением в vlan "А".

Я знаю, что наличие двух сетевых путей для доступа к одной и той же машине - это не обычная настройка, и я должен сказать, что в настоящее время не существует большой проблемы только с возможностью подключения, если один из них подключен к другим сетям. Но что меня беспокоит, так это то, что я могу получить доступ к машинам Debian, а не к Ubuntu?

Даже, с другой стороны, если бы это работало хорошо на обеих платформах, мы могли бы рассмотреть закрытие некоторых сервисов (таких как ssh и backend-интерфейсы) от NIC "A" для повышения безопасности (Наш брандмауэр разрешает доступ только к vlan "B" от нашего айтишника влан).

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

Но таблицы маршрутизации обеих машин практически идентичны. Единственное отличие, которое я видел, был флаг onlink на машине с Ubuntu:

myUser@debianMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.100
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.100


myUser@ubuntuMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0 onlink
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.200
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.200

... но я смог удалить его с помощью следующей команды:

myUser@ubuntuMachine:~$ sudo ip route replace default via 192.168.111.254 dev eth0
myUser@ubuntuMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.200
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.200

И это не решило проблему.

После этого я также попытался раскомментировать строку шлюза "VLAN B", которая, как я уже сказал, была закомментирована в файле / etc / network / interfaces и попыталась перезапустить сеть, но вот что произошло:

myUser@ubuntuMachine:~$ sudo /etc/init.d/networking restart
[....] Restarting networking (via systemctl): networking.serviceJob for networking.service failed because the control process exited with error code. See "systemctl status networking.service" and "journalctl -xe" for details.
failed!

... и флаг onlink вернулся снова.

Как примечание, снова комментируя эту строку и выпуская новый /etc/init.d/networking restart Команда выводит то же самое, пока машина не будет перезагружена (даже работа в сети, несмотря на проблему с VLAN B по умолчанию, продолжает работать как обычно).

Ниже приведены результаты предлагаемых команд:

myUser@ubuntuMachine:~$ sudo systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/networking.service.d
           └─50-insserv.conf-$network.conf
   Active: failed (Result: exit-code) since jue 2017-12-21 14:55:29 CET; 42s ago
     Docs: man:interfaces(5)
  Process: 8552 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo (code=exited, status=0/SUCCESS)
  Process: 8940 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 8934 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-envi
 Main PID: 8940 (code=exited, status=1/FAILURE)

dic 21 14:55:29 ubuntuMachine systemd[1]: Stopped Raise network interfaces.
dic 21 14:55:29 ubuntuMachine systemd[1]: Starting Raise network interfaces...
dic 21 14:55:29 ubuntuMachine ifup[8940]: RTNETLINK answers: File exists
dic 21 14:55:29 ubuntuMachine ifup[8940]: Failed to bring up eth1.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILUR
dic 21 14:55:29 ubuntuMachine systemd[1]: Failed to start Raise network interfaces.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Unit entered failed state.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Failed with result 'exit-code'.

... и значимая часть sudo journalctl -xe:

dic 21 14:55:29 ubuntuMachine sudo[8922]:   myUser : TTY=pts/0 ; PWD=/home/myUser ; USER=root ; COMMAND=/etc/init.d/networking restart
dic 21 14:55:29 ubuntuMachine sudo[8922]: pam_unix(sudo:session): session opened for user root by myUser(uid=0)
dic 21 14:55:29 ubuntuMachine systemd[1]: Stopped Raise network interfaces.
-- Subject: Unit networking.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has finished shutting down.
dic 21 14:55:29 ubuntuMachine systemd[1]: Starting Raise network interfaces...
-- Subject: Unit networking.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has begun starting up.
dic 21 14:55:29 ubuntuMachine ifup[8940]: RTNETLINK answers: File exists
dic 21 14:55:29 ubuntuMachine ifup[8940]: Failed to bring up eth1.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
dic 21 14:55:29 ubuntuMachine systemd[1]: Failed to start Raise network interfaces.
-- Subject: Unit networking.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has failed.
--
-- The result is failed.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Unit entered failed state.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Failed with result 'exit-code'.
dic 21 14:55:29 ubuntuMachine sudo[8922]: pam_unix(sudo:session): session closed for user root

Я много гуглил о том, что смог найти какую-то связанную информацию, но ни одна полностью не отвечала на мой вопрос:

Объяснение флага "onlink", которое мне показалось, указывало на возможность того, что флаг "onlink" был ответственен за "неправильную обратную маршрутизацию" в том смысле, что "говорит ядру, что оно не должно проверять, шлюз доступен непосредственно текущей машиной ", поэтому (как я выяснил) ядро может подумать, что оно может (или должно) направить ответы входящих соединений из VLAN C на шлюз по умолчанию вместо того, чтобы думать о том же сетевом адаптере, откуда было установлено соединение,
- Но, как я уже сказал, удаление флага "onlink", похоже, ничего не изменило.
Этот ответ Unix StackExchange, кажется, решает проблему (я еще не тестировал), используя несколько таблиц и правил маршрутизации (чтобы сообщить ядру, какую таблицу использовать). Но это не объясняет, почему машины Debian работают хорошо (я проверил файл /etc/iproute2/rt_tables обеих машин, и они тоже идентичны:

myUser@bothMachines:~$ sudo cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

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

myUser@debianMachine:~$ sudo uname -a
Linux debianMachine 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

myUser@ubuntuMachine:~$ sudo uname -a
Linux ubuntuMachine 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

И, следовательно, вопрос заключается в следующем:

Мы делаем что-то не так (или в них есть какая-то ошибка) на машинах с Ubuntu? Или, наоборот, это правильное поведение, и мы вынуждены настроить более сложную схему маршрутизации (либо по маршрутам для каждого vlan, либо с помощью двух таблиц маршрутизации, чтобы заставить два шлюза по умолчанию работать снова)?

РЕДАКТИРОВАТЬ:

Теперь я попытался добавить статический маршрут для решения проблемы:

myUser@ubuntuMachine:~$ sudo ip route add 192.168.1.0/24 via 192.168.222.254 dev eth1

... но это заморозило мое соединение ssh (думал NIC A), даже я мог тогда соединить мысль NIC B (в 192.168.111.200)

Оба правила одновременно кажутся невозможными:

myUser@ubuntuMachine:~$ sudo ip route add 192.168.1/24 via 102.168.111.254 dev eth0
myUser@ubuntuMachine:~$ sudo ip route add 192.168.1/24 via 192.168.222.254 dev eth1
RTNETLINK answers: File exists

РЕДАКТИРОВАТЬ 2:

Я наконец нашел Linux Advanced Routing & Traffic Control HOWTO, который, кажется, более точен, чем вся другая документация, которую я нашел, и, в частности, в главе 4. Правила - база данных политики маршрутизации. Я вижу следующий текст:

Если вы хотите использовать эту функцию, убедитесь, что ваше ядро скомпилировано с функциями "IP: расширенный маршрутизатор" и "IP: политика маршрутизации"

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

-2

networking routing ip ubuntu-server iproute

Источник

user4243912 22 дек '17 в 09:17

1 ответ

Решение

Другие вопросы по тегам networking routing ip ubuntu-server iproute

user4243912 22 дек '17 в 13:17 2017-12-22 13:17 · Accepted Answer · 2017-12-22 13:17

Не авторитетный ответ, но моя первая рабочая попытка (применяя то, что мне удалось понять):

sudo ip route add 192.168.1.0/24 via 192.168.222.254 from 192.168.222.200 dev eth1 table 253 
sudo ip rule add from 192.168.222.200 table 253

Обновить: from а также devаргументы в ip route команды не требуются (без них все работает хорошо).

... после первой команды isuinng я не смог подключиться, но после ввода второй да.

Логика этого вытекает из этого текста, который я нашел в этом документе:

Linux-2.x может упаковать маршруты в несколько таблиц маршрутизации, идентифицируемых по номеру в диапазоне от 1 до 255 или по имени из файла /etc/iproute2/rt_tables. По умолчанию все нормальные маршруты вставляются в основную таблицу (ID 254) и ядро использует эту таблицу только при расчете маршрутов.
На самом деле, всегда существует еще одна таблица, которая невидима, но еще важнее. Это локальная таблица (ID 255). Эта таблица состоит из маршрутов для локальных и широковещательных адресов. Ядро поддерживает эту таблицу автоматически, и администратору обычно не нужно ее изменять или даже просматривать.

Фактически я наконец-то использовал другую таблицу маршрутизации, идентифицированную по ее идентификатору (253) вместо того, что, как я теперь понимаю, это просто псевдоним (определенный в файле /etc/iproute2/rt_tables).

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

Что я пока не знаю, так это какая логика стоит за этим наименованием (я имею в виду "по умолчанию" для таблицы маршрутизации 253), и если по какой-либо причине лучше использовать более низкие таблицы маршрутизации (1, 2, 3...), как это решение (уже упоминалось в вопросе) делает.

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

gateway 192.168.222.254 table 253
post-up ip rule add from 192.168.222.200 table 253

Мне все еще нужно проверить и проверить, нужна ли мне дополнительная via 192.168.222.254 в строке шлюза или если он вообще не будет работать, и вместо этого нужно добавить его с помощью другой команды post-up.
Я обновлю этот ответ с результатами.

Редактировать 1: То же самое работает с маршрутами по умолчанию:

sudo ip route add default from 192.168.222.200 via 192.168.222.254 table 253
sudo ip rule add from 192.168.222.200 table 253

Редактировать 2: Первый (теперь полностью) рабочий подход

Поработав некоторое время на тестовой машине, я думаю, что лучшее решение - добавить следующие строки во вторую конфигурацию NIC в /etc/network/interfaces файл:

gateway 192.168.222.254 table 1
post-up ip rule add from 192.169.222.200 table 1
pre-down ip rule del from 192.168.222.200 table 1
post-up ip route add 192.188.222.0/24 dev eth1 src 192.168.222.200 table 1

Комментарии:

Добавление table 1 к gateway ключевое слово работало хорошо, поэтому дополнительная (менее читаемая) команда пост-апа для добавления этого маршрута по умолчанию не нужна.
- ... на самом деле, использование определенной таблицы (кроме основной) для первого NIC вместе с тем же правилом, которое мы использовали для нашего второго NIC, было бы плохой идеей, потому что это правило будет применяться только тогда, когда 192.168.111.200 собирается будет использоваться в качестве адреса источника, поэтому не будет никакого "шлюза по умолчанию". Если оставить первую конфигурацию NIC в основной таблице маршрутизации, все исходящие подключения ("локально сгенерированные") к удаленным локальным сетям будут осуществляться через наш первый шлюз по умолчанию по умолчанию.
Первый post-up Команда добавляет правило, согласно которому пакеты с адресом источника этого сетевого адаптера должны маршрутизироваться с использованием таблицы 1 (иначе наш новый шлюз по умолчанию не использовался бы).
pre-down Команда удаляет это правило. Это не обязательно, но без него многократные перезапуски сетевых служб будут дублировать это правило каждый раз.
Я также пытался использовать dev eth1 вместо from 192.169.222.200 (чтобы избежать дублирования сетевого адреса), но это не сработало. Я предполагаю, какой сетевой адаптер использовать для "ответных" пакетов "еще не определен".
я использовал table 1 для eth1 (наш второй NIC), и я мог бы использовать table 2 для возможного третьего и так далее. Нет необходимости указывать какую-либо таблицу / правило для первого сетевого адаптера, поскольку он относится к основной таблице (не "по умолчанию": см. Примечание ниже).
Наконец (¹) второй post-up Команда заставляет все вещи работать хорошо, потому что (как я теперь понимаю) используется только (первое сопоставление) одна таблица маршрутизации, поэтому сетевой маршрут по умолчанию (автоматически создаваемый при запуске интерфейса) не применяется, потому что он был создан в таблице main.
- Я до сих пор не знаю, есть ли способ заставить его быть помещенным непосредственно в таблицу 1.

ПРИМЕЧАНИЕ: по команде sudo ip rule list мы можем видеть текущие правила маршрутизации следующим образом:
0:      from all lookup local 
32765:  from 192.168.222.200 lookup 1 
32766:  from all lookup main 
32767:  from all lookup default
Как я понимаю, они добавляются по убыванию с 32767 до 0 и пробуются все чаще, пока не будет найдено одно совпадение. Последние два и "0" уже определены по умолчанию. Первый из-за логики, которую я ранее процитировал из этого документа, но в этих документах говорится, что правила начинаются с "1", поэтому я предполагаю, что "0" также должно быть предопределенной "начальной точкой по умолчанию".

Изменить 3:

Как я уже говорил в Edit 2 (вопроса), я нашел этот Linux Advanced Houting Routing & Traffic Control, который мне очень помог в прояснении вещей.

Конкретно, глава " Маршрутизация для нескольких каналов связи / провайдеров" была очень полезна для меня в понимании установок, имеющих "сетевые петли" (даже в нашем случае мы не выступаем в роли маршрутизатора к Интернету).