SSM د OpenVPN له لارې: یو سرچینه او یوه ډله له پیل څخه تر پای پورې تعقیبول
د VPN په تورنولو دمخه یو سرچینه-ځانګړی multicast بهیر د ترلاسه کوونکي غړیتوب، RPF ټاکنې او د تونل د رسولو ماډل له لارې تعقیب کړئ۔
یو بهیر او یو ترلاسه کوونکی وټاکئ، بیا هغه جوړه د هر قدم له لارې تعقیب کړئ پر دې بجې چې multicast د یوې کټګورۍ په توګه وآزموئ۔ د سرچینې لپاره ځانګړی ډیزاین په دقیق ډول د څلورو ځایونو په یو کې ناکام کیږي: ترلاسه کوونکی هیڅکله ونه نښلېد، روټر پاکټ د هغې په بیرته لار کې رد کړ، کرنل هیڅ حالت نلري، یا تونل هیڅکله یوه کاپي ونه رسول۔ دې ترتیب ته کار کول هر قدم لپاره څو دقیقې لګښت لري او تاسو ته وایي چې د څلورو څخه کوم یو واقعا لرئ۔
لومړی سرچینه، ډله او ترلاسه کوونکی وټاکئ
له هر وسیلې څخه د لاس وهلو دمخه درې ارزښتونه ولیکئ: د لېږونکې سرچینې پته، هغه ډلې پته چې ترلاسه کوونکی به ورته نښلي، او هغه فرعي شبکه چې ترلاسه کوونکی پکې دی۔ د یو بېلګې IPv4 بهیر لپاره، 10.50.0.10 سرچینه او 232.20.30.40 ډله هغه ډول جوړه ده چې د سرچینې لپاره ځانګړي ډیزاین سره ځي۔ له دې درې ارزښتونو څخه مبهم هر څه نشي آزمویل کېدای۔
د 232/8 حد د سرچینې لپاره ځانګړي multicast لپاره ساتل شوی، او ماډل په RFC 4607 کې تشریح شوی۔ که ستاسو ډله له دې حد څخه بهر وي په داسې حال کې چې تاسو فکر کوئ SSM چلوئ، ودرېږئ او تایید کړئ چې ځای پرځای کول واقعا څه نیت لري، ځکه چې د ترلاسه کوونکي نښلېدل او د روټر د لیږد پرېکړه دواړه د ماډل د یووالي پورې تړلي دي۔
وګورئ چې ترلاسه کوونکی سرچینې ته نښلېدلی دی
یوازې د ډلې لپاره د غړیتوب راپور د سرچینې لپاره ځانګړی نښلېدل نه دی۔ له ترلاسه کوونکي وپوښتئ کومه سرچینه یې غوښتې، او د لومړي قدم په روټر کې د ډلې حالت وګورئ چې د سرچینو لیست ښکاري که نه۔ که راپور هیڅ سرچینه ونه لري، روټر به هغه د هرې سرچینې څخه نښلېدل وګڼي او ټول ډیزاین به په خاموشۍ کې هغه څه ته ورکړ شي چې تاسو پلان نه و کړی۔
د Linux په ترلاسه کوونکي کې، وګورئ چې سوکیټ واقعا څه ته ګډون کړی او کرنل څه ثبت کړي دي۔ د اپلیکیشن کنفیګریشن فایل ثبوت نه دی؛ د غړیتوب جدول ثبوت دی۔ هغه هغه وخت ولولئ چې ترلاسه کوونکی واقعا روان وي، ځکه چې ننوتنه کېدای شي د هغې پروسې له وتلو وروسته هم لږ وخت پاتې شي چې هغه یې جوړه کړې وه۔ د پخواني ازموینې زوړ ننوتنه د درواغجن باور باوري سرچینه ده۔
ip maddr show dev eth0
cat /proc/net/igmp | sed -n '1,40p'
که نښلېدل د تمه شوې سرچینې سره شتون ولري، روټرونو ته لاړ شئ۔ که نه وي، هیڅ د تونل کنفیګریشن به مرسته ونه کړي، ځکه چې د لیږدو لپاره هیڅ نشته۔
د تونل د کتلو دمخه بیرته لار تایید کړئ
multicast روټینګ د بیرته لار ازموینه کوي، او هغه پاکټ چې د یونیکاسټ لارې له اشارې کولو پرته بل انٹرفیس ته رسیږي غورځول کیږي۔ دا هغه ترټولو عام دلیل دی چې څرګنده لېږل شوې بهیر هیڅکله بل قدم ته نه رسیږي، او د اپلیکیشن په کچه هیڅ ګټور تېروتنه نه تولیدوي۔
د سرچینې په لور مخامخ روټر کې، د سرچینې په لور لار د هغه انٹرفیس سره پرتله کړئ چې پاکټونه واقعا پرې رسیږي۔ د ترلاسه کوونکي په لور مخامخ روټر کې، د ترلاسه کوونکي د خپلې فرعي شبکې لپاره هماغه وکړئ او تایید کړئ چې د وتونکو انٹرفیسونو لیست د هغې په لور لینک لري۔ په هر لوري کې ناسمول د RPF ناکامي ده، د غړیتوب ناکامي نه۔
بیا تایید کړئ چې د سرچینې TTL ستاسو د ډیزاین شوو روټ شوو قدمو د تېرولو لپاره کافي لوی دی۔ هغه بهیر چې په لومړي روټر کار کوي او په دوهم مري، ډېری وخت د TTL پوښتنه ده، د پالیسۍ نه۔
د کنفیګریشن پرځای د کرنل multicast حالت ولولئ
کنفیګریشن تاسو ته وایي چې څه مو غوښتي؛ کرنل وایي چې څه پېښیږي۔ په هر Linux قدم کې، د multicast روټینګ ننوتنې ولولئ او تایید کړئ چې د سرچینې او ډلې د دقیقې جوړې لپاره د راتلونکو او وتونکو انٹرفیسونو لیست شته۔ د ډلې لپاره د عمومي سرچینې سره ننوتنه بله شی ده، او د سرچینې لپاره ځانګړی بهیر به تشریح نه کړي۔
ip mroute show from 10.50.0.10 iif eth1
ip route get 10.50.0.10
د روټینګ ډیمونونه د هغه حالت پرمخ خپل لید ساتي، او هغه کمانډ چې چاپوي یې په دې پورې تړلی دی چې کوم پلي کول نصب دي۔ اصل ثابت دی: له ډیمون څخه د جوړې لپاره د هغه پورتنی ننوتنه وپوښتئ، بیا له کرنل څخه وپوښتئ چې د لیږد ننوتنه شته که نه۔ هغه ډیمون چې فکر کوي لیږدوي په داسې حال کې چې کرنل هیڅ ننوتنه نلري، په هغه کوربه د کنفیګریشن د ساحې ستونزه ده۔
کله چې دواړه سره نه جوړیږي، VPN نه بلکې کوربه سم کړئ۔ ستاسو د پوښتل شوې بهیر د لیږدوونکي قدم لپاره لاندې هیڅ شی نشي بدل کېدای۔ تر هغه چې بهیر کار کوي، د هر قدم لپاره جوړه، راتلونکی انٹرفیس او وتونکی لیست ثبت کړئ۔ هغه ثبت بل ناکامي د نوي پلټنې پرځای پرتله ګرځوي۔
پریکړه وکړئ چې تونل واقعا څنګه کاپي جوړوي
دلته د VPN پرمخ multicast عادي کار کېدل بندوي۔ د ټکي-تر-ټکي تونل پاکټ بلې خوا ته یوازیني جوړښت ته رسوي، نو یوه کاپي دقیقا یو کس ته رسیږي۔ پله شوی برخه د شریک لینک په څېر ډېره چلند کوي، ځکه چې تونل چوکاټ لېږدوي او پله پریکړه کوي چې څه سیلاب کړي۔ دا بېلابېل رسولو ماډلونه دي، او هغه ډیزاین چې دوهم فرض کوي په داسې حال کې چې لومړی چلوي، به یو ترلاسه کوونکي ته کار کوونکی ښکاره شي او بل ته به ناکام شي۔
د یو څخه ډېرو ترلاسه کوونکو لپاره د څو نقطو سرور له لارې، کاپي جوړول باید په څرګند ډول ډیزاین شي۔ په ګیټ وې کې د multicast لار نصبول VPN سرور ته نه ښیي چې کوم همکاران باید کاپي واخلي، او د کسټ اړخ هیڅ لار دا پریکړه د هغه په استازیتوب نه کوي۔ چېرې چې اړتیا ډېر ترلاسه کوونکي وي، هلته ملاتړ شوې کاپي یا په قصد ټاکل شوې بدیله وکاروئ، او ولیکئ چې کومه مو وټاکله۔
په پای کې، په ترلاسه کوونکي کې د نږدې څارنې لاندې تایید کړئ: دقیقه سرچینه، ډله او پورټ، په هغه انٹرفیس چې تمه یې لرئ، په داسې حال کې چې یو مجاز ترلاسه کوونکی نښلېدلی وي۔ SSM لېږونکی ټاکي، او ټاکنه د هغه لېږونکي تصدیق نه دی، او نه بل multicast ترافیک ته د هماغه پالیسۍ د تیرولو اجازه۔