Kodėl multicast neperžengia VPN be plano

Dvi vietos gali puikiai pasiekti viena kitą unicast ryšiu ir vis tiek elgtis taip, tarsi viena jų nemato spausdintuvo aptikimo pranešimo, IPTV srauto ar klasterio širdies plakimo. Tai ne sugedęs tunelis; tai skirtumas tarp tikslo ir grupės. Multicast pristatymui reikia narystės modelio, persiuntimo būsenos kelyje ir sąsajos, pasirengusios perduoti srautą, ir nė vieno iš jų negaunama iš unicast maršruto. Ėjimas nuo programos grupės iki vieno veikiančio gavėjo yra trumpiausias kelias iki atsakymo.

Pradėkite nuo grupės ir programos

Paklauskite, kokį grupės adresą naudoja programa ir kam skirtas srautas. Paslaugas skelbiantis aptikimo protokolas, transliacijos srautas ir maršrutizavimo protokolo pasisveikinimo paketai yra trys skirtingos problemos su trimis skirtingais priimtinais atsakymais. Pats grupės adresas nurodo apimtį: vietinio tinklo valdymo bloko adresai nėra skirti įprasto maršrutizavimo perduoti už ryšio ribų, o juos naudojančios programos paprastai daro prielaidą, kad yra viena transliavimo sritis. Visuotinės apimties grupės transliacijos srautas yra kitokia konstrukcija nei aptikimo protokolas, kuris tikisi, kad kiekvienas įrenginys išgirs kiekvieną užklausą, ir tik antrajam rūpi transliavimo srities dydis.

Nuspręskite, ar reikalavimas yra paslauga, ar aptikimo mechanizmas, nes šie atsakymai skiriasi kaina eile. Vienas prašo adreso, kuris nesikeičia; kitas prašo transliavimo sritį, išplėstą per didelio ploto tinklo ryšį ir visko, kas iš to išplaukia.

Vietinis aptikimas turėtų sustoti

RFC 6762 aprašytas Multicast DNS sukurtas vieno ryšio pagrindu: užklausos eina į fiksuotą grupę, atsakymai siunčiami tai pačiai grupei, o protokolas remiasi tuo, kad kiekvienas dalyvis girdi visus. Maršrutizatoriai šio srauto pagal nutylėjimą nepersiunčia, ir tai yra projektinis sprendimas, o ne apsirikimas. Riba egzistuoja todėl, kad įrenginys viename pastate negalėtų lengvai paskelbti savęs kitame. Tunelis, kuris atrodo taisantis aptikimą nešdamas grupę visur, tą ribą panaikino kiekvienai programai, ne tik tai, kuriai reikėjo pagalbos.

Kartotuvai ir atspindėtojai egzistuoja, ir tai tikros paslaugos su tikromis pasekmėmis: kiekvienas vienoje vietoje paskelbtas vardas tampa matomas kitoje, įskaitant įrenginių vardus, kurie identifikuoja žmones ar įrangą. Jei tikrasis reikalavimas yra tai, kad konkreti paslauga būtų randama, DNS paskelbtas paslaugos įrašas paprastai yra mažesnis pakeitimas, ir jis atskleidžia vieną vardą, o ne jų srautą.

Trys dalykai, kurių reikia maršrutizuotam multicast

Maršrutizuotam multicast reikia trijų dalykų, veikiančių kartu: gavėjų, prisijungiančių prie grupės, maršrutizatorių, palaikančių jai persiuntimo būseną, ir tunelio, kuris grupės adresus traktuoja kaip perduodamą srautą. Tunelis, kurio politika išvardija tik unicast potinklius, numes grupės srautą ties šifravimo riba, todėl pirmasis simptomas dažnai yra tyla, o ne klaida. Maršrutais pagrįsta sąsaja, pavyzdžiui, GRE arba VTI tunelis, perduoda tai, ką į ją siunčia maršrutizavimo lentelė, ir tai padaro grupę pasiekiamą, kai tik yra multicast būsena.

Šaltinio pasiekiamumas yra antroji pusė. Multicast maršrutizavimo protokolai, tokie kaip PIM, stato paskirstymo medžius tikrindami, ar kelias atgal į šaltinį yra laukiamas, todėl unicast maršrutas, rodantis kitur, sugriauna medį net tada, kai grupės narystė yra teisinga. Maršruto gavėjui įdiegimas nieko neduoda šiam patikrinimui, ir tai yra klaida, dėl kurios ping veikia, o srautas nepavyksta. Pirmiausia patikrinkite šaltinio grįžimo kelią, tada pridėkite narystę ir tik po to žiūrėkite į programą.

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

Pirmosios dvi eilutės rodo, prie ko prisijungė hostas ir ką persiunčia branduolys, trečioji rodo pačios programos narystę, o paskutinė – unicast kelią, kurį naudos atvirkštinio kelio patikra. Skaitymas kartu atskiria programą, kuri niekada neprisijungė, nuo tinklo, kuris niekada nepersiuntė.

Įrodykite tai vienu šaltiniu ir vienu gavėju

Prieš liesdami konfigūraciją įsitikinkite, kad programa veikia viename segmente. Jei ji nepavyksta vietiškai, multicast maršrutizavimas nėra problema ir joks tunelio pakeitimas nepadės. Tada pakartokite su vienu gavėju per tunelį ir stebėkite paketus abiejose šifravimo ribos pusėse.

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

Paketai, matomi tunelio viduje, bet nesantys už jo, rodo inkapsuliavimą arba politiką; paketai, matomi abiejose pusėse be programos pažangos, rodo gavėjo narystę arba programos susiejimą. Laikykite įrašus trumpus ir filtruotus, nes platus multicast įrašas užimtame segmente daugiausia yra triukšmas.

Rinkitės paslaugos adresą, kai reikia tik paslaugos

Aptikimas egzistuoja tam, kad rastų ką nors judančio. Serveriui su stabiliu vardu aptikimo nereikia, o privačiame DNS dokumentuotas adresas atsako į tikrąjį vartotojo klausimą neišplečiant transliavimo srities per didelio ploto tinklo ryšį. Ta pati logika galioja spausdintuvams, prietaisams ir vidinėms žiniatinklio paslaugoms. Vardas DNS yra pasiekiamas iš kiekvienos vietos, kurios jam reikia, nieko neskelbdamas vietoms, kurioms nereikia, ir jis toliau veikia, kai įrenginys pakeičiamas kitu su skirtingu adresu.

Kai protokolas tikrai reikalauja multicast, apribokite jį grupe ir vietomis, kurioms jo reikia, dokumentuokite kodėl, ir peržiūrėkite sprendimą, kai programa pasikeis. Aptikimo išplėtimas visur yra lengvas vieną kartą, ir sunku atšaukti po metų įrenginių, kurie tyliai nuo jo priklauso.