ولې مالټي کاسټ پرته له پلان له VPN نه تېرېږي

دوه ځایونه کولای شي د یونیکاسټ له لارې یو بل ته په بشپړه توګه ورسیږي او بیا هم داسې چلند وکړي لکه یو یې د پرنټر د کشف اعلان، د IPTV جریان یا د کلسټر د زړه درزا نه ویني۔ دا ماته تونل نه دی؛ دا د منزل او ډلې ترمنځ توپیر دی۔ د مالټي کاسټ رسولو لپاره د غړیتوب ماډل، د لارې په اوږدو کې د لېږد حالت او د ترافیک د وړلو لپاره چمتو انټرفیس ته اړتیا ده، او له دې هیڅ یو هم د یونیکاسټ لارې څخه نه راځي۔ د اپلیکیشن له ډلې څخه یو کار کوونکي اخیستونکي ته تلل ځواب ته ترټولو لنډه لار ده۔

له ډلې او اپلیکیشن پیل وکړئ

وپوښتئ چې اپلیکیشن کومه د ډلې پته کاروي او ترافیک د څه لپاره دی۔ د خدماتو اعلان کوونکی د کشف پروتوکول، د سټریمینګ جریان او د مسیرولو پروتوکول د سلام پاکټونه درې بېلابېلې ستونزې دي چې درې بېلابېل منل شوي ځوابونه لري۔ د ډلې پته پخپله پراخوالی وایي: په ځایي شبکه کې د کنټرول بلاک پتې د عادي مسیرولو له لارې له لینک څخه بهر لېږلو لپاره نه دي، او هغه اپلیکیشنونه چې دوی کاروي معمولا یو واحد براډکاسټ ډومین فرض کوي۔ په نړیوال پراخوالی ډله کې سټریمینګ جریان د هغه کشف پروتوکول څخه بېل ډیزاین دی چې تمه کوي هره وسیله به هرې پوښتنې ته غوږ ونیسي، او یوازې دویم یې د براډکاسټ ډومین اندازې ته پام کوي۔

پرېکړه وکړئ چې اړتیا خدمت دی که د کشف میکانیزم، ځکه چې هغه دوه ځوابونه په لګښت کې د یوې درجې توپیر لري۔ یو یې داسې پته غواړي چې نه بدلېږي؛ بل یې د پراخې سیمې لینک په اوږدو کې خپور شوی براډکاسټ ډومین او له هغې څخه رامنځته شوي ټول څیزونه غواړي۔

ځایي کشف باید ودرېږي

په RFC 6762 کې تشریح شوی مالټي کاسټ DNS د یو واحد لینک شاوخوا ډیزاین شوی: پوښتنې یوې ثابتې ډلې ته ځي، ځوابونه همدغې ډلې ته لېږل کیږي، او پروتوکول په دې تکیه کوي چې هر ګډونوال ټول اوري۔ روټرونه هغه ترافیک په ډیفالټ ډول نه لېږدوي، او دا د ډیزاین پرېکړه ده نه غفلت۔ پوله د دې لپاره ده چې په یوه ودانۍ کې وسیله په بله ودانۍ کې په اسانه خپل اعلان ونه کړي۔ هغه تونل چې ښکاره د ډلې په هر چیرې وړلو سره کشف سموني، هغه پوله د هر اپلیکیشن لپاره لرې کړې ده، نه یوازې د هغه لپاره چې مرستې ته اړتیا وه۔

تکراروونکي او انعکاسوونکي شته، او هغوی ریښتیني خدمتونه دي چې ریښتیني پایلې لري: په یوه ځای کې اعلان شوی هر نوم په بل ځای کې ښکاره کیږي، په شمول د هغو وسیلو نومونه چې خلک یا وسایل پیژني۔ که ریښتینې اړتیا دا وي چې یو ځانګړی خدمت وموندل شي، په DNS کې خپور شوی د خدمت ریکارډ معمولا کوچنی بدلون دی، او د نومونو د بهیر پرځای یو نوم ښکاره کوي۔

درې شیان چې مسیر شوي مالټي کاسټ ته اړتیا دي

