ایا بشپړ ټنلنګ د اوږد سپلټ-ټنل لیسټ څخه ساده دی؟

د سپلټ-ټنل لیسټ په درې اپلیکیشنونو پیلېږي او د ماشین ډېره برخه پوښي، او هر نوی کرښه د یو چا استثنا ده. په دغه ټکی لیسټ په خاموشۍ سره د اضافي ګامونو سره ډیفالټ شوی دی. بشپړ ټنلنګ ترتیب برعکس کوي: هر څه ټنل ته ننوځي، پرته له دې چې مستنده استثنا بل څه ووايي. چې دا ساده دی که نه، په ګېټوې او هغو سیمهییزو خدماتو پورې اړه لري چې ته به یې مات کړې.

د هغو قواعدو په شمېرلو پیل وکړه چې ته یې ساتې

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

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

که ډېری ننوتنې د ترافیک لویه برخه رونده کړي، ته لا دمخه بشپړ ټنل د ساتنې بار سره چلوې. پرېکړه بیا د دې په اړه ده چې ډیفالټ چېرته اوسېږي، نه د دې چې ډیفالټ ولرو که نه.

وګوره چې ګېټوې ډیفالټ پورته کولای شي که نه

بشپړ ټنلنګ هره کڅوړه یوې وسیلې ته لېږي، کوم چې د هغې وسیلې CPU بار، conntrack جدول، پته ژباړه او د پورتنۍ لوري بانډوېډت اړتیا په یو وخت بدلوي. هغه ګېټوې چې څو داخلي سبنیټونه یې په اسانۍ خدمت کول، ممکن د یو کارونکي د ټول براوزینګ لپاره نه وي اندازه شوې. د اوسط پر ځای تر ټولو لویه تمه شوې هممهاله غونډو شمېره وګوره، ځکه لوړه څوکه لومړی ماتېږي.

ip -s link show dev tun0
conntrack -C
ss -s

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

د لارې MTU هم له سره تر سره وګوره، ځکه بشپړ ډیفالټ هره اپلیکیشن د ټنل د اعظمي کڅوړې اندازې سره مخامخ کوي. هغه اپلیکیشنونه چې د ټنل څخه بهر کار کول، اوس ممکن د پارچې کېدو هغه چلند پورې تړلي وي چې ته هیڅکله فکر کول نه و کړي.

تایید کړه چې سیمهییز خدمات او شخصي DNS لا هم کار کوي

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

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

سیمهییز استثناوې په هغه پروفایل کې ولیکه چې مالک یې دی. یوازې د یو چا په یاد کې ساتل شوې استثنا لومړنۍ هغه ده چې بله مهاجرت یې له لاسه ورکوي.

یو پروفایل مهاجر کړه او پولې تایید کړه

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

بیا دوه پولې جلا جلا تایید کړه: چې عمومي او شخصي منزلونه دواړه کار کوي، او چې نه غوښتل شوی ترافیک له ټنل څخه بهر نه وځي. یو بریالی د پاڼې بارېدل لومړی ثابتوي او د دوهم په اړه هیڅ نه وايي.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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