Регистрация Войти
Рейтинг:0
avatar Server

iptables NETMAP ненадежно настраивает исходный адрес многоадресных пакетов UDP

флаг us
ncoghlan

В случае использования встраиваемых систем/IoT у меня есть хост управления под управлением Linux, который должен иметь возможность взаимодействовать с несколькими сетями, каждая из которых использует общий набор статических IP-адресов.

В основном это работает нормально, в том числе для многоадресного трафика UDP, учитывая:

  • сетевые ссылки для каждой встроенной сети (назовите их эт1, эт2, и т.д)
  • отдельное сетевое пространство имен Linux для каждой отдельной встроенной сети (назовите их ns1, нс2, и т.д)
  • одноранговая связь между каждым сетевым пространством имен и корневым пространством имен (назовите их одноранговый узел1, сверстник2и т. д. со стороны сетевого пространства имен и veth1, veth2и т. д. со стороны корневого пространства имен)
  • правило iptables NETMAP в каждом пространстве имен для сопоставления конфликтующей статической IP-подсети (назовем ее 192.168.0.х) к неконфликтующему набору статических IP-подсетей (назовем их 192.168.1.х, 192.168.2.х, и т.д)
  • ан раскручен экземпляр внутри каждого сетевого пространства имен для пересылки регистрации групп многоадресной рассылки
  • отдельный IP-адрес в отдельной (не NAT) подсети для стороны корневого пространства имен одноранговых ссылок, чтобы обойти тему этого вопроса (назовите это 192.168.(х+100).1)

Чтобы попытаться визуализировать потоки трафика:

[|корневое пространство имен|::veth1] <-> [peer1::(пространство имен ns1)::eth1] <-> встроенная сеть
[| |::veth2] <-> [peer2::(namespace ns2)::eth2] <-> встроенная сеть
... и т.д ...

ns1 пример правил NETMAP для статических IP-подсетей:

sudo -n ip netns exec ns1 iptables -t nat -A PREROUTING -d 192.168.1.0/24 -i peer1 -j NETMAP --to 192.168.0.0/24
sudo -n ip netns exec ns1 iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o peer1 -j NETMAP --to 192.168.1.0/24

ns1 пример раскручен правила конфигурации для поддерживаемой многоадресной группы:

mgroup из группы eth1 239.255.60.60
mgroup из группы peer1 239.255.60.60
mroute от группы eth1 239.255.60.60 к peer1
mroute от источника peer1 192.168.101.1 группа 239.255.60.60 к eth1

Фактическая тема этого вопроса заключается в том, что в СЕТЕВАЯ КАРТА настройка исходного IP-адреса, которую я не смог объяснить, только обходной путь.

Мое ожидаемое поведение:

  • Подписки на многоадресную рассылку UDP внутри сетевого пространства имен будут видеть неизмененный пре-NETMAP 192.168.0.х исходные адреса
  • Многоадресные подписки UDP внутри корневого пространства имен будут видеть измененный пост-NETMAP. 192.168.1.х исходные адреса

Однако этого не происходит. Вместо этого либо подписчики в обоих пространствах имен видят исходные адреса до NETMAP 192.168.0.x, либо они видят адреса 192.168.1.x после NETMAP.

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

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

Цель вопроса — помочь выяснить, что из следующего применимо:

  • ожидается, что это не сработает, компенсация на уровне приложения - лучшее, что можно сделать (что кажется маловероятным, учитывая использование сетевых пространств имен в контейнерных средах Linux)
  • есть что-то еще, что нужно настроить (или не настроить) в ядре, iptables или smcroute, чтобы предотвратить неправильное поведение

