înregistrare Logare
Puncte:0
avatar Server

iptables NETMAP nu ajustează în mod fiabil adresa sursă a pachetelor UDP multicast

drapel us
ncoghlan

Într-un caz de utilizare încorporat/IoT, am o gazdă de management care rulează Linux care trebuie să poată vorbi cu mai multe rețele care utilizează fiecare un set comun de adrese IP statice.

Acest lucru funcționează în mare parte bine, inclusiv pentru traficul multicast UDP, având în vedere:

  • legături de rețea pentru fiecare rețea încorporată (numiți-le et1, et2, etc)
  • un spațiu de nume de rețea Linux separat pentru fiecare rețea încorporată diferită (numiți-le ns1, ns2, etc)
  • o legătură peer între fiecare spațiu de nume de rețea și spațiul de nume rădăcină (numiți-le peer1, peer2, etc din partea spațiului de nume de rețea și veth1, veth2, etc din partea spațiului de nume rădăcină)
  • o regulă iptables NETMAP în fiecare spațiu de nume pentru a mapa subrețeaua IP statică aflată în conflict (numiți-o 192.168.0.x) la un set neconflictual de subrețele IP statice (numiți-le 192.168.1.x, 192.168.2.x, etc)
  • un smcrouted instanță în interiorul fiecărui spațiu de nume de rețea pentru a transmite înregistrări de grup multicast
  • o adresă IP separată într-o subrețea distinctă (non-NAT) pentru partea rădăcină a spațiului de nume a legăturilor peer pentru a rezolva subiectul acestei întrebări (numiți-o 192.168.(x+100).1)

Pentru a încerca să vizualizați fluxurile de trafic:

[|spațiu de nume rădăcină|::veth1] <-> [peer1::(spațiu de nume ns1)::eth1] <-> rețea încorporată
[| |::veth2] <-> [peer2::(namespace ns2)::eth2] <-> rețea încorporată
... etc ...

ns1 exemplu de reguli NETMAP pentru subrețelele IP statice:

sudo -n ip netns exec ns1 iptables -t nat -A PREROUTING -d 192.168.1.0/24 -i peer1 -j NETMAP --la 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 --la 192.168.1.0/24

ns1 exemplu smcrouted reguli de configurare pentru un grup multicast acceptat:

mgroup din eth1 grup 239.255.60.60
mgroup din peer1 grup 239.255.60.60
mroute de la grupul eth1 239.255.60.60 la peer1
mroute de la sursa peer1 192.168.101.1 grup 239.255.60.60 la eth1

Subiectul real al acestei întrebări este că există o eroare ciudată în NETMAP Ajustarea IP-ului sursă pe care nu am reușit să o explic, ci doar să o rezolv.

Comportamentul meu așteptat:

  • Abonamentele UDP multicast în interiorul spațiului de nume ale rețelei vor vedea pre-NETMAP nemodificat 192.168.0.x adresele sursei
  • Abonamentele UDP multicast din interiorul spațiului de nume rădăcină vor vedea modificarea post-NETMAP 192.168.1.x adresele sursei

Nu asta se întâmplă, totuși. În schimb, fie abonații din ambele spații de nume văd adresele sursă 192.168.0.x pre-NETMAP, fie văd adresele post-NETMAP 192.168.1.x.

The sursă filtru pe mroute de la peer1 regulă în smcroute configurația este acolo pentru a preveni o buclă de rutare multicast care altfel începe atunci când serverul trece la al doilea set de comportament.

Până acum nu am reușit să stabilesc ce cauzează tranziția dintre cele două stări, rezolv problema doar la nivelul aplicației, ajustând pe baza spațiului de nume activ al rețelei sau a interfeței rețelei sursă atunci când informațiile despre adresa sursă arată greșit.

Scopul punerii întrebării este de a ajuta la a afla care dintre următoarele se aplică:

  • acest lucru nu este de așteptat să funcționeze, compensarea la nivelul aplicației este cea mai bună care se poate face (ceea ce pare puțin probabil având în vedere utilizarea spațiilor de nume de rețea în mediile de containere Linux)
  • mai este ceva care trebuie configurat (sau nu) în nucleu, iptables sau smcroute pentru a împiedica comportamentul inadecvat să se întâmple

