یوه اپلیکیشن د WireGuard له لارې: تړل روټینګ نه دی

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

دغه میکانزم دوه نیمایي لري: د لارښوونې جدول چې یوازې د تونل ترافیک باید وکاروي، او یو قانون چې سمونکې سرچینه هلته واستوي۔

تړل د سرچینې پته ټاکي، نه نور څه

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

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

تونل ته خپل جدول ورکړه

wg-quick لارې هلته ځای پرځای کوي چې پروفایل وایي۔ [Interface] لاندې Table = 40 اضافه کول هغوی اصلي جدول پرځای جدول 40 ته لېږدوي۔ انټرفیس پورته کړه او تایید کړه چې رسېدلي دي: ip -4 route ls table 40 باید د تونل لارې وښيي، او ip -4 route get 10.66.127.142 ښيي چې کرنل اوس د هغوی یوه څنګه حل کوي۔ کله چې لارې په خپل جدول کې وي، اصلي جدول د نورو ټولو لپاره کار کوي۔

همدا کار IPv6 لپاره وکړه، نه دا چې پراخ مخکښ سره سمون وکړه۔ ip -6 rule add from fd00::2/128 lookup 40 یوه پته ټینګوي؛ fc00::/8 کولای شي له نورو انټرفیسونو سره ټکر وشي او داسې قانون جوړ کړي چې له ارادې ډېر سمون وکړي۔

د سرچینې قانون اضافه کړه او کاونټرونه وګوره

بیا دوه نیمایي سره ونښلوه: ip -4 rule add from 10.66.127.142/32 lookup 40، هماغه پته د WireGuard انټرفیس سره نښلولې وساته۔ دواړه قوانین PostUp کې کېږده چې بیا وصلېدل هغوی بېرته راولي۔ په ریښتیني غوښتنه ازموینه وکړه نه په ترتیباتو: ip route get 1.1.1.1 from 10.66.127.142 باید د تونل وسیله ونوموي، او curl --interface wg0 ifconfig.me باید د کور پتې پرځای د تونل پته راپور کړي۔

کله چې لا هم ناکام شي، ip -s rule ولوله۔ هغه قانون چې شته خو هیڅکله نه سم شوی صفر کاونټرونه ښيي، او دا غلط قانون له هغې چې قانون نه وي بېلوي۔ هماغه یو حکم د دې اړه ډېر اټکل بچ کوي چې ایا اپلیکیشن خپل د انټرفیس ترتیب له پامه غورځولی و۔

په برعکس حالت: SSH له تونله بهر وساته

برعکس ستونزه هم همدومره عامه ده: wg-quick د تلوالې لارې خاوند دی او سرور ته SSH سیشن په نیمایي کې مري۔ د هغه قوانین په ټیټ لومړیتوب شمېره کې ناست دي، نو استثنا باید له هغوی دمخه ارزول شي۔ ip rule add dport 22 ipproto tcp table main priority 123 دا په نوي iproute2 کې کوي؛ چېرې چې غوره کوونکی نشته، بهیر په nftables کې نښه کړه او پرځای یې نښه سره سمون وکړه۔

د ځواب لاره هم وګوره۔ هغه SSH سیشن چې جوړ شي او بیا چوپ شي معمولاً نامساوي لارښوونه لري: یو لوری له تونله او بل له فزیکي انټرفیس څخه وځي۔ د سرور پتې لپاره ip route get وایي چې ځواب کوم لوري ته ځي۔

د جدول شمېره، د سرچینې قانون او استثنا په خپل پروفایل کې ولیکه۔ درېواړه یوې ډیزاین پورې اړه لري او یوځای به سم شي۔