د VPN کلاینټانو مخه ونیسئ چې په ټنل کې یو بل ته ورسېږي

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

مشترک خدمت ته لاره د شریکانو ترمنځ اجازه نه ده

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

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

غوښتنه د ټرمینل پرانیستلو مخکې په یوه کرښه کې ولیکئ۔ د خدمتونو بلاک او ټوپ کوربه ته ورسېږئ، د کلاینټانو بلاک دننه بل څه ته مه رسېږئ۔

ومومئ چې د شریک بسته په رېښتیا څوک لېږي

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

WireGuard لومړي ګروپ کې دی: د شریکانو ترمنځ بدلونکی نلري، نو له 10.8.0.4 څخه 10.8.0.5 ته بسته پر wg0 راځه، د لېږد چنګک وهي او کله چې AllowedIPs دواړه پتې پوښي بیا له wg0 څخه لارېږي۔ OpenVPN دویم ګروپ دی، کله چې د سرور په ترتیب کې client-to-client ټاکل شوی وي، ځکه هغه لارښوونه بسته په کاروونکي فضا کې د غونډو ترمنځ سپاري۔ د څه لیکلو مخکې په بار شوي ترتیب کې هغه لارښوونه وګورئ۔ هغه هستوي قاعده چې هېڅکله ترافیک نه ویني له کار کوونکې قاعدې نه جلا کېدای نه شي، او همداسې یو ځای پرځای کول پرته له هېڅ جلا کېدنې پای ته رسېږي۔

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

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

هرې پتې ته داسې پېژندنه ورکړئ چې په خپله باطلېدای شي

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

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

منع هلته کېږدئ چې بسته ټنل تېروي

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

د nftables سره جوړه په شته inet filter جدول کې ننوځي، لومړی اجازه او بیا غورځول۔ دواړه سمونونه د پتو سره یوځای د مخونو جوړه ټینګوي۔

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

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

کله چې په OpenVPN کې client-to-client فعال وي، دا لېږد قاعدې هېڅکله د شریکانو ترافیک سره سمون نه خوري او منع باید د ډیمون په خپلو کنټرولونو کې وي۔ کوربه ته استول شوي ترافیک لپاره هستوي قاعدې وساتئ، خو دوی د جلا کېدنې کنټرول مه ګڼئ۔

منع له سرور څخه نه، له کلاینټ څخه ثابته کړئ

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

له اجازه لرونکي کلاینټ څخه تایید کړئ چې خدمت په خپله پورټ کې ځواب وایي۔ له هماغه کلاینټ څخه د شریک پته وآزموئ او د ردولو پرځای غلی غورځول تمه وکړئ:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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