په هب کې د WireGuard همکار ګروپونه: د سرچینې مالکیت او تګلاره

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

دوه کارونه، جلا ساتل شوي

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

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

دواړه طبقې یوځای ډیزاین کړئ، بیا دواړه وآزمویئ۔ هغه ترتیب چې په یوه طبقه کې سم او په بله کې ناازمویل شوی وي د ډیفالټ له مخې خلاص یا بند ناکام کیږي۔

هر همکار ته یوازې د هغه خپله پته ورکړئ

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

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

هغه د لېږد تګلاره ولیکئ چې ګروپونه جلا کوي

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

لومړنۍ دوه قاعدې د هر ګروپ دننه ترافیک اجازه ورکوي۔ وروستې هغه هر څه بندوي چې هغه انټرفېس تېروي، او همدا د ګروپونو ترمنځ جلاوالی رامنځته کوي۔ که اړتیا وي د بلې پتې کورنۍ لپاره ښکاره قاعدې اضافه کړئ، ځکه چې د IPv4 لپاره لیکل شوی drop د IPv6 چلند نه اجازه ورکوي او نه تشریح کوي۔

ترتیب پریکړه کوي چې تګلاره پلي کیږي که نه

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

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

د فایلونو شمېر نه، میټریکس وآزمویئ

د تمه شوو پایلو یو کوچنی میټریکس جوړ کړئ او هر حجره وګورئ۔ له A ګروپ څخه A ګروپ ته باید کار وکړي، له B ګروپ څخه B ګروپ ته باید کار وکړي، او له A څخه B ته باید ونه کړي، په دواړو لورو او که تاسو ملاتړ کوئ په دواړو پتې کورنیو کې۔

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

لومړني دوه ښیي چې څه ترتیب شوي دي۔ د غلط ګروپ له غړي څخه ping ښیي چې واقعاً څه پیښیږي۔ conntrack لیست ښیي چې پخوانی بهیر لا هم منل کیږي که نه، او همدا راز د جلاوالي بدلون په چوپتیا کې نه پلي کیږي۔

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