د IPv6 ټونل ملګري ته ping ناکام شو؟ :: پته وګورئ

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

هغه نښه چې پتې ته اشاره کوي

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

د ټولو صفرونو پیژندونکی د anycast په توګه خوندي دی

RFC 4291 د ټولو صفرونو انټرفیس پیژندونکی د سبنیټ روټر anycast پتې په توګه ساتي، نو /64 لکه 2001:db8:4a::/64 کې هېڅ د کار وړ هوسټ نشته 2001:db8:4a:: پتې کې۔ دا خوندیتوب خپل ځای مستحق دی: د روټر اعلانونه او د ګاونډیو موندنه هماغې بڼې ته ادرس ورکوي، او روټر د هغې مخکینیښې لپاره ځواب ورکوي چې خدمت یې کوي۔ هغه ارزښت د ټونل سر ته ټاکل یوه پاڼې ته د روټر رول ورکوي، او ځکه هېڅ شی بیرته نه راځي۔ په مخکینیښه کې هر بل پیژندونکی د هوسټ په توګه کار کوي، نو سمون معمولاً یو رقم دی۔

دا خوندیتوب داسې رول وګڼئ چې د ټونل سر څخه یې اخیستلو حق نه لرئ، نه داسې عجیبه چې له روټ سره یې تیر شئ۔

د هوسټ پتې وټاکئ او مخکینیښه روټ کړئ

د دوو سرو لپاره ::1 او ::2 وټاکئ، یوه دا کمانډ سره اضافه کړئ: ip -6 addr add 2001:db8:4a::2/64 dev tun0، بیا لیرې مخکینیښه ادرس کولو هڅې پرځای روټ کړئ۔ 2001:db8:4a::/64 لپاره له ټونل څخه وتونکی روټ لیرې خوا ته رسېدنه ممکنوي؛ یوازې پته محلي انټرفیس تنظیموي۔

د بشپړ ټونل لپاره درېیم ګام شته، د وسیلې له لارې نړیوال unicast لپاره اصلي روټ، چې هر څه ټونل ته لېږلو IPv6 معادل دی۔ که یې پرېږدئ، IPv4 د ټونل دننه سفر کوي او IPv6 فزیکي لینک کاروي، نو هوسټ هغه ټرافیک تویوي چې تاسو یې پوښل شوی ګڼلی و۔ د دې سره تایید کړئ: ip -6 route get 2001:4860:4860::8888 او د ځواب اټکل کولو پرځای ولولئ چې کوم وسیله نوموي۔

multicast د روټینګ دمخه رد کیږي

Android VpnService.Builder لپاره پتې او روټونه LinkAddress له لارې تاییدوي، او هغه جوړونکی multicast په کلکه ردوي۔ که ورته د روټ په توګه multicast مخکینیښه ورکړئ، نتیجه روټ نه، بلکې د خراب LinkAddress پارامیټرونو ناکامي ده، چې د شبکې ځواب نه، د تایید ځواب دی۔ دا رد کول له منځګړي سره سمون لري: پوائنټ-ټو-پوائنټ tun وسیله د لینک طبقې multicast نه لري، نو پر هغې ډله ایز روټ د نصبولو سپارلو ماډل نه لري۔ ډله ایزې پتې لاسي تنظیم نه، بلکې سټیک پخپله جوړوي او کاروي۔

IPv6 all-nodes او solicited-node پتې د همدې قاعدې لاندې راځي۔ انټرفیس هغوی ځکه وړي چې سټیک هغوی هلته ایښي، نه ځکه چې کومه تګلاره یې اراده درلوده۔

ټونل پرځای څه وړلی شي

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

په مقابل کې unicast پرته له پورتنۍ پتو او روټونو بل څه نه غواړي، نو معمولاً له ټونلونو تمه کیږي چې هغه ووړي، او بیا د موندنې پروتوکول ناکامېدو لامل په هغوی ورته اچول کیږي۔

د هر څه ټاکلو دمخه درې کتنې

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

هغه روټ چې پلیټ فورم هیڅکله نصب کړی نه دی په اوږده انتظار سره ډیبګ کېدای نه شي، او هغه پته چې هیڅکله هوسټ نه وه په غوره ping سره سمېدای نه شي۔