د IPv6 د څانګې مخکښ: په سرور کې iroute-ipv6 یا route-ipv6؟

د نږدې یو شان نوم لرونکې دوه لارښوونې په هر کار کوونکي بېلګه کې ښکاري، او یوه له بلې پرته کاپي کول داسې تونل جوړوي چې سم ښکاري او د څانګې مخکښ په غلیمه توګه غورځوي۔ دوی د یوې پولې په دوو بېلو خواوو کې بېل کار کوي: یوه د سرور کرنل ته ښیي چې مخکښ چېرته اوسیږي، او بله OpenVPN ته ښیي چې کوم تصدیق شوی پېرېدونکی یې وړي۔ که دواړه سم وي، مخکښ بهیږي؛ که یو سم وي، بستې لاره لري خو خاوند نه لري۔

دوه لارښوونې، دوه بېل کارونه

route-ipv6 یوه عادي د لارې نصبول دي: سرور یوه کرنل لاره ورزیاتوي چې مخکښ د خپل تونل انټرفېس ته اشاره کوي۔ iroute-ipv6 د یو ځانګړي پېرېدونکي په شرایطو پورې اړه لري او داخلي مالکیت اعلانوي، نو ډیمون پوهیږي چې د دې مخکښ ترافیک باید یو ټاکلي پېرېدونکي ته ولېږل شي، نه هغه همکار ته چې کرنل لاره ناڅاپه نوموي۔

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

دودیز userspace ترتیباتو کې دواړه اړین دي او یو بل بشپړوي۔ یوازې کرنل لاره ډیمون پرته له دې چې همکار وټاکي پرېږدي۔ یوازې iroute کرنل ته تونل ته د لارې پرته پرېږدي۔ له همدې ځایه د هر پېرېدونکي لپاره د فایلونو په اړه ډېره ګډوډي راځي: فایل د لارې جدول اندراج نه دی، او د لارې اندراج د مالکیت اعلان نه دی۔

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

هر یو چېرته ځي

لاره د سرور په مدیریت شوې ترتیباتو کې ځي، چېرته چې دا د همدې سرور پروسې لپاره پلي کیږي۔ iroute د پېرېدونکي ځانګړي فایل ته ځي، چې د څانګې وسیلې د تصدیق شوې هویت په نوم نومول شوی۔

داسې فایل نوم چې له اصلي هویت سره سمون نه لري هېڅکله نه لوستل کیږي، او نښه په بشپړه توګه د ورک iroute په څېر ده۔ هغه هویت وګورئ چې سرور تصدیق کړی، بیا د فایل نوم توری په توري وګورئ۔

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

پول او د څانګې مخکښ جلا وساتئ، ځکه چې د دوی یو بل ته ننوتل داسې معما جوړوي چې هېڅ لارښوونه یې نه شي حل کولی۔

بل پېرېدونکی څه ته اړتیا لري

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

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

هغه هر چا ته لېږل د پایلو لرونکې غوره توب دی: بیا هر پېرېدونکی باور لري چې څانګه د تونل له لارې رسېدونکې ده، په شمول هغو پېرېدونکو چې هېڅکله مو نه غوښتل دوی ته دا لاسرسی ورکړئ۔ اعلان په عمل کې د لاسرسي پرېکړه ده، که څه هم لارښوونه د پلمبرۍ کار ښکاري۔ د سرور انتخابونو مرجع iroute-ipv6 د پېرېدونکي ځانګړي مالکیت په توګه مستندوي، او همدا هغه توپیر دی چې ساتل یې ارزښت لري۔

د څانګې وسیلې باندې د بېرته راتلو لار

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

هغه بېرته راتلو لار په IPv6 کې د هغې ورکې لارې ستونزې سیال دی چې خلک په IPv4 کې ورسره مخ کیږي۔

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

کله چې جوړه لا هم بس نه وي

ځینې ځای پرځای کول دا لار هېڅ نه کاروي۔ د کرنل معلوماتي لار او د محصول لخوا مدیریت شوي سرورونه خپله ملاتړ شوې لارې سمبالښت لري، او د userspace بېلګه ممکن مستقیم ونه لېږدېږي۔

د بل لپاره لیکل شوي لارښود څخه لارښوونې کاپي کولو دمخه تایید کړئ چې ستاسو جوړښت کومه معلوماتي لار کاروي۔

او په پای کې، د پتو ساحه په یاد ولرئ: داسې ځانګړی سیمه ییز مخکښ لکه fd00:7a::/64 چې ډیزاین له مخې شخصي دی او د عامه IPv6 رسېدنې په اړه هېڅ نه وایي۔ له هغې سره د داخلي لاسرسي په توګه چلند وکړئ، او انټرنیټ ته وتل د خپلې پالیسۍ سره جلا مسئله وساتئ۔