(Примечание: это очень эзотерический, очень специфический вопрос, поэтому я подумал, может ли сетевая инженерия быть более подходящим, но https://networkengineering.stackexchange.com/questions/64744/linux-local-multicast-egress-follows-forward-chain-when-smcroute-is-active ясно дал понять, что это для работы с коммерческими маршрутизаторами и т. д., а не для конфигурации сетевого пространства имен Linux. Однако я менее четко понимаю границы между Server Fault и обменом стеков Unix и Linux, когда дело доходит до настройки серверов Linux)

194
1 + 0
Рейтинг:1
avatar Server
флаг tr
troglobit

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

Очень похожая проблема описана в Трекер проблем SMCRoute, единственное отличие от вас в том, что они не используют NAT 1: 1 с сетевой картой (пока).

я на скорую руку прецедент для этого при подготовке к следующему выпуску (v2.5). Я запускаю все тесты локально и в GitHub Actions (облако Azure), используя:

компакт-диск тест/
unshare -mrun ./multi.sh

В тесте используются два отдельных маршрутизатора (R1 и R2) в выделенных сетевых пространствах имен с общим сегментом локальной сети между ними (192.168.0.0/24). За каждым маршрутизатором находится частная локальная сеть (10.0.0.0/24), которая одинакова для обоих маршрутизаторов. Дополнительный (фиктивный) интерфейс eth1 используется для маршрутизации многоадресной рассылки из общей локальной сети (eth0). Правило NETMAP использует цепочку PREROUTING и POSTROUTING. Преобразование частной локальной сети R1 в 192.168.10.0/24 и частной локальной сети R2 в 192.168.20.0/24. Как вы можете видеть ниже, многоадресные маршруты, установленные в ядре, используют сопоставленные 1:1 (глобальные) адреса.

>> Запуск эмиттеров...                                                           
R1[2811708]: новые многоадресные данные от 192.168.10.1 до группы 225.1.2.3 на VIF 1.
R1[2811708]: добавить 192.168.10.1 -> 225.1.2.3 из VIF 1
R2[2811709]: Новые многоадресные данные от 192.168.10.1 до группы 225.1.2.3 на VIF 0
R2[2811709]: добавить 192.168.10.1 -> 225.1.2.3 из VIF 0
R2[2811709]: новые многоадресные данные от 192.168.20.1 до группы 225.1.2.3 на VIF 1.
R2[2811709]: добавить 192.168.20.1 -> 225.1.2.3 из VIF 1
R1[2811708]: Новые многоадресные данные от 192.168.20.1 до группы 225.1.2.3 на VIF 0
R1[2811708]: добавить 192.168.20.1 -> 225.1.2.3 из VIF 0
>> Многоадресные маршруты R1 и NAT 1:1...                                             
(192.168.10.1,225.1.2.3) Iif: eth1 Oifs: eth0 Состояние: разрешено
(192.168.20.1,225.1.2.3) Iif: eth0 Oifs: eth1 Состояние: разрешено
Цепочка PREROUTING (политика ACCEPT 5 пакетов, 244 байта)
 pkts bytes target prot opt ​​in out source target         
    0 0 NETMAP все -- любой любой везде 192.168.10.0/24 to:10.0.0.0/24

Цепочка INPUT (политика ACCEPT 1 пакетов, 84 байта)
 pkts bytes target prot opt ​​in out source target         

Цепочка OUTPUT (политика ACCEPT 4 пакета, 248 байт)
 pkts bytes target prot opt ​​in out source target         

Цепочка POSTROUTING (политика ACCEPT 2 пакета, 124 байта)
 pkts bytes target prot opt ​​in out source target         
    2 124 NETMAP все -- любой любой 10.0.0.0/24 куда угодно до:192.168.10.0/24
>> Многоадресные маршруты R2 и NAT 1:1...                                             
(192.168.10.1,225.1.2.3) Iif: eth0 Oifs: eth1 Состояние: разрешено
(192.168.20.1,225.1.2.3) Iif: eth1 Oifs: eth0 Состояние: разрешено
Цепочка PREROUTING (политика ACCEPT 4 пакета, 204 байта)
 pkts bytes target prot opt ​​in out source target         
    1 84 NETMAP все -- любой любой любой 192.168.20.0/24 to:10.0.0.0/24

Цепочка INPUT (политика ACCEPT 2 пакета, 168 байт)
 pkts bytes target prot opt ​​in out source target         

Цепочка OUTPUT (политика ACCEPT 3 пакета, 164 байта)
 pkts bytes target prot opt ​​in out source target         

Цепочка POSTROUTING (политика ACCEPT 1 пакета, 40 байт)
 pkts bytes target prot opt ​​in out source target         
    2 124 NETMAP все -- любой любой 10.0.0.0/24 куда угодно до:192.168.20.0/24
>> Анализ...                                                                   
    1 0,000000000 0,000000000 192.168.10.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe769, seq=1/256, ttl=2
    2 1.000105261 1.000105261 192.168.10.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe769, seq=2/512, ttl=2
    3 1.000957268 0.000852007 192.168.20.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe76b, seq=1/256, ttl=2
    4 2.024216212 1.023258944 192.168.10.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe769, seq=3/768, ttl=2
    5 2.024216229 0.000000017 192.168.20.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe76b, seq=2/512, ttl=2
    6 3.048426868 1.024210639 192.168.10.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe769, seq=4/1024, ttl=2
    7 3.048426842 -0.000000026 192.168.20.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe76b, seq=3/768, ttl=2
    8 4.072270331 1.023843489 192.168.10.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe769, seq=5/1280, ttl=2
    9 4.072270458 0.000000127 192.168.20.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe76b, seq=4/1024, ttl=2
   10 5.096430449 1.024159991 192.168.20.1 – 225.1.2.3 ICMP 98 Эхо-запрос (ping) id=0xe76b, seq=5/1280, ttl=2
 => 10 для группы ff04::114, ожидается >= 8

Это может быть немного сложно читать, вам, возможно, придется проконсультироваться с тестовым примером для деталей. В любом случае, я получаю стабильные результаты при переводе, за который, кстати, отвечает Linux, а не SMCRoute, так что у вас может быть ошибка ядра или что-то в этом роде. Может ли персональная рабочая станция иметь Linux Mint с ядром 5.11.0, а внутренние серверы для GitHub Actions работают под управлением Ubuntu 20.04 LTS, ядро ​​5.8.0, ядра обоих дистрибутивов с довольно исправленными исправлениями, но, может быть, это основа для начала?

0 + 0
флаг us
ncoghlan
Спасибо! Знание того, что это *должно* работать, по крайней мере, дает мне понять, что я не полностью испортил конфигурацию :) Неправильное поведение изначально было выявлено в Debian 9, который на данный момент довольно древний. У меня должна быть система с ядром 5.14.x для тестирования в недалеком будущем, но я также просмотрю журналы изменений ядра 4.9 LTS, чтобы увидеть, есть ли какие-либо правдоподобно связанные отчеты об ошибках.
0
Ответить
флаг us
ncoghlan
Просматривая https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?qt=grep&q=multicast, я начинаю задаваться вопросом, не упустил ли я что-то из описания сценария чтобы упростить объяснение, на самом деле важно спровоцировать проблему: встроенные сети физически не разделены, это разные VLAN на помеченном магистральном соединении VLAN. Это вводит в действие многоадресную обработку моста ядра в дополнение ко всему остальному :(
0
Ответить
флаг us
ncoghlan
Итак, предварительная гипотеза, основанная на этом ответе и просмотре сообщений фиксации ядра за последние пару лет, в которых упоминается «многоадресная рассылка»: в старых ядрах может быть проблема, которая была устранена различными обновлениями моста и обработки многоадресной рассылки macvlan в новых ядра. Следующие шаги будут заключаться в том, чтобы увидеть, можно ли воспроизвести проблему с ядром 4.9.283 (последняя версия LTS для Debian 9) или даже с более новым ядром 5.8.0+.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.