د Wi-Fi څخه سیلولر ته د تګ وروسته kill-switch: څه ماتېږي

په یوه شیبه کې لیپ ټاپ د دفتر په Wi-Fi کې دی، په بله شیبه په تلیفون وتړل شو، او د ټونل ښودونکی بیا شین دی، لا تر دې چې تاسو د کړکیو بدلول نه وي بشپړ کړي. شین رڼا یوازې دا رپوټ کوي چې ټونل بیا وتړل شو؛ چې د رولېنګ او بندولو پالیسي په دې تشه کې څه وکړل، دا بله پوښتنه ده. هغه پالیسي د ورته والي د شرطونو یوه ټولګه ده چې په وروستي نصب کې تالیف شوې، او هغه انټرفیس، پته او د پتې کورنۍ نوموي چې لېږد یې همدا اوس لرې کړي. نو هماغه بدلون درې پایلې ورکوي چې ورته ښکاري: بندول دوام کوي، پالیسي خپله بیا رغونه بندوي، یا داسې لاره پرانیستل کېږي چې هېڅ شی یې نه پوښي.

په سکرین کې هېڅ شی هغه درې حالتونه نه جلا کوي، نو پوښتنه وکړئ چې قواعد په کومو پېژندونکو پورې وتړل شول، نه دا چې ښودونکی کوم رنګ ښيي. په Linux کې یو قاعده کولای شي یو انټرفیس یا له هغه ډک ipset ونوموي؛ په Android کې VpnService ته د setUnderlyingNetworks له لارې ویل کېدای شي چې کومې لاندې شبکې تعقیب کړي. هر تړون هغه اړیکې ته اشاره کوي چې بدلېدو ته ده، او هر یو باید وروسته بیا ارزول شي.

لېږد په رښتیا څه بیا لیکي

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

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

بهرنی ټونل پرته له سوري کولو بیا جوړول

بهرنی لېږد له زړې سرچینې پتې سره تړل شوی و، نو باید له نوي څخه نوی ساکټ پرانیزي. کله چې پای نقطه لفظي پته نه بلکې د کوربه نوم وي، لټون باید هغه وخت بریالی شي چې بندول لا روان دي. دا د ترتیب دام دی: هغه پالیسي چې د پای نقطې پرته هر څه غورځوي، هغه لټون هم غورځوي چې د هغې موندلو لپاره اړین دی، پرته له دې چې حل مخکې له بند پورته کولو ترسره شي یا د لا ژوندي ټونل له لارې وړل شي. دواړه ترتیبونه کولای شي کار وکړي، خو یوازې هغه وخت چې پیرودونکی پوه شي چې په کوم ترتیب کې دی.

پیرودونکي دلته په داسې توګه توپیر لري چې په تشخیص کې مهم دي. ځینې لومړی حل کوي او بیا قواعد نصبوي، نو لېږد یو لیدل کېدونکی وقفه لري او بیا پخپله رغېږي؛ نور بندول ساتي او د لټون وړلو لپاره پر ژوندي پاتې ټونل تکیه کوي، چې کله ټونل له اړیکې سره مړ شي په بشپړه توګه ناکامېږي. د اړیکې د بېرته راوستلو لپاره پراخه مستقیمه تلواله لار زیاتول تل ازموینه بریالۍ کوي او تل هغه تېښته پرېږدي چې تاسو یې مخنیوی کاوه.

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

کله چې نوې اړیکه IPv6 راوړي او قواعد نه

سیلولر او مېلمنو شبکې ډېری وخت نړیوال IPv6 مختګ ورکوي، حتی کله چې د دفتر تار لرونکې LAN دا هېڅکله نه وي کړی. هغه پالیسي چې یوازې د IPv4 قواعدو په توګه لیکل شوې — د لاسي جوړو شوو iptables او nftables تر ټولو ډېرو لارښوونو تلواله بڼه — له دې څخه هېڅ نه پوښي. ټونل وتړل شوی پاتې کېږي، هغه اپلیکیشنونه چې IPv6 لاسرسی لري د هغې بهر ځي، او ښودونکی توپیر نه شي ښودلای ځکه ټونل رښتیا پورته دی. برعکس حالت هم هماغه ډول عام دی: یوازې د IPv6 لپاره د قواعدو ټولګه په هغه شبکه کې هېڅ نه کوي چې v6 نه وړاندې کوي.