مسیر شوي مالټي کاسټ ته درې شیان په یوځای کار کولو سره اړتیا ده: هغه اخیستونکي چې ډلې ته ورګډیږي، هغه روټرونه چې د هغې لپاره د لېږد حالت ساتي، او هغه تونل چې د ډلې پتې د وړلو وړ ترافیک ګڼي۔ هغه تونل چې پالیسي یې یوازې یونیکاسټ فرعي شبکې لیستوي، د ډلې ترافیک به د کوډ کولو په پوله کې وغورځوي، او ځکه لومړنی نښه ډېری وخت خطا نه بلکې غلظ دی۔ د لارې پر بنسټ انټرفیس لکه GRE یا VTI تونل هغه څه وړي چې د مسیرولو جدول ورته لېږي، چې دا د مالټي کاسټ حالت شتون سره سمه ډله د لاسرسي وړ کوي۔

سرچینې ته رسېدنه دویمه نیمایي ده۔ د مالټي کاسټ مسیرولو پروتوکولونه لکه PIM د وېش ونې جوړوي دا په ګوته کوي چې سرچینې ته د بېرته تګ لار تمه شوې ده، نو هغه یونیکاسټ لار چې بلې خوا ته اشاره کوي ونې ته زیان رسوي حتی کله چې د ډلې غړیتوب سم وي۔ د اخیستونکي لپاره لار نصبول د هغې پلټنې لپاره هیڅ نه کوي، او دا هغه تېروتنه ده چې کار کوونکی پنګ او ناکام جریان رامنځته کوي۔ لومړی د سرچینې د بېرته تګ لار تایید کړئ، بیا غړیتوب اضافه کړئ، او یوازې له هغې وروسته اپلیکیشن ته وګورئ۔

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

لومړنۍ دوه کرښې ښیي چې هوسټ په څه ګډون کړی او کرنل څه لېږدوي، دریمه د اپلیکیشن خپل غړیتوب ښیي، او وروستنۍ هغه یونیکاسټ لار ښیي چې د معکوسې لارې پلټنه به یې کاروي۔ د دوی یوځای لوستل هغه اپلیکیشن چې هیڅکله ګډون نه دی کړی له هغې شبکې څخه بېلوي چې هیڅکله یې لېږد نه دی کړی۔

دا په یوه سرچینه او یو اخیستونکي ثابت کړئ

له ترتیباتو څخه دمخه ډاډ ترلاسه کړئ چې اپلیکیشن په یوه برخه کې کار کوي۔ که په ځایي توګه ناکام شي، د مالټي کاسټ مسیرول ستونزه نه ده او هیڅ تونل بدلون به مرسته ونه کړي۔ بیا د تونل په اوږدو کې د یو اخیستونکي سره تکرار کړئ او د کوډ کولو پولې دواړو خواوو کې پاکټونه وګورئ۔

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

هغه پاکټونه چې د تونل دننه ښکاري خو دباندې نه وي د انکپسولیشن یا پالیسي ښکارندوی دي؛ هغه پاکټونه چې دواړو خواوو کې ښکاري خو اپلیکیشن کې پرمختګ نه وي د اخیستونکي غړیتوب یا د اپلیکیشن تړاو ښکارندوی دي۔ نیول لنډ او فلټر شوي وساتئ، ځکه په بوخت برخه کې پراخه مالټي کاسټ نیول ډېری شور وي۔

کله چې یوازې خدمت ته اړتیا وي د خدمت پته غوره کړئ

کشف د یو څه د موندلو لپاره دی چې حرکت کوي۔ د ثابت نوم لرونکي سرور کشف ته اړتیا نه لري، او په شخصي DNS کې ثبت شوې پته د کارونکي ریښتینې پوښتنې ته ځواب وایي پرته له دې چې براډکاسټ ډومین د پراخې سیمې لینک په اوږدو کې خپور کړي۔ ورته استدلال پرنټرونو، وسایلو او داخلي ویب خدمتونو ته هم صدق کوي۔ په DNS کې نوم له هغه هر ځای څخه د لاسرسي وړ دی چې ورته اړتیا لري، هغو ځایونو ته چې اړتیا نه لري هیڅ نه اعلانوي، او کله چې وسیله د بلې پتې لرونکې وسیلې سره بدله شي کار ته دوام ورکوي۔

کله چې یو پروتوکول واقعا مالټي کاسټ ته اړتیا ولري، هغه ډلې او هغو ځایونو ته محدود کړئ چې ورته اړتیا لري، ولیکئ چې ولې، او کله چې اپلیکیشن بدل شي پرېکړه بیا وګورئ۔ کشف هر چیرې خپرول یو ځل اسانه دی، او د یو کال لپاره په غلظه توګه پرې تکیه کوونکو وسیلو وروسته یې بېرته اخیستل ستونزمن دي۔