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

استفسار کس حل کنندہ تک پہنچا؟

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

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

ایسا پتہ استعمال کریں جس پر کلاؤڈ نیٹ ورک واقعی جواب دیتا ہے

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

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

ٹنل نام کی جگہ نہیں اٹھاتا

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

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

حدود کو ترتیب سے پار کریں

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

لکھیں کہ کون سا قدم ناکام ہوا۔ وہی ایک سطر اگلے شخص کو درکار ہے، اور اسے درج کرنے میں دس سیکنڈ لگتے ہیں۔

زنجیر وہاں رکھیں جہاں اگلا شخص اسے پا سکے

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

ریکارڈ کو درست رہنے کے لیے کافی مختصر رکھیں: چار سطریں، ایک تاریخ، اور ہر حصے کے مالک کا نام۔ پرانہ ریکارڈ نہ ہونے سے بدتر ہے، کیونکہ وہ غلط ہونے کے باوجود مستند دکھتا ہے۔

متعلقہ مضامین