IPv6 د IPv4 VPN سرور له لارې لا هم ریښتیني IPv6 وتل غواړي

تونل پورته کېږي، پېرېدونکی له پول څخه IPv6 پته ترلاسه کوي، او بیا هم هر IPv6 منزل وخت ته رسېږي۔ په تونل کې هېڅ خراب نه دی: IPv6 په IPv4 لېږد کې ښه ځي، او دا هېڅکله سخت برخه نه وه۔ هغه پته چې تا ورکړه، هغه ژمنه ده چې سرور یې نه شي پوره کولی، ځکه وتلې ته هېڅ IPv6 upstream نشته چې هغه ته یې ولېږي۔ سمون د وتلې په خوا دی، نه د پېرېدونکي په پروفایل کې۔

نښه: پته شته، لار نشته

د پېرېدونکي په خوا کتنه په تونل وسیله نړیوال ښکارېدونکې IPv6 پته او هغې ته اشاره کوونکې لار ښیي، نو ځکه دا په غلطه د پېرېدونکي د خرابۍ په توګه لوستل کېږي۔ ټرافیک تونل ته ننوځي، سرور یې کپسول پرانیزي، او بیا کڅوړه پر هغه کوربه کېږي چې د لارښوونې جدول کې د کوم ریښتیني ځای لپاره IPv6 تلواله لار نشته۔ د سټک له مخې ته سملاسي نه‌رسېدنه یا ارامه غورځول ترلاسه کوې، او په دواړو حالتونو کې پېرېدونکی د اور وژنې غوندې ورته ښکارېدونکی وخت پای ومومي۔

له پېرېدونکي سره د لاس وهلو دمخه د سرور خپل لارښوونې جدول ولوله، ځکه د لارې ورکه نیمه همالته اوسېږي۔ یو IPv4 تلواله لار لرونکی سرور تا ته ځواب دمخه ورکړی دی۔

له کپسول پرانیستلو وروسته کڅوړه تعقیب کړه

د تونل په داخل کې کڅوړه عادي IPv6 ده او د هغې سرچینه د پېرېدونکي پته ده۔ سرور د لېږد کپسول لادرزه کوي او بیا اصلي IPv6 کڅوړه لري چې باید بل IPv6 پړاو ته ورسول شي۔ د IPv4 تلواله لار هغه نه شي وړلی، او هغه ته IPv4 ته ژباړل بله دنده ده چې چا هم نه ده ګمارلې۔ دا ټوله ناکامي ده، او د دې سره هېڅ تړاو نه لري چې VPN اورېدونکي د IPv4 له لارې ځواب ورکړ که نه۔

د IPv6 له IPv4 پورته کپسول کولو میخانیک په RFC 4213 کې بیان شوی، او هلته مهم تفصیل دا دی چې سرونه لا هم د تونل بلې خوا ته ریښتینې IPv6 اړیکې ته اړتیا لري۔ د سرلیک پېچل upstream نه جوړوي۔

دوه تونل طبقې، دوه خپلواکې کتنې

هره طبقه بېله کتنه وکړه، ځکه چې کار کوونکی بهرنی تونل مات شوی داخلي تونل پټوي۔ بهرنۍ لار له پېرېدونکي څخه سرور ته په IPv4 ping سره وګوره او هغه پورټ تایید کړه چې کاروې۔ بیا پر سرور داخلي لار وګوره، چېرې چې ip -6 route باید تلواله یا له ریښتیني upstream څخه زده شوې ځانګړې لار وښیي، او ip -6 addr باید هغه سرچینه مخکښ وښیي چې upstream یې مني۔ له دې لږ هر څه یوازې پر مخ د ښکلا توکي دي۔

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

همدا خبره پېرېدونکي ته هم تطبیقېږي: ip -6 route get 2001:4860:4860::8888 باید د تونل وسیله ونوموي، او که فزیکي وسیله ونوموي، پېرېدونکی IPv6 لپاره VPN هېڅ نه کاروي۔

د سرچینې مخکښ، اندازه او ICMPv6

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

ستا سټک چې واقعاً کوم اضافي کپسول کاروي هغه ته بودیجه وټاکه، او ICMPv6 د Packet Too Big په ګډون فعاله وساته۔ دویم سرلیک د کارېدونکي بار اندازه کموي، نو هغه لار چې کوچنیو ping ته ځواب وایي ممکن د فایل لېږد په مهال هم ناکامه شي، او هغه اور وژنه چې ټول ICMPv6 غورځوي د سمېدونکي اندازې ستونزه توره سوري ته اوړي۔ د خدمت اعلانولو دمخه یو لوی لېږد وآزمویه۔

کومه به بشپړه بېله ستونزه وي

یوازې IPv4 چلونکې غوښتنلیک ته له یوازې IPv6 چلونکي پېرېدونکي څخه رسېدل ژباړه ده، نه تونل، او د پوره ارادې سره ګمارل شوي NAT64 غوندې څه ته اړتیا لري۔ منزل به یوازې د دې لپاره چې تا یو اضافي تونل سرلیک ورزیات کړ، هغه ونه پېژني۔ تاریخي لېږد خدمتونه هم هماغه پاملرنې ته اړ دي: RFC 7526 د 6to4 anycast ریلې ماډل لغوه کړ، نو هغه لارښود چې د هغې شاوخوا لیکل شوی، هغه څه بیانوي چې نور ساتل شوی عامه ریلې نه لري۔

که سرور د کارېدونکي IPv6 upstream نه لري، انتخابونه د ملاتړ شوی upstream، بله وتلې، یا مستندې پرېکړې دي چې IPv6 د تونل څخه بهر پاتې شي۔ ناقابل قبول دا دي چې پېرېدونکو ته ووایې چې IPv6 خدمت شته، په داسې حال کې چې د دوی عادي IPv6 اړیکه په چوپتیا VPN ته څنګه تېرېږي۔