iptables NETMAP ненадежно корректирует адрес источника многоадресных UDP-пакетов
В случае использования встраиваемых систем/IoT у меня есть управляющий узел под управлением Linux, который должен иметь возможность общаться с несколькими сетями, каждая из которых использует общий набор статических IP-адресов.
Это в основном работает хорошо, в том числе для многоадресного трафика UDP, учитывая:
- сетевые ссылки для каждой встроенной сети (назовем их
eth1,eth2, и т.д.) - отдельное пространство имен сети Linux для каждой отдельной встроенной сети (назовем их
ns1,ns2, и т.д.) - одноранговая ссылка между каждым пространством имен сети и корневым пространством имен (назовем их
peer1,peer2, etc со стороны сетевого пространства имен иveth1,veth2, etc со стороны корневого пространства имен) - правило iptables NETMAP в каждом пространстве имен для отображения конфликтующей статической IP подсети (назовите его
192. 168.0.x) в неконфликтующий набор статических IP-подсетей (назовем их192. 168.1.x,192.168.2.xи т.д.) - экземпляр
smcroutedвнутри каждого сетевого пространства имен для пересылки регистраций многоадресных групп - отдельный IP-адрес в отдельной (не NAT) подсети для корневого пространства имен на стороне пиринговых соединений, чтобы обойти тему этого вопроса (назовем его
192.168.(x+100). 1)
Чтобы попытаться визуализировать потоки трафика:
[|root namespace|::veth1] <-> [peer1::(namespace ns1)::eth1] <-> embedded network
[| |::veth2] <-> [peer2::(namespace ns2)::eth2] <-> embedded network
... etc ...
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 пример smcrouted правил конфигурации для поддерживаемой многоадресной группы:
mgroup from eth1 group 239.255.60.60
mgroup from peer1 group 239.255.60.60
mroute from eth1 group 239.255.60.60 to peer1
mroute from peer1 source 192.168.101.1 group 239.255.60.60 to eth1
На самом деле тема этого вопроса заключается в том, что в NETMAP настройке IP источника есть странный глюк, который я не смог объяснить, только обойти.
Ожидаемое поведение:
- UDP multicast подписки в сетевом пространстве имен будут видеть немодифицированные до NETMAP
192.168.0.xадреса источников - UDP multicast подписки в корневом пространстве имен будут видеть модифицированные после NETMAP
192.168.1.xадреса источников
Однако этого не происходит. Вместо этого либо подписчики в обоих пространствах имен видят адреса источников 192.168.0.x до NETMAP, либо 192.168.1.x после NETMAP.
Фильтр source на правиле mroute from peer1 в конфигурации smcroute существует для предотвращения петли многоадресной маршрутизации, которая в противном случае начинается, когда сервер переключается на второй набор поведения.
Пока что я не смог определить, что вызывает переход между двумя состояниями, только обойти проблему на прикладном уровне, регулируя на основе активного сетевого пространства имен или сетевого интерфейса источника, когда информация об адресе источника выглядит неверной.
Цель вопроса - помочь выяснить, что из этого применимо:
- ожидается, что это не сработает, компенсация на прикладном уровне - лучшее, что можно сделать (что кажется маловероятным, учитывая использование сетевых пространств имен в контейнерных средах 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-серверов)
.Maintainer of SMCRoute здесь. Это определенно должно сработать. Мы используем именно этот подход, хотя и с реальным аппаратным обеспечением, а не сетевыми пространствами имен, для различных клиентов на работе.
В системе отслеживания ошибок SMCRoute сообщается об очень похожей проблеме, единственное отличие от вас в том, что они не используют NAT 1:1 с сетевой картой (пока).
Я подготовил тестовый пример для этого в рамках подготовки к следующему релизу (v2.5). Я запускаю все тесты локально и в GitHub Actions (облако Azure), используя:
cd test/
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 (глобальные) адреса.
>> Starting emitters ...
R1[2811708]: New multicast data from 192.168.10.1 to group 225.1.2.3 on VIF 1
R1[2811708]: Add 192.168.10.1 -> 225.1.2.3 from VIF 1
R2[2811709]: New multicast data from 192.168.10.1 to group 225.1.2.3 on VIF 0
R2[2811709]: Add 192.168.10.1 -> 225.1.2.3 from VIF 0
R2[2811709]: New multicast data from 192.168.20.1 to group 225.1.2.3 on VIF 1
R2[2811709]: Add 192.168.20.1 -> 225.1.2.3 from VIF 1
R1[2811708]: New multicast data from 192.168.20.1 to group 225.1.2.3 on VIF 0
R1[2811708]: Add 192.168.20.1 -> 225.1.2.3 from VIF 0
>> R1 multicast routes and 1:1 NAT ...
(192.168.10.1,225.1.2.3) Iif: eth1 Oifs: eth0 State: resolved
(192.168.20.1,225.1.2.3) Iif: eth0 Oifs: eth1 State: resolved
Chain PREROUTING (policy ACCEPT 5 packets, 244 bytes)
pkts bytes target prot opt in out source destination
0 0 NETMAP all -- any any anywhere 192.168.10.0/24 to:10.0.0.0/24
Chain INPUT (policy ACCEPT 1 packets, 84 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 4 packets, 248 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 2 packets, 124 bytes)
pkts bytes target prot opt in out source destination
2 124 NETMAP all -- any any 10.0.0.0/24 anywhere to:192.168.10.0/24
>> R2 multicast routes and 1:1 NAT ...
(192.168.10.1,225.1.2.3) Iif: eth0 Oifs: eth1 State: resolved
(192.168.20.1,225.1.2.3) Iif: eth1 Oifs: eth0 State: resolved
Chain PREROUTING (policy ACCEPT 4 packets, 204 bytes)
pkts bytes target prot opt in out source destination
1 84 NETMAP all -- any any anywhere 192.168.20.0/24 to:10.0.0.0/24
Chain INPUT (policy ACCEPT 2 packets, 168 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 3 packets, 164 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 1 packets, 40 bytes)
pkts bytes target prot opt in out source destination
2 124 NETMAP all -- any any 10.0.0.0/24 anywhere to:192.168.20.0/24
>> Analyzing ...
1 0.000000000 0.000000000 192.168.10.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe769, seq=1/256, ttl=2
2 1.000105261 1.000105261 192.168.10.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe769, seq=2/512, ttl=2
3 1.000957268 0.000852007 192.168.20.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe76b, seq=1/256, ttl=2
4 2.024216212 1.023258944 192.168.10.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe769, seq=3/768, ttl=2
5 2.024216229 0.000000017 192.168.20.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe76b, seq=2/512, ttl=2
6 3.048426868 1.024210639 192.168.10.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe769, seq=4/1024, ttl=2
7 3.048426842 -0.000000026 192.168.20.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe76b, seq=3/768, ttl=2
8 4.072270331 1.023843489 192.168.10.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe769, seq=5/1280, ttl=2
9 4.072270458 0.000000127 192.168.20.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe76b, seq=4/1024, ttl=2
10 5.096430449 1.024159991 192.168.20.1 → 225.1.2.3 ICMP 98 Echo (ping) request id=0xe76b, seq=5/1280, ttl=2
=> 10 for group ff04::114, expected >= 8
Это может быть немного трудно читать, вам, возможно, придется проконсультироваться с тестовым примером для деталей. В любом случае, я получаю стабильные результаты при переводе, за который, кстати, отвечает Linux, а не SMCRoute, так что у вас может быть ошибка ядра или что-то в этом роде. Может ли персональная рабочая станция иметь Linux Mint с ядром 5.11.0, а внутренние серверы для GitHub Actions работают под управлением Ubuntu 20.04 LTS, ядро 5.8.0, ядра обоих дистрибутивов с исправленными исправлениями, но, может быть, это базовый уровень для начала?