DNS تبدیلیوں کے بعد بھی WireGuard پرانا اینڈ پوائنٹ استعمال کرتا ہے

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

نام ایک ہی بار حل ہوتا ہے، مسلسل نہیں

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

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

ریکارڈ کا موازنہ زیر استعمال پتے سے کریں

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

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

ان سطروں میں استعمال ہونے والے show ذیلی کمانڈز wg(8) کتابچے میں درج ہیں۔ پتے کے ساتھ پتے کی فیملی بھی موازنہ کریں، صرف پتہ نہیں، کیونکہ IPv6 اندراج پا چکا ریکارڈ اس ریکارڈ سے مختلف موازنہ ہے جس کا IPv4 پتہ بدلا ہو۔ اگر اینڈ پوائنٹ ریکارڈ سے مختلف ہے تو انٹرفیس پرانی معلومات پر چل رہا ہے اور نام کبھی مسئلہ نہیں تھا۔ اگر دونوں ملتے ہیں اور ٹنل پھر بھی ناکام ہوتا ہے، تو پروفائل کی بجائے سننے والے اور قواعد کی طرف جائیں۔

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

انٹرفیس کے مینیجر کے ذریعے دوبارہ شروع کریں

اینڈ پوائنٹ کے پرانا ثابت ہونے کے بعد، انٹرفیس کی ملکیت والے طریقہ کار کے ذریعے اسے ریفریش کریں چلتی کنفیگریشن میں ترمیم کرنے کی بجائے۔ wg-quick سے شروع کیا گیا انٹرفیس ہو تو یہ نیچے اور اوپر ہے، systemd یونٹ ہو تو یہ دوبارہ آغاز ہے، اور مینیجر کی ملکیت والا انٹرفیس ہو تو یہ اسی مینیجر میں کیا گیا تبدیلی ہے، کیونکہ دوران کار ترمیم اگلی بار لاگو ہونے پر اوپر لکھ دی جاتی ہے:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

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

پہلے ہاتھ ملانا، پھر ڈیٹا راستہ

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

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