VPN کا DNS ہر تلاش لیتا ہے: NetworkManager میں dns-priority درست کریں

دفتر کے VPN سے جڑیں اور اچانک ہر نام کی تلاش کارپوریٹ ریزولور کی طرف چلی جاتی ہے۔ عوامی نام اب بھی حل ہوتے ہیں، اس لیے کچھ بگڑا ہوا نظر نہیں آتا جب تک مقامی پرنٹر کا نام ناکام نہ ہو یا split-horizon ریکارڈ دفتر کا پتہ واپس نہ دے۔ کچھ Fedora ترتیبات میں اس کا الٹ ہوتا ہے: ISP کا ریزولور ٹنل اوپر آنے کے بعد بھی جواب دیتا رہتا ہے۔ دونوں ایک ہی سوال ہیں — یہ استفسار کس ریزولور کی ملکیت ہے — اور NetworkManager نظاموں میں جواب ہر کنکشن کی DNS خصوصیات میں رہتا ہے۔

دو کنکشن، ایک جیتنے والا ریزولور

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

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

ترجیح ترتیب طے کرتی ہے، تلاش فہرست ملکیت طے کرتی ہے

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

تلاش فہرست ملکیت کا اعلان ہے۔ corp.example جیسا ننگا ڈومین تلاش لاحقہ اور روٹنگ ڈومین بن جاتا ہے۔ صرف روٹنگ والی شکل ~corp.example اس لاحقے کے تحت تلاشیں ڈومین کو مختصر ناموں میں شامل کیے بغیر اس کنکشن پر بھیجتی ہے۔ وہی ٹلڈا «اس سرور سے پوچھو» اور «اس سرور سے پوچھو اور میری ٹائپنگ مکمل کرو» کے درمیان فرق ہے۔

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

پھر ترجیح کو واضح کریں اور دوبارہ فعال کریں:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

منفی ترجیح «اس کنکشن کو ترجیح دو» کہنے کا مستند طریقہ ہے، اور دونوں پتہ خاندانوں کو مقرر کرنا IPv6 کنیکٹیویٹی والے ہوسٹ پر رویہ یکساں رکھتا ہے۔ کنکشن کو دوبارہ فعال کیے بغیر خصوصیت بدلنے سے اب چل رہی کسی چیز میں تبدیلی نہیں آتی، اسی لیے ترتیب واضح up پر ختم ہوتی ہے۔

تقسیم systemd-resolved کے پاس رہنے دیں

طے شدہ dnsmasq پلگ ان استفسارات ایک مقامی ریزولور میں ڈالتا ہے، اس لیے فی لنک علیحدگی موٹی رہتی ہے۔ systemd-resolved ہر لنک کے لیے تقسیم ظاہر کرتا ہے، اور resolvectl query جواب دینے والے لنک کا نام بتاتا ہے۔

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

اس کے بعد کارپوریٹ لنک corp.example اٹھاتا ہے اور عوامی ریزولور باقی کی خدمت کرتا ہے۔ جب استفسار غلط لنک پر پہنچتا ہے، کمانڈ اس لنک کا نام بتاتی ہے جس نے اس کا جواب دیا، اور یہ جاننا صرف پتہ جاننے سے بہتر ہے۔

DNS ڈیزائن کو ٹنل کی قسم سے ہم آہنگ کریں

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

پھر وہ kill switch ہے جو ٹنل سے باہر DNS روکتا ہے۔ نام ٹنل کے زونز کے لیے حل ہوتے ہیں اور باقی ہر جگہ ناکام ہوتے ہیں جبکہ کنکشن بالکل صحت مند ہے۔ قابل عمل جوابات LAN ریزولور کے لیے واضح اجازت یا ایسا مقامی کیش ہیں جو صرف کارپوریٹ زون آگے بھیجے، اور دونوں میں سے کوئی بھی ٹنل میں خرابی نہیں بلکہ مالک والا استثنا ہے۔

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

ہر لنک پر جانچیں، پھر دوبارہ منسلک ہونے کے بعد پھر جانچیں

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

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