ہب پر 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 تک رسائی الگ پالیسی والے الگ راستے ہیں۔ لکھیں کہ میٹرکس ان میں سے کس کس کو محیط ہے، کیونکہ صرف ساتھی سے ساتھی ٹریفک جانچنے والا امتحان ان میں سے کسی کے بارے میں کچھ نہیں کہتا۔