Назад | Перейти на главную страницу

Таблица маршрутов для нескольких записей подсети?

Так же, как немного контекста, это для виртуальной машины, которая выполняет обработку вызовов. Я посмотрел на таблицу маршрутов на виртуальной машине и заметил, что в ней есть следующее:

  12.12.12.64/28 dev bond15 proto kernel scope link src 12.12.12.12
  12.12.12.64/28 dev bond19 proto kernel scope link src 12.12.12.12
  12.12.12.64/28 dev bond11 proto kernel scope link src 12.12.12.12
  12.12.12.64/28 dev bond8 proto kernel scope link src 12.12.12.12

Итак, мой вопрос: имеет ли это смысл? Я не добавлял их в таблицу маршрутизации самостоятельно, они были установлены при настройке IP. Но у меня вопрос, как тогда это работает? Если 12.12.12.64/28 приходит пакет, предназначенный для чего-либо, он всегда идет на интерфейс bond15, правильно? Разве это не отменяет полностью интерфейсы bond19 и bond11?

Теперь, как было сказано, я также сделал ifconfig виртуальной машины и заметил, что все эти интерфейсы BOND имеют одинаковый IP:

  bond8: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1472
          inet 12.12.12.12  netmask 255.255.255.240  destination 12.12.12.12
 bond11: flags=209<UP,POINTOPOINT,RUNNING,NOARP>         mtu 1472
          inet 12.12.12.12  netmask 255.255.255.240  destination 12.12.12.12
        bond15: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1472
    inet 12.12.12.12  netmask 255.255.255.240    destination 12.12.12.12
  bond19: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1472
    inet 12.12.12.12  netmask 255.255.255.240  destination 12.12.12.12

Итак, учитывая эти две части информации, мне любопытно, как все это объединить. Означает ли это, что все эти BOND используют один и тот же интерфейс? Если да, то почему в таблице маршрутов должно быть несколько строк? и почему бы просто не создать одну единственную запись в ifconfig, которая объединяет все 4 облигации в одну? Значит, есть только один Bond0 для 12.12.12.12 и запись ipconfig для Bond0 для 12.12.12.12?

Мне кажется, что в соответствии с таблицей маршрутов любой пакет, предназначенный для этой подсети, пойдет только на Bond15, потому что он появляется первым в списке маршрутов?

Спасибо всем..

Сначала вы должны знать, что для любых дополнительных сетевых настроек ifconfig и route следует полностью избегать, и ip link, ip address, ip route (так же как ip rule для маршрутизации политики, bridge в дополнении к ip link заменить brctl) вместо этого. Некоторые функции недоступны в старых инструментах, поскольку новые функции реализованы только в новом API ядра ((RT) netlink вместо ioctl).

Эти маршруты помечены proto kernel: это означает, что они были автоматически добавлены ядром при добавлении адресов к интерфейсам, возможно, примерно так:

ip address add 12.12.12.12 peer 12.12.12.64/28 dev bond8

Само по себе это не имеет особого смысла: будет использоваться только первый указанный маршрут среди равных: bond15, для правильной маршрутизации должны быть другие элементы.

Я могу придумать как минимум два способа сделать это:

дополнительные таблицы маршрутизации

Вероятно, это должно работать вместе с зоны conntrack (чтобы избежать смешивания двух идентичных потоков, кроме их интерфейса), Connmarks и Метки (с помощью iptables или столы), чтобы отмечать пакеты, чтобы знать, откуда они пришли, и чтобы ядро могло ответить туда. В ip rule команда возвращает это в стандартной системе:
```
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default
```
Если у вас есть дополнительные записи, вероятно, это выбранный метод, и он может стать довольно сложным, если дополнительные настройки будут выполнены с помощью iptables или столы. За каждую дополнительную запись с lookup XXXX, вы можете отобразить дополнительную таблицу маршрутизации с помощью:
```
ip route show table XXXX
```
у которого, вероятно, будет только один bondXX устройство, указанное внутри него (возможно, через другие интерфейсы).
привязка непосредственно к интерфейсу

С помощью SO_BINDTODEVICE:

SO_BINDTODEVICE

Привяжите этот сокет к определенному устройству, например «eth0», как указано в переданном имени интерфейса. [...] Если сокет привязан к интерфейсу, только пакеты, полученные от этого конкретного интерфейса, обрабатываются сокетом. Обратите внимание, что это работает только для некоторых типов сокетов, особенно сокетов AF_INET.

Обычно для этого требуется уйти Переадресация обратного пути отфильтровать, например, с помощью:
```
sysctl -w net.ipv4.conf.all.rp_filter=0

sysctl -w net.ipv4.conf.bond8.rp_filter=0
sysctl -w net.ipv4.conf.bond11.rp_filter=0
sysctl -w net.ipv4.conf.bond15.rp_filter=0
sysctl -w net.ipv4.conf.bond19.rp_filter=0
```
на самом деле возможно просто с этим перед созданием интерфейсов:
```
sysctl -w net.ipv4.conf.default.rp_filter=0
```
Я мог бы заставить это работать, используя socat и это so-bindtodevice= вариант, но только как клиент (подключение), а не как сервер (прослушивание), поэтому я не знаю, подходит ли он для всех случаев, или это было ограничение с socat или что-то я пропустил. Что-то вроде:
```
socat tcp4:12.12.12.65:5555,so-bindtodevice=bond11 -
```
для связи со службой через порт 5555 / tcp в системе, владеющей 12.12.12.65 на облигация11 стороне (а не той, что на облигация15 сторона).

Кроме того, несмотря на свое название, эти интерфейсы не относятся к типу связь, но наверное туннель какой-то. С помощью ip -details link show будет отображать их фактический тип (в начале 3-й строки для каждого интерфейса).