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 انکار کو مؤثر دکھاتا ہے۔ قبول شدہ اور رد شدہ نتائج تاریخ کے ساتھ رن بک میں درج کریں، کیونکہ اگلی منتقلی قاعدہ دوبارہ نکالے گی۔