WireGuard کی مصافحہ کام کرتا ہے، سروس نہیں

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

جو پہلا پورا نہ اترے وہیں رکیں، اور باقی کے لیے قواعد نہ بڑھائیں۔

مصافحہ صرف ٹنل ثابت کرتا ہے

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

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

سننے والا اور راستہ پڑھیں

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

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

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

مقامی ان پٹ کے لیے قواعد لگائیں، فارورڈنگ کے لیے نہیں

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

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

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

نام، حجم اور شناخت کی ناکامیوں کو الگ کریں

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

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

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