Af hverju multicast fer ekki yfir VPN án áætlunar

Tveir staðir geta náð hvor til annars fullkomlega með unicast og hegðað sér samt eins og annar þeirra sjái ekki tilkynningu um uppgötvun prentarans, IPTV-strauminn eða hjartslátt klasans. Þetta er ekki brotinn göng; þetta er munurinn á áfangastað og hópi. Sending multicast krefst aðildarlíkans, framsendingarstöðu meðfram leiðinni og viðmóts sem er reiðubúið að bera umferðina, og ekkert þess kemur frá unicast-leið. Að ganga frá hópi forritsins að einum virkum móttakanda er stysta leiðin að svari.

Byrjaðu á hópnum og forritinu

Spyrðu hvaða hópval forritið notar og hvers vegna umferðin er. Uppgötvunarprotokoll sem tilkynnir þjónustur, streymisstraumur og halló-pakkar beiningarprotokolls eru þrjú mismunandi vandamál með þrjú mismunandi ásættanleg svör. Hópvangið sjálft segir umfangið: föng í stjórnblokki staðbundins nets eru ekki ætluð til að vera send út af tenginu með venjulegri beiningu, og forrit sem nota þau gera venjulega ráð fyrir einu útvarpssviði. Streymisstraumur á hópi með alheimsumfangi er önnur hönnun en uppgötvunarprotokoll sem býst við að hvert tæki heyri hverja fyrirspurn, og aðeins hið síðara hefur áhyggjur af stærð útvarpssviðsins.

Ákveddu hvort krafan er þjónustan eða uppgötvunaraðferðin, því þessi svör eru mismunandi að kostnaði um stærðargráðu. Annað biður um fang sem breytist ekki; hitt biður um útvarpssvið sem er teygt yfir tengingu víðsnet með öllu sem af því leiðir.

Staðbundin uppgötvun á að stöðvast

Multicast DNS eins og lýst er í RFC 6762 er hannað í kringum eina tengingu: fyrirspurnir fara á fastan hóp, svör eru send á sama hóp, og protokollið reiðir sig á að hver þátttakandi heyri alla. Beinar senda ekki þessa umferð sjálfgefið, og það er hönnunarákvörðun en ekki yfirsjón. Mörkin eru til svo tæki í einni byggingu geti ekki tilkynnt sig af tilviljun í aðra. Göng sem virðast laga uppgötvun með því að bera hópinn alls staðar hafa fjarlægt þessi mörk fyrir hvert forrit, ekki bara það sem þurfti hjálp.

Endurvarpar og speglar eru til, og þeir eru raunveruleg þjónusta með raunverulegar afleiðingar: hvert nafn sem tilkynnt er á einum stað verður sýnilegt á hinum, þar á meðal tækjanöfn sem auðkenna fólk eða búnað. Ef raunverulega krafan er að tiltekin þjónusta sé finnanleg, er þjónustufærsla birt í DNS venjulega minni breytingin, og hún opinberar eitt nafn í stað straums af þeim.

Þrír hlutir sem beint multicast þarf

Beint multicast þarf þrjá hluti sem vinna saman: móttakendur sem ganga í hópinn, beinar sem halda framsendingarstöðu fyrir hann, og göng sem meðhöndla hópföngin sem umferð til að bera. Göng með stefnu sem telur aðeins upp unicast-undirnet munu sleppa umferð hópsins á dulkóðunarmörkunum, og þess vegna er fyrsta einkennið oft þögn frekar en villa. Leiðartengt viðmót eins og GRE eða VTI göng ber það sem beiningataflan sendir inn í það, sem gerir hópinn aðgengilegan þegar multicast-staðan er til.

Aðgengi uppsprettunnar er seinni helmingurinn. Beiningarprotokoll multicast eins og PIM byggja dreifitrjé með því að athuga að leiðin til baka að uppsprettunni sé sú sem búist er við, svo unicast-leið sem bendir annað hvert brýtur tréð jafnvel þótt aðild hópsins sé rétt. Að setja upp leið fyrir móttakandann gerir ekkert fyrir þá athugun, og það er mistökin sem gefa ping sem virkar og straum sem bregst. Staðfestu fyrst afturleið uppsprettunnar, bættu síðan við aðild, og skoðaðu forritið aðeins eftir það.

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

Fyrstu tvær línurnar sýna við hvað hýsillinn gekk og hvað kjarninn sendir áfram, þriðja sýnir eigin aðild forritsins, og síðasta unicast-leiðina sem afturleiðarathugunin mun nota. Að lesa þær saman greinir forrit sem gekk aldrei í hóp frá neti sem sendi aldrei áfram.

Sannaðu það með einni uppsprettu og einum móttakanda

Áður en þú snertir stillingu skaltu staðfesta að forritið virki á einum hluta. Ef það bregst staðbundið er beining multicast ekki vandamálið og engin breyting á göngum mun hjálpa. Endurtaktu síðan með einum móttakanda yfir göngin og fylgstu með pökkunum beggja vegna dulkóðunarmarkanna.

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

Pakkar sem sjást inni í göngunum en vantar utan þeirra benda til innpakningar eða stefnu; pakkar sem sjást beggja vegna án framfara í forritinu benda til aðildar móttakandans eða tengingar forritsins. Hafðu upptökur stuttar og síaðar, því breið multicast-upptaka á annasömu sviði er að mestu hávaði.

Veldu þjónustufang þegar þú þarft aðeins þjónustuna

Uppgötvun er til að finna eitthvað sem hreyfist. Þjónn með stöðugt nafn þarf ekki uppgötvun, og skjalfest fang í einkareknu DNS svarar raunverulegri spurningu notandans án þess að teygja útvarpssvið yfir tengingu víðsnet. Sama röksemd á við prentara, tæki og innri vefþjónustur. Nafn í DNS er aðgengilegt frá hverjum stað sem þarf þess meðan það tilkynnir ekkert stöðunum sem þurfa þess ekki, og það heldur áfram að virka þegar tækinu er skipt út fyrir annað með öðru fangi.

Þegar protokoll krefst sannarlega multicast, takmarkaðu það við hópinn og staðina sem þurfa þess, skjalfestu hvers vegna, og endurskoðaðu ákvörðunina þegar forritið breytist. Að teygja uppgötvun alls staðar er auðvelt einu sinni, og erfitt að afturkalla eftir ár af tækjum sem þegja og treysta á hana.