د لېږد په دواړو غاړو کې پرتله کړئ چې اړیکه څه وړاندې کوي او پالیسي څه یادوي. دا حکمونه هماغه حقایق چاپ کوي چې پیرودونکی ورسره کار کوي:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

که دوهم حکم تلواله لار چاپ کړي او دریم صفر بېرته راوګرځوي، نو نوې اړیکه کولای شي ماشین د IPv6 له لارې بهر بوځي او هېڅ قاعده یې نه ګوري. له بدلون وروسته هر درې بیا چل کړئ، ځکه زړه راښکونکې شمېره د دواړو چلولو توپیر دی. که دوهم هېڅ ونه چاپوي، برعکس حالت پلي کېږي او هلته هر v6 درانه پالیسي یوازې ښکلا ده.

حل کوونکی د غونډې په مینځ کې لاسونه بدلوي

په عصري سیستمونو کې حل کوونکي له اړیکو سره تړلي وي، نو نوې اړیکه د نوي حل کوونکو ټولګې سره او کېدای شي د بل split-DNS لید سره راځي. systemd-resolved د هرې اړیکې لپاره یو سکاپ ساتي او د لارې له مخې د هغوی ترمنځ ټاکنه کوي، په داسې حال کې چې macOS له متحرک زېرمې څخه scoped حل کوونکي لولي او د انټرفیسونو ترتیب ته درناوی کوي. هغه پیرودونکی چې خپل حل کوونکی نصبوي له اړیکې سره سیالي کوي، او هغه لومړیتوب قواعد چې څوک یې نه ګوري ګټونکی فیصله کوي. بیا ممکن نوم حل مات شي، په داسې حال کې چې د بستې فلټر کول هغه څه کوي چې د هغوی لپاره لیکل شوي وو.

هغه حل کوونکی ولولئ چې فعال دی، نه هغه چې ترتیب شوی. په systemd کوربه کې status فرعي حکم ښيي چې هر سکاپ له کومې اړیکې راغی او آیا private-DNS نوم پلي دی:

resolvectl status --no-pager
resolvectl query intranet.example.com

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

لېږد تمرین کړئ او ریکارډ وساتئ

د انتظار پرځای په قصد بدلون بیا تولید کړئ. په لومړۍ اړیکه کې ټونل پورته کړئ، اوږد لېږد او تکراري لټون پیل کړئ، بیا اړیکه بدله کړئ او وګورئ کومه ژوندې پاتې کېږي. د زړې اړیکې د ورکېدو او د ټونل د وتړل کېدو راپور ترمنځ وقفه ولیکئ، ځکه په هماغه کړکۍ کې پالیسي ودرېده یا نه. ترتیب په بله خوا هم وچلوئ، تر څو پایله یو اړخیزه نه وي.

استثناوو ته خپل پړاو ته اړتیا ده، ځکه هغه تېرېدنه چې په زړه شبکه کې توجیه وه په نوې کې په اتوماتيک ډول توجیه نه ده. په کور LAN کې پرینټر، NAS یا captive portal په سیلولر کې سیال نه لري، او هغه استثنا چې هغوی ته رسېده بې سیاله قاعده ګرځي.

د هر لوري لپاره د انټرفیسونو نومونه، وړاندې شوې کورنۍ، پلي حل کوونکی او د وقفې اوږدوالی ولیکئ. بیا تړل ثابتوي چې لېږد ورغېده، نه دا چې بندول په تشه کې ودرېده، او دا د ټکټ لپاره جلا ادعاوې دي. له دې ریکارډ سره بله لېږدنه له معلوم حالت سره پرتله کېږي نه له یادې سره.