د لارښوونې جدول د ریښتیني پلټنې پر وړاندې: د VPN ټرافیک چېرته ځي

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

جدول د کاندیدانو ټولګه ده، نه پریکړه

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

پورتنۍ هره پته یو مستند مثال دی۔ خبره د ځواب په بڼه ده: انټرفیس، غوره شوې سرچینه پته، ګیټ وې، او هغه جدول چې ننوتنه ترې راغله۔ که دا پایله د هغه انټرفیس سره سمون ونه خوري چې تاسو یې تمه لرله، نو تاسو ستونزه په یو امر کې پیدا کړه، او د بشپړ جدول لوستلو هیڅ اندازه هم تاسو ته نه وایي چې کوم کاندید وګټل۔

پلټنه لومړی له قاعدو، بیا له جدولونو تېریږي

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 خپلې قاعدې او جدولونه لري۔ هغه ډیزاین چې دواړه کورنۍ چلوي دواړه پلټنې ته اړتیا لري، او یو کارکوونکی IPv4 ځواب د v6 لارې په اړه هیڅ نه وایي چې دوه سټیک لرونکی کس ممکن غوره کړي۔

د VPN کس څه نصبوي

کسونه معمولاً د ډیفالټ لاره نه بدلوي، ځکه چې دا به د تونل خپله بهرنۍ لاره مات کړي۔ دوی یو څه ډېر مشخص نصبوي چې د پریفیکس اوږدوالي سره ګټي: د 0.0.0.0/1 او 128.0.0.0/1 پوښونکې نیمه-ډیفالټ جوړه کلاسیکه چل ده، ځکه دواړه له 0.0.0.0/0 اوږد پریفیکسونه دي او یوځای ټول ځای پوښي۔ نور مشخص شخصي پریفیکسونه او یوه پالیسي قاعده نصبوي، او ځینې نښه ورزیاتوي ترڅو یوازې غوره شوی ټرافیک ونیول شي۔

له همدې کبله "VPN زما ډیفالټ لاره بدله نه کړه" د ناکامۍ ثبوت نه دی۔ وګورئ چې هغه واقعاً څه زیات کړل، او ایا اړوند موخه په هغو پریفیکسونو کې راځي:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

په ډمپ کې دوه نیمه-لارې په اسانه له پامه غورځېدای شي ځکه چې دوی د ډیفالټ په څیر نه ښکاري۔ هغه split-tunnel ترتیبات چې پریفیکس شاملول یې هیر کړل، هغه نښه پیدا کوي چې تاسو یې تعقیب کوئ: هغه اپلیکیشن چې باید تونل وکاروي، پرځای یې په سیمه ییز ډول حل او نښلوي۔ نصب شوي پریفیکسونه د هغو موخو سره پرتله کړئ چې کاروونکي واقعاً ورته اړتیا لري، نه له هغو پتو سره چې تصادفاً مو ازموینې۔ هغه split-tunnel لیست چې د فایل سرور پوښي خو د هغه حل کوونکی نه، هغه اړیکه پیدا کوي چې عامه پتې ته حل کېږي او بیا په تصدیق کې ناکامېږي، دا د پټنوم ستونزې په څیر ښکاري خو د لارې ستونزه ده۔

بهرنۍ لاره هم باید ژوندۍ پاتې شي

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

د سیال پته هغسې وګورئ لکه چې تاسو دنننۍ موخه ګڼلې وه، او تایید کړئ چې هغه فزیکي انټرفیس ته حل کېږي نه تونل ته:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

تکرارېدونکې لاره، هغه پالیسي قاعده چې سیال نیسي، یا هغه ډیفالټ چې بشپړ-تونل کس بدل کړی، درې معمول لاملونه دي۔ درېواړه په بهرنۍ پلټنه کې ښکاري، او هیڅ یو هم د واقیعې وروسته اخیستل شوي اصلي جدول ډمپ کې نه ښکاري۔

د لارښوونې پایله تاسو ته څه نه شي ویلای

سمه پلټنه مانا دا ده چې کرنل به پیکټ یو مناسب ځای ته ولېږي۔ دا مانا نه ده چې فایرول اجازه ورکوي، IPsec پالیسي یې پوښي، NAT قاعده یې ژباړي، یا لرې اړخ ته د بېرته راتلو لاره ده۔ له دې هر یو وروسته پړاو دی، او د strongSwan د لېږلو یادښتونه هغه زنځیر بیانوي چې پیکټ باید په دواړو سرونو کې تیر کړي۔

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

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