resolvectl کی آؤٹ پٹ سے ہر لنک کے لیے VPN DNS روٹنگ کیسے پڑھیں
resolvectl status ہر لنک کے لیے سرورز، ڈومینز اور ڈیفالٹ راستہ دکھاتا ہے۔ انھیں ایک ساتھ پڑھیں، پھر نام پوچھیں اور نوٹ کریں کہ کون سے لنک نے جواب دیا۔
resolvectl status چلائیں تو ہر لنک کے لیے بلاکس کی دیوار ملتی ہے، ہر ایک کے اپنے سرورز اور اپنی ڈومین لائن ہوتی ہے۔ روٹنگ کا فیصلہ ڈومین فہرست کرتی ہے، نیم سرور کا پتہ نہیں، کیونکہ مقامی stub ہر سوال اُس لنک کو بھیجتا ہے جو نام کا دعویٰ کرتا ہے۔ جواب پڑھنے سے پہلے وہ دعوے پڑھیں، پھر نام پوچھیں اور دیکھیں کہ کس لنک نے اسے بنایا۔ درست لنک سے غلط جواب غلط لنک سے درست جواب سے مختلف مسئلہ ہے۔
ہر لنک بلاک آپ کو کیا بتاتا ہے
ہر بلاک وہ سرورز گنواتا ہے جو حل کنندہ اُس انٹرفیس کے لیے استعمال کرے گا، ڈومین فہرست اور یہ کہ لنک ڈیفالٹ راستہ ہے یا نہیں۔ ڈومین فہرست دعوؤں کا مجموعہ ہے، اور حل کنندہ طویل ترین لاحقے کی مطابقت لگاتا ہے: host.corp.example کا سوال corp.example والا لنک صرف ڈیفالٹ راستہ والے لنک سے پہلے دعویٰ کرتا ہے۔ ایک ہی لاحقے کا دعویٰ کرنے والے دو لنک نتیجہ ترجیح اور ترتیب پر چھوڑ دیتے ہیں، اسی لیے نقول پہلے توجہ کے لائق ہیں۔ موجودہ سرور لائن دکھاتی ہے کہ فہرست میں سے کون سا سرور اُس لمحے استعمال میں ہے۔
/etc/resolv.conf میں 127.0.0.53 جیسا stub پتہ صرف یہ بتاتا ہے کہ stub آگے ہے۔ یہ جواب دینے والے بالائی ماخذ کا نام نہیں لیتا، اسی لیے صرف resolv.conf پر مبنی تشخیص رک جاتی ہے۔
ڈومین اندراجات کی تین اقسام درست پڑھیں
| اندراج | کس چیز کا دعویٰ | عام غلطی |
|---|---|---|
| corp.example | روٹنگ ڈومین اور تلاش لاحقہ: اس کے نیچے کے نام اِس لنک پر جاتے ہیں، اور تار ننگے ناموں میں شامل کیا جاتا ہے | ہٹا دیا گیا کیونکہ روٹنگ بہرحال کام کرتی دکھتی ہے |
| ~corp.example | صرف راستہ: اس کے نیچے کے نام اِس لنک پر جاتے ہیں، مگر لاحقہ شامل نہیں ہوتا | روٹنگ کے لیے ضروری سمجھا گیا |
| ~. | ڈیفالٹ راستہ: اُن سوالوں کا دعویٰ کرتا ہے جنہیں کوئی دوسرا لنک نہیں ڈھکتا | منقسم پروفائل پر فعال چھوڑا گیا، اس لیے عوامی نام سرنگ کی پیروی کرتے ہیں |
ٹلڈا تلاش کا رویہ بدلتا ہے، روٹنگ نہیں۔ بغیر ٹلڈا اندراج روٹنگ ڈومین اور تلاش ڈومین دونوں ہے، اس لیے اس کے نیچے کے نام اُس لنک کو بھیجے جاتے ہیں اور یک لیبل ناموں میں لاحقہ شامل ہوتا ہے۔ ٹلڈا اندراج وہی لاحقہ روٹ کرتا ہے مگر اسے تلاش فہرست سے باہر رکھتا ہے۔ اسی لیے ٹلڈا ہٹانا بدلتا ہے کہ کون سے ننگے نام حل ہوتے ہیں، اور اسی لیے ٹلڈا کا نہ ہونا تلاش کا مسئلہ ہے، منقسم DNS کی ناکامی نہیں۔
ڈیفالٹ راستے کا اندراج اُس ہر چیز کا دعویٰ کرتا ہے جسے کوئی دوسرا لنک نہیں ڈھکتا۔ مکمل سرنگ پروفائل عام طور پر اسے چاہتا ہے اور منقسم پروفائل عام طور پر نہیں، کیونکہ پھر عوامی نام نجی حل کنندہ تک جاتے ہیں اور وہاں ناکام ہو سکتے ہیں۔ پروفائلز کے درمیان جھنڈے نقل کرنے کے بجائے پروفائل کے ارادے کے سامنے جدول پڑھیں۔ جب دو لنک ایک ہی لاحقے کا دعویٰ کریں، تو کچھ اور ترمیم کرنے سے پہلے ترجیح کا سوال طے کریں۔
نام پوچھیں اور دیکھیں کس لنک نے جواب دیا
query ذیلی کمانڈ پتہ، پروٹوکول اور وہ لنک یا دائرہ چھاپتی ہے جس نے جواب بنایا۔ نجی لاحقے کا دعویٰ کرنے والا ایک نام اور ایک عام عوامی نام جانچیں، پھر بتائے گئے ماخذ موازنہ کریں۔ اگر نجی نام بے تار لنک سے جواب دے، تو دعویٰ نہیں یا سرنگ بند ہے؛ اگر منقسم پروفائل میں عوامی نام سرنگ سے جواب دے، تو ڈیفالٹ راستہ بہت وسیع ہے۔ یہ دونوں ناکامیاں براؤزر میں یکساں اور اِس آؤٹ پٹ میں الٹ دکھتی ہیں۔
resolvectl status
resolvectl query host.corp.exampleبتائے گئے پروٹوکول پر بھی نظر رکھیں، کیونکہ کیش یا hosts فائل سے جواب کسی بالائی ماخذ سے پوچھے بغیر آ سکتا ہے۔ کیش سے جواب ثابت کرتا ہے کہ نام کبھی حل ہوا تھا، یہ نہیں کہ موجودہ پالیسی اسے درست طور پر روٹ کرتی ہے۔
نام کی روٹنگ کو پیکٹ کی روٹنگ سے الگ رکھیں
حل کنندہ کا فیصلہ راستہ نہیں بناتا۔ منتخب سرور کو اب بھی اپنے پتے تک راستہ درکار ہے، اور واپس ملے پتے کو اب بھی نجی نیٹ ورک میں راستہ درکار ہے، اس لیے درست DNS پالیسی ایسے کنکشن کے ساتھ رہ سکتی ہے جو کبھی نہیں کھلتا۔ جب نام حل ہو اور ایپلیکیشن ناکام ہو، تو دوبارہ DNS بدلنے کے بجائے پتہ اور راستہ دیکھیں۔ نام حل ہونا اور رسائی دو مختلف مالکان کے دو سوال ہیں۔
ایپلیکیشنز اپنی محفوظ DNS ترتیب یا شامل حل کنندہ کے ذریعے نظام کے حل کنندہ کو مکمل طور پر بائی پاس کر سکتی ہیں۔ resolvectl کا نتیجہ نظام کا راستہ بیان کرتا ہے، اور اسے نظر انداز کرنے والا براؤزر آپ کے ہر امتحان سے متصادم ہوگا۔ پالیسی ٹوٹی ہے یہ نتیجہ اخذ کرنے سے پہلے وہ ترتیب دیکھیں۔
جس پتے پر نام حل ہوا اسے لنک کے ساتھ نوٹ کریں۔ غلط پتے کی طرف اشارہ کرنے والا درست نام روٹنگ نہیں، ریکارڈ کا مسئلہ ہے۔
لنک بدلنے کے بعد دوبارہ دیکھیں
دوبارہ جڑنا یا بے تار تبدیلی لنک کی حالت دوبارہ بناتی ہے، اور نیٹ ورک مینیجر دستی طور پر مقرر ہر چیز کے اوپر اپنے ڈومینز اور سرورز دوبارہ نصب کر سکتا ہے۔ پھر وہی دو نام پوچھیں اور درج بنیادی لائن سے موازنہ کریں۔ اگر دستی ترمیم غائب ہو گئی ہو، اصلاح کنکشن پروفائل میں ہونی چاہیے شیل کمانڈ میں نہیں۔ پہلے اور بعد میں درج کرنا ہی اسے نمایاں کرتا ہے۔
صرف وہی نام اور سرور سیاق شریک کریں جو رپورٹ کو درکار ہیں، کیونکہ اندرونی لاحقے ٹوپولوجی ظاہر کرتے ہیں۔ ڈومین روٹنگ پر systemd-resolved کی دستاویز طویل ترین مطابقت کا قاعدہ اور ٹلڈا کا رویہ بیان کرتی ہے، اور ایک بار پڑھنا اوپر کے جدول کی بیشتر غلطیاں روک دیتا ہے: systemd-resolved میں سوال کی روٹنگ۔