(Notă: aceasta este o întrebare super-ezoterică, foarte specifică, așa că m-am întrebat dacă Ingineria rețelei ar putea fi mai potrivită, dar https://networkengineering.stackexchange.com/questions/64744/linux-local-multicast-egress-follows-forward-chain-when-smcroute-is-active a precizat că aceasta este pentru lucrul cu routere comerciale etc., nu pentru configurarea spațiului de nume de rețea Linux. Cu toate acestea, sunt mai puțin clar granițele dintre Server Fault și schimbul de stive Unix și Linux atunci când vine vorba de configurarea serverelor Linux)

194
1 + 0
Puncte:1
avatar Server
drapel tr
troglobit

Menţinător al SMCRoute Aici. Acest lucru ar trebui să funcționeze cu siguranță. Folosim această abordare exactă, deși cu HW real și nu cu spații de nume de rețea, pentru diverși clienți la locul de muncă.

Există o problemă foarte similară raportată în Urmăritorul problemelor SMCRoute, singura diferență față de tine este că nu folosesc NAT 1:1 cu netmap (încă).

Am adunat un caz de testare pentru aceasta în pregătirea următoarei versiuni (v2.5). Rulez toate testele local și în GitHub Actions (Azure cloud) folosind:

test cd/
unshare -mrun ./multi.sh

Testul are două routere separate (R1 și R2) în spații de nume de rețea dedicate, cu un segment LAN partajat între ele (192.168.0.0/24). În spatele fiecărui router este un LAN privat (10.0.0.0/24), care este același pentru ambele routere. O interfață suplimentară (fictivă) eth1 este utilizată pentru a ruta multicast de la LAN partajat (eth0). Regula NETMAP folosește lanțul PREROUTING și POSTROUTING. Traducerea LAN-ului privat R1 la 192.168.10.0/24 și a LAN-ului privat R2 la 192.168.20.0/24. După cum puteți vedea mai jos, rutele multicast instalate în nucleu folosesc adresele mapate 1:1 (globale).

>> Pornirea emițătorilor...                                                           
R1[2811708]: noi date multicast de la 192.168.10.1 la grupul 225.1.2.3 pe VIF 1
R1[2811708]: Adăugați 192.168.10.1 -> 225.1.2.3 din VIF 1
R2[2811709]: noi date multicast de la 192.168.10.1 la grupul 225.1.2.3 pe VIF 0
R2[2811709]: Adăugați 192.168.10.1 -> 225.1.2.3 din VIF 0
R2[2811709]: noi date multicast de la 192.168.20.1 la grupul 225.1.2.3 pe VIF 1
R2[2811709]: Adăugați 192.168.20.1 -> 225.1.2.3 din VIF 1
R1[2811708]: noi date multicast de la 192.168.20.1 la grupul 225.1.2.3 pe VIF 0
R1[2811708]: Adăugați 192.168.20.1 -> 225.1.2.3 din VIF 0
>> Rute multicast R1 și NAT 1:1...                                             
(192.168.10.1,225.1.2.3) Iif: eth1 Oifs: eth0 Stare: rezolvat
(192.168.20.1,225.1.2.3) Iif: eth0 Oifs: eth1 Stare: rezolvat
PRERUUTARE în lanț (politica ACCEPTĂ 5 pachete, 244 de octeți)
 pkts bytes target prot opt ​​in out source destination         
    0 0 NETMAP toate -- orice oriunde oriunde 192.168.10.0/24 la:10.0.0.0/24

INTRARE în lanț (politica ACCEPTĂ 1 pachet, 84 de octeți)
 pkts bytes target prot opt ​​in out source destination         

IEȘIRE în lanț (politica ACCEPTĂ 4 pachete, 248 octeți)
 pkts bytes target prot opt ​​in out source destination         

POSTROUTING în lanț (politica ACCEPTĂ 2 pachete, 124 de octeți)
 pkts bytes target prot opt ​​in out source destination         
    2 124 NETMAP toate -- orice orice 10.0.0.0/24 oriunde la:192.168.10.0/24
>> Rute multicast R2 și NAT 1:1...                                             
(192.168.10.1,225.1.2.3) Iif: eth0 Oifs: eth1 Stare: rezolvat
(192.168.20.1,225.1.2.3) Iif: eth1 Oifs: eth0 Stare: rezolvat
PRERUUTARE în lanț (politica ACCEPTĂ 4 pachete, 204 octeți)
 pkts bytes target prot opt ​​in out source destination         
    1 84 NETMAP toate -- orice oriunde oriunde 192.168.20.0/24 la:10.0.0.0/24

INTRARE în lanț (politica ACCEPTĂ 2 pachete, 168 octeți)
 pkts bytes target prot opt ​​in out source destination         

IEȘIRE în lanț (politica ACCEPTĂ 3 pachete, 164 de octeți)
 pkts bytes target prot opt ​​in out source destination         

POSTROUTING în lanț (politica ACCEPTĂ 1 pachet, 40 de octeți)
 pkts bytes target prot opt ​​in out source destination         
    2 124 NETMAP toate -- orice orice 10.0.0.0/24 oriunde la:192.168.20.0/24
>> Se analizează...                                                                   
    1 0,000000000 0,000000000 192.168.10.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe769, seq=1/256, ttl=2
    2 1.000105261 1.000105261 192.168.10.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe769, seq=2/512, ttl=2
    3 1.000957268 0.000852007 192.168.20.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe76b, seq=1/256, ttl=2
    4 2.024216212 1.023258944 192.168.10.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe769, seq=3/768, ttl=2
    5 2.024216229 0.000000017 192.168.20.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe76b, seq=2/512, ttl=2
    6 3.048426868 1.024210639 192.168.10.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe769, seq=4/1024, ttl=2
    7 3.048426842 -0.000000026 192.168.20.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe76b, seq=3/768, ttl=2
    8 4.072270331 1.023843489 192.168.10.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe769, seq=5/1280, ttl=2
    9 4.072270458 0.000000127 192.168.20.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe76b, seq=4/1024, ttl=2
   10 5.096430449 1.024159991 192.168.20.1 â 225.1.2.3 ICMP 98 Echo (ping) cerere id=0xe76b, seq=5/1280, ttl=2
 => 10 pentru grupul ff04::114, așteptat >= 8

Poate că este puțin greu de citit, poate fi necesar să consultați cazul de testare pentru detalii. Oricum, obțin rezultate consistente în traducere, care, de altfel, este responsabilitatea Linuxului, nu a SMCRoute, așa că este posibil să aveți o eroare de kernel sau ceva de genul. Stația de lucru personală poate să aibă Linux Mint cu kernel 5.11.0, iar serverele backend pentru GitHub Actions rulează Ubuntu 20.04 LTS, kernel 5.8.0, ambele nuclee de distribuție destul de corectate, dar poate o bază de la care să începeți?

0 + 0
drapel us
ncoghlan
Mulțumesc! Știind că *ar trebui* să funcționeze măcar îmi permite să știu că nu am încurcat complet configurația :) Comportamentul greșit a fost identificat inițial pe Debian 9, care este destul de veche în acest moment. Ar trebui să am un sistem cu un nucleu 5.14.x de testat într-un viitor nu prea îndepărtat, dar voi scana și jurnalele de modificări ale nucleului 4.9 LTS pentru a vedea dacă există rapoarte de eroare plauzibil.
0
Răspunde
drapel us
ncoghlan
Răsfoind prin https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?qt=grep&q=multicast, încep să mă întreb dacă am omis ceva din descrierea scenariului a încerca să fie mai ușor de explicat este de fapt esențial pentru a provoca problema: rețelele încorporate nu sunt separate fizic, sunt VLAN-uri diferite pe o conexiune trunk VLAN etichetată. Asta aduce în joc gestionarea multicast-ului bridge-ului pe lângă orice altceva :(
0
Răspunde
drapel us
ncoghlan
Așadar, ipoteză tentativă bazată pe acest răspuns și răsfoind ultimii doi ani de mesaje de comitere a nucleului care menționează „multicast”: poate exista o problemă în nucleele mai vechi care a fost rezolvată de diferitele actualizări ale bridge-ului și gestionării multicast macvlan în mai noi. miezuri. Următorii pași vor fi să vedem dacă problema poate fi reprodusă cu un nucleu 4.9.283 (cea mai recentă versiune LTS pentru Debian 9) sau cu un nucleu 5.8.0+ și mai nou.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.