VPN منسلک ہے لیکن فائر وال اب بھی روک رہا ہے: کون سا ہے یہ کیسے جانیں

کلائنٹ کہتا ہے منسلک ہے، وسیلہ اب بھی انکار کرتا ہے، اور اگلا عام قدم کچھ بند کرنا ہے۔ اس جملے کے دونوں کنٹرول مختلف کام کرتے ہیں: VPN ڈھکے ہوئے ٹریفک کے لیے راستہ بناتا ہے، اور فائر وال ہر کنکشن کے لیے فیصلہ کرتا ہے کہ ٹریفک گزر سکتا ہے یا نہیں۔ انکار کرنے والی پالیسی کے ساتھ چلنے والا ٹنل صارف کی کرسی سے بالکل ٹوٹے ہوئے ٹنل جیسا دکھائی دیتا ہے، اس لیے کام یہ معلوم کرنا ہے کہ کون سی تہہ جواب دے رہی ہے۔ یہ وہ ترتیب ہے جو میں اپناتا ہوں، ساتھ وہ پڑھائی جو آپ کو رکنے کا کہتی ہے۔

راستے کو پالیسی سے الگ کریں

ناکامی کی شکل سے شروع کریں، کیونکہ یہ مفت معلومات ہے۔ پیکٹ گرنے سے وقت کی حد بنتی ہے: کلائنٹ دوبارہ کوشش کرتا ہے، کچھ واپس نہیں آتا، اور حکم ہار ماننے تک لٹکتا رہتا ہے۔ انکار سے انکار یا ری سیٹ بنتا ہے: کسی نے جواب دیا اور نہیں کہا۔ جو سروس نہیں سنتی وہ میزبان پر ہی انکار کرتی ہے، کسی فائر وال کے بغیر۔

یہ تین نتائج مختلف تہوں کی طرف اشارہ کرتے ہیں۔ وقت کی حد کا مطلب ہے کہ کہیں کوئی پالیسی خاموشی سے پھینک رہی ہے، یا راستہ کبھی مشین سے نہیں نکلتا۔ انکار کا مطلب ہے کہ آپ میزبان تک پہنچے اور اس کے اسٹیک یا مقامی فائر وال نے نہیں کہا۔ مکمل خاموشی، ٹنل انٹرفیس چالو اور منزل تک راستہ نہ ہونے کی صورت میں، مطلب ہے کہ راستہ غلط ہے اور کوئی فائر وال قاعدہ اسے درست نہیں کرے گا۔

راستہ ایک ہی بار میں پڑھیں

ایک بھی قاعدہ دیکھنے سے پہلے یقینی بنائیں کہ ٹنل منزل کو ڈھکتی ہے۔ جو اسپلٹ ٹنل صرف دفتر کا ذیلی نیٹ ورک لے جاتی ہے وہ درخواست کو دوسری حد میں نہیں بھیجے گی، اور پھر ناکامی فائر وال کی روک جیسی دکھائی دیتی ہے، جو وہ نہیں ہے:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

راستے کا آؤٹ پٹ بتاتا ہے کہ پیکٹ کس انٹرفیس سے نکلے گا اور کون سا ماخذ پتہ لے کر جائے گا۔ اگر وہ انٹرفیس ٹنل نہیں بلکہ آپ کا جسمانی نیٹ ورک کارڈ ہے، تو مسئلہ روٹنگ میں یا ٹنل کی اجازت شدہ حدود میں ہے، اور یہ فائر وال کا نہیں، VPN ترتیب کا ہے۔

VPN کے لیے مخصوص ایک جال اپنی الگ جانچ کا حقدار ہے۔ WireGuard میں ہم منصب کا AllowedIPs بیک وقت راستہ اور خفیہ نگاری کا فلٹر ہے: جس پیکٹ کا ماخذ پتہ ہم منصب کے اجازت شدہ مجموعے سے میل نہیں کھاتا وہ کسی بھی فائر وال قاعدے کو دیکھے جانے سے پہلے پھینک دیا جاتا ہے۔ اس لیے مکمل طور پر درست میزبان فائر وال بھی پالیسی جیسی دکھنے والی خاموش پھینک کے پیچھے ہو سکتا ہے، اور اصلاح قاعدہ نہیں بلکہ کلید کی ترتیب کی ایک سطر ہے۔

پالیسی اس تہہ میں پڑھیں جو جواب دیتی ہے

جب راستہ درست ہو، میزبان سے باہر کی طرف پالیسی میں چلیں اور اس ایک تہہ پر نظر رکھیں جس کے کاؤنٹر حرکت کرتے ہیں:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

سننے والا ساکٹ قواعد سے مختلف سوال کا جواب دیتا ہے۔ اگر پورٹ پر کچھ نہیں سن رہا، کرنل کنکشن سے انکار کرتا ہے اور کوئی اندرونی قاعدہ متعلقہ نہیں۔ اگر ساکٹ موجود ہے اور دور دراز کلائنٹ سے کنکشن وقت کی حد پر جاتا ہے، راستے میں کہیں پھینکا جا رہا ہے، اور قواعد کے کاؤنٹر بتاتے ہیں کہ یہ یہیں ہو رہا ہے یا نہیں۔

