Bakit hindi tumatawid ang multicast sa isang VPN nang walang plano

Dalawang site ay maaaring perpektong maabot ang isa't isa sa unicast at gayon pa man ay kumilos na parang hindi nakikita ng isa ang abiso ng pagtuklas ng printer, ang IPTV stream o ang tibok ng cluster. Hindi ito sirang tunnel; ito ang pagkakaiba ng isang destinasyon at isang grupo. Ang paghahatid ng multicast ay nangangailangan ng modelo ng pagiging kasapi, kalagayan ng pagpapasa sa buong landas at interface na handang magdala ng trapiko, at wala sa mga ito ang nagmumula sa rutang unicast. Ang paglalakad mula sa grupo ng aplikasyon hanggang sa isang gumaganang tagatanggap ang pinakamaikling landas patungo sa sagot.

Magsimula sa grupo at sa aplikasyon

Itanong kung aling address ng grupo ang ginagamit ng aplikasyon at para saan ang trapiko. Ang protokol ng pagtuklas na nag-aanunsyo ng mga serbisyo, ang streaming feed at ang mga hello packet ng protokol ng ruta ay tatlong magkaibang problema na may tatlong magkaibang katanggap-tanggap na sagot. Ang address ng grupo mismo ang nagsasabi ng saklaw: ang mga address sa bloke ng kontrol ng lokal na network ay hindi nilayon na ipasa sa labas ng link ng ordinaryong ruta, at ang mga aplikasyong gumagamit ng mga ito ay karaniwang nagpapalagay ng isang domain ng broadcast. Ang streaming feed sa isang grupong may pandaigdigang saklaw ay ibang disenyo kaysa sa protokol ng pagtuklas na umaasa na maririnig ng bawat device ang bawat query, at ang pangalawa lang ang may pakialam sa laki ng domain ng broadcast.

Magpasya kung ang pangangailangan ay ang serbisyo o ang mekanismo ng pagtuklas, dahil ang mga sagot na iyon ay nagkakaiba sa gastos ng isang order ng magnitude. Ang isa ay humihingi ng address na hindi nagbabago; ang isa ay humihingi ng domain ng broadcast na pinalawak sa isang link ng malawak na lugar kasama ang lahat ng sumusunod dito.

Ang lokal na pagtuklas ay dapat huminto

Ang Multicast DNS na inilarawan sa RFC 6762 ay dinisenyo sa paligid ng isang link: ang mga query ay pumupunta sa isang takdang grupo, ang mga sagot ay ipinapadala sa parehong grupo, at ang protokol ay umaasa na naririnig ng bawat kalahok ang lahat. Hindi ipinapasa ng mga router ang trapikong iyon bilang default, at iyon ay desisyon sa disenyo at hindi kapabayaan. Umiiral ang hangganan upang ang isang device sa isang gusali ay hindi basta makapag-anunsyo ng sarili sa iba. Ang isang tunnel na tila nag-aayos ng pagtuklas sa pamamagitan ng pagdadala ng grupo sa lahat ng lugar ay nag-alis ng hangganang iyon para sa bawat aplikasyon, hindi lang para sa isang nangangailangan ng tulong.

May mga repeater at reflector, at sila ay tunay na serbisyo na may tunay na kahihinatnan: bawat pangalang inaanunsyo sa isang site ay nagiging nakikita sa isa, kasama ang mga pangalan ng device na kumikilala sa mga tao o kagamitan. Kung ang tunay na pangangailangan ay mahanap ang isang partikular na serbisyo, ang service record na inilathala sa DNS ay karaniwang mas maliit na pagbabago, at nagbubunyag ito ng isang pangalan sa halip na isang agos ng mga ito.

Tatlong bagay na kailangan ng naka-rutang multicast

