UDP اسکین کہتا ہے فلٹر شدہ: کیا آپ کا WireGuard ساتھی واقعی بند ہے؟

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

اس کے بجائے کلائنٹ سے باہر کی طرف کام کریں، اور اسکین کو کئی کمزور ڈیٹا نکات میں سے ایک سمجھیں۔

اسکینر کیا دیکھ سکتا ہے اور کیا نہیں

UDP اسکینر ایک پے لوڈ بھیجتا ہے اور انتظار کرتا ہے۔ اگر ICMP port-unreachable واپس آئے تو یہ پورٹ کو بند بتا سکتا ہے۔ اگر کچھ واپس نہ آئے تو نتیجہ بناوٹی طور پر مبہم ہے: فلٹر شدہ راستہ، غائب میزبان اور چلتی ہوئی سروس جس نے پے لوڈ کو نظر انداز کیا، سب وہی خاموشی پیدا کرتے ہیں۔ تین مختلف حالتیں، ایک آؤٹ پٹ سٹرنگ۔

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

اسی پورٹ نمبر پر TCP ٹیسٹ کسی متعلقہ چیز کی جانچ نہیں کرتا۔ یہ ایک اور سننے والا چلاتا ہے جو شاید موجود نہ ہو، اور اس کا انکار UDP کے بارے میں کچھ نہیں کہتا۔

اس لیے کھلی فلٹر شدہ حالتیں اسکینر کی غیر یقینی کو آپ کے سرور سے زیادہ درست بیان کرتی ہیں۔

اصل کلائنٹ کو پروفائل سے اندر تک چلیں

خود کلائنٹ کے نظریے سے شروع کریں۔ کیا انٹرفیس کے پاس پتہ ہے، کیا کنفیگریشن درست اینڈ پوائنٹ بتاتی ہے، اور کیا کنکشن کی کوشش پر ہینڈ شیک کاؤنٹر حرکت کرتا ہے؟ وہ کلائنٹ جس نے کبھی پیکٹ نہیں بھیجا اور وہ کلائنٹ جس کے پیکٹ گرائے گئے، اسٹیٹس ونڈو میں ایک جیسے نظر آتے ہیں۔ صرف کاؤنٹر انہیں الگ کرتے ہیں، اس لیے پہلے کاؤنٹر پڑھیں۔

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

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

جب آپ سرور کا انتظام کریں تو وہیں ربط قائم کریں

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

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

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

اسکین کے نتیجے کو دیانت سے پڑھنا

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

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

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