کون سا لنک جواب دیتا ہے: split-tunnel VPN DNS کے لیے روٹنگ ڈومینز

عام براؤزنگ مقامی لنک پر رکھیں، جبکہ کمپنی کے نام اُس DNS سرور کے ذریعے حل ہوں جو ٹنل فراہم کرتا ہے۔ VPN کا ڈیفالٹ راستہ بند کرنے سے پہلا نصف ملتا ہے اور دوسرا نصف بنائے بغیر رہ جاتا ہے۔ آگے وہ ترتیب ہے جو غائب ہے، وہ رموزِ اوقاف جو اُس کا مطلب بدلتے ہیں، اور وہ واحد حکم جو دکھاتا ہے کہ کون سے لنک نے واقعی جواب دیا۔ پورے متن میں NetworkManager اور systemd-resolved فرض کیے گئے ہیں، کیونکہ الجھن عام طور پر اسی جوڑے سے شروع ہوتی ہے۔

پہلا قدم: راستے کو حل کنندہ سے الگ کریں

ipv4.never-default راستے کے سوال کا جواب دیتا ہے اور NetworkManager کو روکتا ہے کہ یہ کنکشن تمام IPv4 ٹریفک کا راستہ نہ بنائے۔ DNS روٹنگ ڈومین ایک اور سوال کا جواب دیتا ہے: کس لنک کے نام سرورز کو ملتے جلتے لاحقے کے لیے استفسار ملتا ہے۔ کوئی بھی دوسرے کو لازم نہیں کرتا، اور ایک پروفائل برسوں ایک رکھ سکتا ہے جبکہ دوسرا غائب ہو۔ صرف راستہ کا مطلب ہے کہ ٹنل کمپنی کے ذیلی نیٹ ورک لے جاتی ہے اور اُس کا حل کنندہ کمپنی کے ناموں کا جواب دیتا ہے، جبکہ باقی سب کچھ اچھوتا رہتا ہے۔

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

دوسرا قدم: پروفائل میں صرف-روٹنگ ڈومین شامل کریں

فرض کریں کہ کنکشن کا نام corp-vpn ہے، کمپنی کا لاحقہ internal.example ہے، اور ٹنل کا حل کنندہ پہلے سے قابلِ رسائی ہے۔ پہلے موجودہ اقدار پڑھیں، کیونکہ نیچے دیے گئے اوامر ایسی خصوصیات بدلتے ہیں جن میں پہلے سے اندراجات ہو سکتے ہیں۔

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

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

آغاز کا ٹلڈا صرف-روٹنگ ڈومین کی نشان دہی کرتا ہے، اس لیے ملتے جلتے استفسارات اسی لنک کے سرورز کو جاتے ہیں اور لاحقہ مختصر ناموں میں شامل نہیں ہوتا۔ ٹلڈا ہٹائیں تو وہی سٹرنگ تلاش کا لاحقہ بھی بن جاتی ہے، جو ایک مختلف نتیجہ ہے اور لوگ شاذ و نادر ہی اُس کا ارادہ کرتے ہیں۔ اوپر کی دونوں ترتیبات IPv4 ہیں، اس لیے دوہرے اسٹیک والے پروفائل کو ipv6.never-default اور ipv6.dns-search میں وہی روٹنگ ڈومین چاہیے، ورنہ IPv6 طرف ڈیفالٹ راستہ استعمال کرتا رہے گا اور وہاں اندرونی نام ناکام ہوں گے۔

تیسرا قدم: resolvectl سے پوچھیں کہ کون سے لنک نے جواب دیا

resolvectl status چلائیں اور ہر لنک کے DNS سرورز اور ڈومینز پڑھیں، پھر کسی حقیقی اندرونی نام پر resolvectl query host.internal.example چلائیں جسے پوچھنے کی آپ کو اجازت ہے۔ دوسرا حکم ہی واحد براہِ راست ثبوت ہے کہ روٹنگ ڈومین اپنا کام کر رہا ہے، کیونکہ وہ اُس لنک کا نام لیتا ہے جس نے جواب دیا۔ صرف حالت کی فہرست ترتیب کو ثابت کرتی ہے؛ استفسار حل کو ثابت کرتا ہے۔

systemd-resolved بہترین مماثلت والا روٹنگ ڈومین منتخب کرتا ہے، اس لیے دوسرے لنک کا زیادہ مخصوص ڈومین اب بھی دوڑ جیت سکتا ہے۔ اگر استفسار کسی غیر متوقع لنک سے واپس آئے تو VPN کے DNS سرور کو چھونے سے پہلے ڈومین فہرستیں پڑھیں۔ ~. جڑ ڈومین ہر چیز سے مماثل ہے، اور اگر وہ پہلے سے موجود ہو تو آپ کا مخصوص ڈومین اپنے ناموں کے لیے اب بھی جیتتا ہے جبکہ لنک آپ کی درخواست سے کہیں زیادہ کا جواب دیتا ہے۔ جب مقصد صرف کمپنی کے نام تھے تو وہ جڑ اندراج ہٹا دیں یا تنگ کریں۔

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

چوتھا قدم: جب نام حل ہو لیکن سروس نہیں

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

اس سوال کے ساتھ گھومنے والی Samba تبدیلی رسائی کی تہہ سے متعلق ہے، DNS کے انتخاب سے نہیں۔ اُسے نام حل کی خرابی پر لاگو کرنا ہی چھوٹے مسئلے کے دوسرا مسئلہ پانے کا طریقہ ہے۔

پانچواں قدم: غائب ڈومین درست کرنے کے لیے حل کنندہ نہ بدلیں

وہ مشورہ جو حل کنندہ کی فائل پر لکھ دے یا دوسرا حل کنندہ منتظم نصب کرے، کسی اور مسئلے کو حل کرتا ہے۔ وہ نظام کے انضمام کی تبدیلیاں ہیں جن کے اپنے ناکامی کے طریقے ہیں، اور اُن میں سے کوئی بھی ایسا روٹنگ ڈومین شامل نہیں کرتا جو کبھی ترتیب نہیں دیا گیا۔ بدلنے سے پہلے طے کریں کہ مشین پر نام حل کرنا کس جزو کی ملکیت ہے، کیونکہ systemd-resolved والے NetworkManager ڈیسک ٹاپ پر وہ ملکیت پہلے ہی متعین ہے۔ اُس سے لڑنا ہی کام کرنے والی ترتیب کو ایسی چیز بناتا ہے جسے کوئی دوبارہ نہیں بنا سکتا۔

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