ولې د IPv6 ګاونډیانو موندنه په روټ شوي VPN کې ناکامه کیږي

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

حد د ترتیبونو دمخه راځي

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

د لینک سره محلي پت لکه fe80:: ننوتنه هم زون-محدود دی، او هماغه متن په بل لینک کې بل کوربه ښودلی شي۔ د تونل له بلې خوا یو ازمویل د دې پرته چې پت مبهم دی هیڅ نه ثابتوي۔

تله داده چې پری فکس په لینک باندې دی

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

د یو خدمت لپاره /128 ترټولو لږ حیرانونکی ترتیب دی، او ابهام په بشپړه توګه لیرې کوي۔ د ګاونډیانو موندنې مشخصات د پیغامونو ټولګه او په-لینک-باندې هغه بیرغ تشریح کوي چې دا فیصله کوي۔

پل جوړول په قصد سره قواعد بدلوي

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

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

د هغه پت سره ازموئ چې اپلیکیشن یې کاروي

د ip -6 route get سره لاره تایید کړئ، د ip -6 neigh سره ګاونډي ننوتنه وګورئ، بیا د روټ شوې لارې له مخې خدمت تایید کړئ۔ DNS او د بیرته راستنیدو لار جلا کتنې دي، او روغه ګاونډي ننوتنه له دوی څخه هیڅ یوه نه ثابتوي۔

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

ولیږئ چې کوم ډیزاین لرئ

د پیښې دمخه ثبت کړئ چې روټ شوی دی که پل شوی، ځکه دواړه ځای پرځای کول دې پوښتنو ته بیلابیل ځوابونه ورکوي او د دندې انجینر باید دا له پروفایل څخه اټکل نه کړي۔

د پیغامونو ټولګه یو ځل لوستل د لینک-حد خاصیت د VPN نیمګړتیا په توګه تشریح کولو هوس لیرې کوي، چې په دې برخه کې ترټولو ګران غلط تشخیص دی۔