د دوه اپلینکونو ترمنځ د fe80::1 شریکېدو پر مهال IPv6 پالیسي روټینګ

تاسو دوه اپلینکونه لرئ، او ip -6 route show په دواړو کې ورته بل ګام چاپوي: default via fe80::1 dev uplink0 او default via fe80::1 dev uplink1۔ دا د پت د تکرار شخړه نه ده، او یوازې بل ګام fe80::1 پالیسي جدول ته کاپي کول کرنل ته نه وایي چې تاسو کوم لینک ته اشاره کوئ۔ ریښتیني پوښتنه له نښې څخه تنګه ده: دویم جدول یو لینک ته اړتیا لري که دواړو ته، او د بیا پیل وروسته دا روټونه څه ژوندي ساتي۔ په ترتیب سره ازمویل شوې درې شرطونه ډېری حل کوي۔

هماغه fe80::1 دوه بېل ګاونډیان دي

لینک-ځایي پتونه یوازې یوه لینک ته محدود دي، نو fe80::1 دوه ځله چاپ شوی یو پت نه دی؛ دا دوه ګاونډیان دي چې یوازې یو ځانګړی پای شریکوي۔ د زون انډیکس هغه لاره ده چې کوربه وایي کوم یې مطلب دی، نو fe80::1%uplink0 او fe80::1%uplink1 کرنل ته بېلې منزلونه دي، او هغه پای هېڅکله لرې روټر ته نه ځي۔ RFC 4007 د دې شاته زون ماډل بیانوي، او همدا لامل دی چې پالیسي جدول باید له هر لینک-ځایي بل ګام سره وسیله ولېږدوي۔

د VPN کنفیګوریشن جوړوونکی چې د یوه کوربه شمېري زون ID ټیمپلیټ ته کاپي کوي، ځایي شرایط د پت برخه ګڼي، او هغه فایل چې لیکي یې په هره هغه ماشین کې غلط دی چې د انټرفیس نومونه یا انډیکسونه یې بېل وي۔ پالیسي جدول دوه لینکونه یو نه کوي: روټ شوی VPN د شبکو ترمنځ پاکټونه لېږدوي، خو د لرې ایترنیټ ګاونډي لینک-ځایي هویت د تونل له لارې نه وړي، نو لینک-ځایي ټرافیک په خپل لینک کې پاتې کېږي۔

وسیله لرې کړئ او روټ د لیکلو وړ نه پاتې کېږي۔ ip -6 route add default via fe80::1 table 200 د ګېټوې حل نشي کولای، او iproute2 یې د Error: Nexthop has invalid gateway. تېروتنې سره ردوي۔ dev uplink0 ورزیات کړئ او امر بریالی کېږي، ځکه چې بل ګام له دې دوو ګاونډیانو څخه یو ته تړي هماغه وسیله ده۔ هغه څه چې وسیله یې نه شي ویلای دا دي چې uplink0 د دې جدول لپاره سم لینک دی که نه، او له بل کوربه کاپي شوی روټ د هغه کوربه د انټرفیس نومونه ځان سره راوړي، ریښتیني غلطۍ هم له همدې ځایه راځي۔

لومړی شرط: په جدول کې یو لینک یا دوه

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

په هغه دویم حالت کې قاعده پرېکړه کوي چې جدول کله وکتل شي، او روټ پرېکړه کوي چې پاکټ چېرته ځي:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

هیڅ شی بل شی نه بدلوي، او یوازې ډیفالټ لرونکی جدول هم کولای شي خپله ګېټوې حل نه کړي۔ که اضافه کول رد شي، یا روټ وي خو د کار وړ نه وي، د هغه انټرفیس نښلول شوی پریفکس په هماغه جدول کې کېږدئ، یا بل ګام onlink ونښلئ (کله چې هغه پریفکس بل ځای روټ کېږي)۔ په پورتني بلاک کې 2001:db8:100::/48 هېڅ خپل سری منزل نه، بلکې په uplink1 باندې هماغه نښلول شوی پریفکس ښيي۔ د fwmark قاعده یوازې هغه نښه کاروي چې بل څه یې باید کیږدي: د فوروارډینګ لارې د nftables یا iptables قاعدې څخه، یا SO_MARK ساکټ کې، نو د نښې له سرچینې پرته کاپي شوی بلاک له هېڅ شي سره نه ځانګړي کېږي۔

دویم شرط: میټریکونه مړ چمتوکوونکی نه پېژني

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

له جوړېدو وروسته انتخاب تصدیق کړئ، او هغسې یې تصدیق کړئ لکه کرنل به یې ویني۔ ip -6 route get 2001:db8:100::1 هغه روټ چاپوي چې به کارول کېده، په دې کې وسیله او ټاکل شوی سرچینه پت شامل دي، او د پالیسي قاعدو درناوی کوي۔ د غلط اپلینک سرچینه پت معمولاً هغه نښه ده چې قاعده ستاسو له تمې دمخه برابره شوې۔

دریم شرط: پرېکړه وکړئ چې دوام ورته چا پورې اړه لري

روټ ip -6 route add سره اضافه شوی روټ تر بیا پیل یا تر هغه پورې چې څه یې پاک کړي پاتې کېږي۔ له روټر اعلانونو زده شوی ډیفالټ عمر لري او روټر یې بیرته اخیستلای شي، خو په لاس اضافه شوی ډیفالټ هېڅکله پخپله نه پای ته رسېږي۔ دواړه په یوه جدول کې ګډول هماغه لار ده چې زوړ تلپاتې روټ د نوې اعلان شوې روټ څخه پورته شي، ډېر وروسته له هغې چې تشریح شوی اپلینک له منځه تللی وي۔

هر جدول لپاره یو مالک وټاکئ۔ که د شبکې مدیر یا د روټینګ ډیمون لا دمخه انټرفیس سمبالوي، پالیسي روټ هلته بیان کړئ او کرنل ته لاس مه وروړئ۔ که یې په سکریپټ کوئ، سکریپټ آیډمپوټینټ کړئ او ماتول یې په هماغه وخت ولیکئ، ځکه چې په لومړي بد بدلون کې به یې اړتیا وي:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

په هغه روټر چې نورو کوربه وړاندې لېږي، د جدول تورنولو دمخه net.ipv6.conf.all.forwarding وګورئ۔ که فوروارډینګ بند وي، بلې شبکې ته ادرس شوي پاکټونه د 201 جدول هر څومره سم وي، غورځول کېږي۔

ډیزاین ثبت کړئ چې بل کس یې پلټنه کولای شي

یوازې fe80::1 ذخیره کوونکې فهرست مهمې برخې غورځوي۔ منزل، بل ګام، وسیله، جدول او میټریک یوځای ولیکئ، او دا هم چې هر روټ له کومه راغی: اعلان شوی، د مدیر جوړ کړی، که ثابت۔ کله چې وروسته څوک پوښتنه وکړي چې دویم اپلینک واقعاً ټرافیک وړي که نه، هغه ثبت پرته له اټکل ځواب وایي۔

د جدول د بشپړېدو دمخه، ګاونډی ip -6 neigh show dev uplink0 سره تصدیق کړئ، ip -6 rule show بیا ولولئ — د ترتیب ناڅاپیو لپاره، او د ډیفالټ لار نیوونکي ping پرځای له قاعدې سره سمون لرونکي ټرافیک سره یې وازموئ۔ بیا یو اپلینک په قصد بند کړئ او وګورئ کرنل کوم روټ ته شاته ځي؛ ځواب باید ستاسو له لیکل شوي سره سمون ولري۔