باہر سے اندازہ لگانے کے بجائے جس پروفائل یا زنجیر پر شک ہے اس کے لیے لاگنگ چالو کریں۔ ماخذ، منزل اور پورٹ بتانے والی ایک درج پھینک تہہ اور قاعدہ کی نشاندہی کرتی ہے، اور یہ بھی ثابت کرتی ہے کہ پیکٹ پہنچا، جو کلائنٹ کی طرف سے کوئی بھی جانچ ثابت نہیں کر سکتی۔

جب ٹنل وہیں ختم ہو تو گیٹ وے کا فیصلہ پڑھیں

سائٹ سے سائٹ یا دور دراز رسائی گیٹ وے پر، VPN صارف کی تصدیق کرتا ہے اور پالیسی وسیلے کی اجازت دیتی ہے، اور یہ الگ اجازتیں ہیں۔ ٹنل میں داخل ہونے والے صارف کو ہر اندرونی میزبان پر خود بخود داخلہ نہیں ملتا، اور انکار اکثر فارورڈنگ قاعدے سے آتا ہے جبکہ ٹنل خود صحت مند ہوتا ہے۔ یہی تقسیم IPsec میں بھی دکھائی دیتی ہے، جہاں ٹریفک چننے والی سکیورٹی پالیسی اسے داخل کرنے والے فلٹر سے مختلف ہے، اور اسی لیے دونوں کو الگ میکانزم کے طور پر RFC 4301۔

واپسی کا راستہ بھی جانے والے راستے جتنی احتیاط سے جانچیں۔ ریاستی فلٹرنگ کو جواب دیکھنا ضروری ہے، اس لیے ٹنل سے ایک سمت میں اور اس کے گرد دوسری سمت میں غیر متناسب روٹنگ ایسی پھینکیں بناتی ہے جو بے ترتیب لگتی ہیں اور صرف کچھ کلائنٹس سے دہرائی جاتی ہیں۔ اگر ٹریفک گیٹ وے تک پہنچ کر رک جائے، تو کچھ بھی بڑھانے سے پہلے فارورڈنگ قاعدہ اور واپسی کا راستہ ساتھ پڑھیں۔

گیٹ وے وہ جگہ بھی ہے جہاں NAT یا ماسکریڈ قاعدہ اصل ماخذ چھپا سکتا ہے۔ اگر اندرونی میزبان کلائنٹ کے بجائے گیٹ وے کا پتہ دیکھیں، تو کلائنٹ پول سے میل کھانے والے ان کے میزبان فائر وال قواعد کبھی میل نہیں کھائیں گے، اور اصلاح ہر سرور پر نہیں، گیٹ وے پر ہے۔

سب سے تنگ تہہ بدلیں، پھر تصدیق کریں

وسیع مرمت کی مخالفت کریں۔ میزبان فائر وال بند کرنا، سب کچھ اجازت دینے والا قاعدہ شامل کرنا، یا ہر انٹرفیس کو قابل اعتماد پروفائل میں دھکیلنا — ہر ایک وہ کنٹرول ہٹا دیتا ہے جو اپنا کام کر رہا تھا، اور تبدیلی واقعے کے بعد بھی رہتی ہے۔ ماخذ کی حد اور متعلقہ پورٹ تک محدود قاعدہ کا جائزہ آسان ہے، ہٹانا آسان ہے، اور مشین کی باقی پالیسی محفوظ رکھتا ہے۔

وہی جانچ جو ناکام ہوئی، اسی کلائنٹ سے تصدیق کریں، اور پھر دوبارہ منسلک ہونے کے بعد ایک بار اور، کیونکہ ٹنل کے دوبارہ مذاکرات سے پہلے میل کھانے والا قاعدہ بعد میں میل نہ کھا سکے:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

اسے بند کرنے سے پہلے:

• منزل کا راستہ ٹنل انٹرفیس سے نکلتا ہے، اور ماخذ پتہ اس سے میل کھاتا ہے جس کی پالیسی توقع کرتی ہے۔
• پورٹ پر کچھ سن رہا ہے، اور انکار یا وقت کی حد اندازہ نہیں، نامزد قاعدے کو منسوب کیا جاتا ہے۔
• گیٹ وے دونوں سمتوں میں فارورڈ کرتا ہے، اور منزل وہ ماخذ دیکھتی ہے جس کے لیے آپ کے قواعد لکھے گئے تھے۔
• جانچ پاس ہونے کے لیے کوئی کنٹرول بند نہیں کیا گیا، اور آپ کی تبدیلی ایک ماخذ کی حد اور ایک پورٹ بتاتی ہے۔