Ang naka-rutang multicast ay nangangailangan ng tatlong bagay na nagtutulungan: mga tagatanggap na sumasali sa grupo, mga router na nagpapanatili ng kalagayan ng pagpapasa para dito, at isang tunnel na itinuturing na trapik na dapat dalhin ang mga address ng grupo. Ang isang tunnel na may patakaran na naglilista lamang ng mga subnet na unicast ay ibabagsak ang trapiko ng grupo sa hangganan ng encryption, at iyon ang dahilan kung bakit ang unang sintomas ay madalas katahimikan at hindi error. Ang interface na nakabatay sa ruta, tulad ng GRE o VTI tunnel, ay nagdadala ng ipinapadala ng routing table dito, na nagpapalabas ng grupo kapag umiiral na ang kalagayan ng multicast.

Ang maabot ng pinagmulan ay ang ikalawang kalahati. Ang mga protokol ng rutang multicast tulad ng PIM ay nagtatayo ng mga puno ng pamamahagi sa pamamagitan ng pagsuri na ang landas pabalik sa pinagmulan ay ang inaasahan, kaya ang rutang unicast na tumuturo sa ibang lugar ay sumisira sa puno kahit tama ang pagiging kasapi sa grupo. Ang pag-install ng ruta para sa tagatanggap ay walang ginagawa para sa pagsusuring iyon, at ito ang pagkakamaling gumagawa ng gumaganang ping at nabigong stream. Tiyakin muna ang landas ng pagbalik ng pinagmulan, pagkatapos idagdag ang pagiging kasapi, at pagkatapos lang tingnan ang aplikasyon.

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

Ang unang dalawang linya ay nagpapakita kung saan sumali ang host at ano ang ipinapasa ng kernel, ang pangatlo ay nagpapakita ng pagiging kasapi ng aplikasyon mismo, at ang huli ang rutang unicast na gagamitin ng pagsusuri ng baliktad na landas. Ang pagbasa sa kanila nang sabay ay naghihiwalay ng aplikasyong hindi kailanman sumali sa network na hindi kailanman nagpasa.

Patunayan ito sa isang pinagmulan at isang tagatanggap

Bago hawakan ang isang configuration, tiyakin na gumagana ang aplikasyon sa isang segment. Kung nabigo ito nang lokal, hindi ang rutang multicast ang problema at walang pagbabago sa tunnel ang makakatulong. Pagkatapos ulitin sa isang tagatanggap sa kabila ng tunnel at obserbahan ang mga packet sa magkabilang panig ng hangganan ng encryption.

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

Ang mga packet na nakikita sa loob ng tunnel ngunit wala sa labas nito ay tumuturo sa encapsulation o patakaran; ang mga packet na nakikita sa magkabilang panig nang walang progreso ng aplikasyon ay tumuturo sa pagiging kasapi ng tagatanggap o sa pagkakabit ng aplikasyon. Panatilihing maikli at naka-filter ang mga capture, dahil ang malawak na capture ng multicast sa abalang segment ay karamihan ingay.

Pumili ng address ng serbisyo kung serbisyo lang ang kailangan

Umiiral ang pagtuklas upang makahanap ng isang bagay na gumagalaw. Ang server na may matatag na pangalan ay hindi nangangailangan ng pagtuklas, at ang address na nakatala sa pribadong DNS ay sumasagot sa tunay na tanong ng gumagamit nang hindi pinalalawak ang domain ng broadcast sa isang link ng malawak na lugar. Ang parehong pangangatwiran ay nalalapat sa mga printer, kagamitan at panloob na serbisyo sa web. Ang pangalan sa DNS ay maaabot mula sa bawat site na nangangailangan nito habang wala itong inaanunsyo sa mga site na hindi nangangailangan, at patuloy itong gumagana kapag ang device ay pinalitan ng isa na may ibang address.

Kapag ang isang protokol ay tunay na nangangailangan ng multicast, limitahan ito sa grupo at sa mga site na nangangailangan nito, idokumento kung bakit, at suriin muli ang desisyon kapag nagbago ang aplikasyon. Ang pagpapalawak ng pagtuklas sa lahat ng lugar ay madali nang isang beses, at mahirap bawiin pagkatapos ng isang taon ng mga device na tahimik na umaasa dito.