De ce multicast nu traversează un VPN fără un plan

Două locații se pot atinge perfect prin unicast și totuși se pot comporta ca și cum una dintre ele nu vede anunțul de descoperire al imprimantei, fluxul IPTV sau bătăile inimii clusterului. Acesta nu este un tunel defect; este diferența dintre o destinație și un grup. Livrarea multicast are nevoie de un model de apartenență, de starea de forwardare de-a lungul căii și de o interfață dispusă să transporte traficul, iar nimic din toate acestea nu vine dintr-o rută unicast. Mersul de la grupul aplicației la un receptor funcțional este cea mai scurtă cale către un răspuns.

Începeți cu grupul și aplicația

Întrebați ce adresă de grup folosește aplicația și pentru ce este traficul. Un protocol de descoperire care anunță servicii, un flux de streaming și pachetele hello ale unui protocol de rutare sunt trei probleme diferite cu trei răspunsuri acceptabile diferite. Adresa grupului în sine spune domeniul: adresele din blocul de control al rețelei locale nu sunt destinate să fie forwardate în afara legăturii de rutarea obișnuită, iar aplicațiile care le folosesc presupun de obicei un singur domeniu de difuzare. Un flux de streaming pe un grup cu domeniu global este un alt proiect decât un protocol de descoperire care așteaptă ca fiecare dispozitiv să audă fiecare interogare, și doar al doilea se preocupă de dimensiunea domeniului de difuzare.

Decideți dacă cerința este serviciul sau mecanismul de descoperire, pentru că aceste răspunsuri diferă ca cost cu un ordin de mărime. Unul cere o adresă care nu se schimbă; celălalt cere un domeniu de difuzare extins peste o legătură de arie largă cu tot ce decurge din el.

Descoperirea locală ar trebui să se oprească

Multicast DNS, așa cum este descris în RFC 6762, este proiectat în jurul unei singure legături: interogările merg la un grup fix, răspunsurile sunt trimise aceluiași grup, iar protocolul se bazează pe faptul că fiecare participant îi aude pe toți. Routerele nu forwardează acel trafic implicit, iar aceasta este o decizie de proiectare, nu o scăpare. Granița există pentru ca un dispozitiv dintr-o clădire să nu se poată anunța lejer în alta. Un tunel care pare să repare descoperirea ducând grupul peste tot a eliminat acea graniță pentru fiecare aplicație, nu doar pentru cea care avea nevoie de ajutor.

Repetitoarele și reflectoarele există și sunt servicii reale cu consecințe reale: fiecare nume anunțat într-o locație devine vizibil în cealaltă, inclusiv numele de dispozitiv care identifică persoane sau echipamente. Dacă cerința reală este ca un anumit serviciu să fie găsibil, o înregistrare de serviciu publicată în DNS este de obicei cea mai mică schimbare și dezvăluie un singur nume în locul unui șir de nume.

Trei lucruri de care are nevoie multicastul rutat

Multicastul rutat are nevoie de trei lucruri care lucrează împreună: receptori care se alătură grupului, routere care mențin starea de forwardare pentru el și un tunel care tratează adresele de grup ca trafic de transportat. Un tunel cu o politică ce listează doar subrețele unicast va arunca traficul grupului la granița de criptare, motiv pentru care primul simptom este adesea tăcerea, nu o eroare. O interfață bazată pe rute, cum ar fi un tunel GRE sau VTI, transportă ce îi trimite tabela de rutare, ceea ce face grupul accesibil de îndată ce starea multicast există.

Accesibilitatea sursei este a doua jumătate. Protocoalele de rutare multicast precum PIM construiesc arbori de distribuție verificând că drumul înapoi la sursă este cel așteptat, așa că o rută unicast care indică în altă parte rupe arborele chiar și atunci când apartenența la grup este corectă. Instalarea unei rute pentru receptor nu face nimic pentru acea verificare, și aceasta este greșeala care produce un ping funcțional și un flux care eșuează. Verificați mai întâi calea de întoarcere a sursei, apoi adăugați apartenența și abia după aceea priviți aplicația.

ip maddr show dev tun0
ip mroute show
ss -gnu | grep 239.255.0.10
ip route get 10.20.5.20

Primele două linii arată la ce s-a alăturat gazda și ce forwardează nucleul, a treia arată apartenența aplicației înseși, iar ultima calea unicast pe care o va folosi verificarea căii inverse. Citirea lor împreună distinge o aplicație care nu s-a alăturat niciodată de o rețea care nu a forwardat niciodată.

Demonstrați cu o singură sursă și un singur receptor

Înainte de a atinge o configurație, confirmați că aplicația funcționează pe un singur segment. Dacă eșuează local, rutarea multicast nu este problema și nicio modificare a tunelului nu va ajuta. Apoi repetați cu un singur receptor prin tunel și urmăriți pachetele pe ambele părți ale graniței de criptare.

tcpdump -ni tun0 -c 10 'ip multicast'
tcpdump -ni eth0 -c 10 'ip multicast and host 239.255.0.10'

Pachetele vizibile în interiorul tunelului dar absente în afara lui indică încapsulare sau politică; pachetele vizibile pe ambele părți fără progres al aplicației indică apartenența receptorului sau legarea aplicației. Păstrați capturile scurte și filtrate, pentru că o captură multicast largă pe un segment aglomerat este în mare parte zgomot.

Preferați o adresă de serviciu când aveți nevoie doar de serviciu

Descoperirea există pentru a găsi ceva care se mișcă. Un server cu un nume stabil nu are nevoie de descoperire, iar o adresă documentată în DNS privat răspunde la întrebarea reală a utilizatorului fără a extinde un domeniu de difuzare peste o legătură de arie largă. Același raționament se aplică imprimantelor, aparatelor și serviciilor web interne. Un nume în DNS este accesibil din fiecare locație care are nevoie de el fără a anunța nimic locațiilor care nu au nevoie, și continuă să funcționeze când dispozitivul este înlocuit cu unul cu o altă adresă.

Când un protocol cere cu adevărat multicast, limitați-l la grup și la locațiile care au nevoie de el, documentați de ce și revizuiți decizia când aplicația se schimbă. Extinderea descoperirii peste tot este ușor de făcut o dată și greu de retras după un an de dispozitive care depind discret de ea.