OpenVPN کا بھیجا ہوا DNS نظر انداز: کون سا جزو اسے لاگو کرتا ہے

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

بھیجا گیا اختیار پیشکش ہے، تنصیب نہیں

سرور پر دو ہدایات اثر نہیں، ارادہ بیان کرتی ہیں:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

کلائنٹ کو ترتیب شدہ ریزولور نہیں ملتا۔ اسے ماحولی متغیرات ملتے ہیں، foreign_option_1 اور اگلے، ہر بھیجی گئی سطر کے لیے ایک، اور کوئی مقامی چیز انہیں پڑھ کر آپریٹنگ سسٹم کی ریزولور حالت دوبارہ لکھتی ہے۔ Linux پر طے شدہ طور پر کوئی ایسا نہیں کرتا، اسی لیے درست سرور اور منسلک کلائنٹ پھر بھی LAN کے ذریعے نام حل کر سکتے ہیں۔

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

تصدیق کریں کہ بھیجنا پہنچا اور مالک تلاش کریں

آغاز لانچر کا نام لے کر کریں: ایک ننگا openvpn کمانڈ، systemd مثال، NetworkManager یا وینڈر کلائنٹ۔ یہ طے کرتا ہے کہ ہک کہاں رہ سکتا ہے۔ systemd-resolved والے میزبان پر، resolvectl status ہر لنک کو اس کے واقعی استعمال شدہ DNS سرورز اور تلاش ڈومینز کے ساتھ فہرست کرتا ہے، اور ٹنل لنک کا نام ہمیشہ tun0 نہیں ہوتا۔

اگر بھیجا گیا پتہ لاگ میں ہے مگر کسی لنک پر نہیں، تو انضمام موجود نہیں۔ اگر وہ لنک پر ہے اور استفسار پھر بھی کہیں اور جاتے ہیں، مسئلہ یہ ہے کہ کون سے استفسار اس لنک کو منتخب کرتے ہیں۔ NetworkManager dns=dnsmasq فائل میں /etc/NetworkManager/NetworkManager.conf مقامی فارورڈر چلاتا ہے جو منقسم DNS جان بوجھ کر لاگو کرتا ہے: VPN ڈومین کے اندر کے نام VPN ریزولور کو جاتے ہیں اور باقی سب اپنا سابقہ راستہ رکھتا ہے۔ یہ رویہ خرابی جیسا لگتا ہے جب آپ کو توقع تھی کہ ساری ٹریفک منتقل ہو جائے گی؛ فی کنکشن ترتیبات دیکھیں nmcli connection show "My VPN" کے ذریعے، جہاں ipv4.dns اور ipv4.dns-search ڈیوائس کی رپورٹ کے پیچھے موجود اقدار رکھتے ہیں، اسے ٹوٹا کہنے سے پہلے۔ اگر ہر استفسار واقعی VPN ریزولور تک پہنچنا چاہیے، تو ہٹائیں dns=dnsmasq کو NetworkManager.conf فائل سے اور NetworkManager دوبارہ شروع کریں، جو ناموں کا حل کنکشن ترتیبات کو واپس دیتا ہے؛ ورنہ منقسم DNS رکھیں اور بھیجی گئی ڈومین فہرست درست کریں۔

Linux: اختیارات ریزولور کو دیں

ڈسٹری بیوشن پیکجز اس کے لیے ہک دیتے ہیں، اور کلائنٹ کو اسے چلانے کی اجازت ہونی چاہیے۔ systemd-resolved کے بغیر میزبان پر عام ترتیب:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved کے ساتھ پرانی resolv.conf اسکرپٹ شاید کچھ اہم تبدیل نہ کرے، کیونکہ stub ریزولور فی لنک حالت رکھتا ہے۔ update-systemd-resolved معاون ایسی ہک شکل کی دستاویز کرتا ہے جو up-restart اور down-pre استعمال کرتی ہے، جو تب اہم ہے جب انٹرفیس ایک کنکشن کوشش سے زیادہ قائم رہے۔ آپ جو بھی منتخب کریں، حالت کی ملکیت ایک ہی جزو کے پاس ہونی چاہیے۔ NetworkManager کے ساتھ غیر متعلق ہک شامل کرنے سے ایک ہی لنک کو دو لکھنے والے مل جاتے ہیں، اور نتیجہ پھر آپ کی ترتیب کے بجائے ترتیبِ وقوع پر منحصر ہوتا ہے۔

ایک ایسا موقع بھی ہے جب NetworkManager نے بھیجے گئے اختیار کو مکمل نظر انداز کیا جب تک سرور کا پتہ کنکشن کی IPv4 ترتیبات میں درج نہ ہوا، پھر ریزولور حالت نے اسے زیرِ استعمال دکھایا۔ اسکرپٹس دوبارہ لکھنے سے پہلے اسے آزمانا قابلِ قدر ہے، کیونکہ یہ مسئلہ شیل ہک سے اس کنکشن پروفائل میں منتقل کرتا ہے جو پہلے ہی ٹنل اٹھائے ہوئے ہے۔

Windows اور macOS مختلف حصے لاگو کرتے ہیں

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

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

اگر پتہ نہیں، تو اس سے مقرر کریں Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1، پھر لاحقہ اڈاپٹر کی IPv4 خصوصیات میں شامل کریں تاکہ fileserver بن جائے fileserver.corp.example۔ مشین بھر میں SearchList قیمت Tcpip\Parameters کے تحت بھی وہی کرتی ہے۔ جہاں لمبا نام حل ہو اور ننگا نہ ہو، وہاں ریزولور پہلے ہی درست ہے اور قصور تلاش فہرست کا ہے۔ اصلاحات ترتیب سے: بھیجیں ایک DOMAIN تاکہ کلائنٹ لاحقہ سیکھے، وہ لاحقہ اڈاپٹر یا کنکشن کی تلاش فہرست میں شامل کریں، اور عارضی اقدام کے طور پر نام یہاں مستحکم کریں hosts فائل میں، یا LMHOSTS میں Windows پر؛ NetBIOS براؤزنگ راؤٹر سے نہیں گزرتی، اس لیے دفتری LAN پر مختصر نام تلاش کرنے والا براڈ کاسٹ کبھی ٹنل کلائنٹ تک نہیں پہنچتا۔

block-outside-dns block-outside-dns Windows کلائنٹ کا رویہ ہے، قابلِ نقل پروفائل سطر نہیں، اور اسے Linux یا macOS پروفائل میں نقل کرنے سے وہ وہاں دوبارہ پیدا نہیں ہوتا۔ اگر Windows پر عوامی نام کام کریں اور اندرونی ناکام ہوں، تو اعلیٰ درجے کی ترتیبات کے تحت اڈاپٹر ترتیب کا موازنہ کریں ipconfig /all سے۔ macOS پر فی سروس ریزولور ترتیب سسٹم کی ہے، لہٰذا استعمال کریں scutil --dns یہ دیکھنے کے لیے کہ کس ڈومین کے لیے کون سا ریزولور پوچھا جاتا ہے، اور کسی بھی واحد رپورٹ شدہ پروفائل اصلاح کو عام نہیں بلکہ کلائنٹ پر منحصر سمجھیں۔

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

تاریخ تیسرا سبب ہے۔ پچھلے پروفائل کے DNS سرورز یا لاحقہ ترتیبات دوبارہ کنکشن پر قائم رہ سکتی ہیں، لہٰذا جب اڈاپٹر درست دکھے اور تلاش پھر بھی ناکام ہو، زندہ اڈاپٹر کا موازنہ کریں Get-VpnConnection سے اور سرور کو چھونے سے پہلے پرانا اندراج مٹائیں یا دوبارہ لکھیں۔

ثابت کریں کہ استفسار کہاں گیا

ایک تلاش کے دوران کیپچر بحث ختم کرتا ہے: tcpdump -ni eth0 port 53 طبعی انٹرفیس پر استفسار دکھاتا ہے، یعنی وہ ٹنل سے باہر جا رہے ہیں اور ریزولور کبھی تبدیل نہیں ہوا۔ dig @10.8.0.1 name.corp.example پھر باقی دو صورتوں کو الگ کرتا ہے۔ اگر براہِ راست استفسار جواب دے، ریزولور کام کر رہا ہے اور کلائنٹ اسے استعمال نہیں کر رہا؛ اگر وقت ختم ہو، ریزولور ٹنل کے ذریعے ناقابلِ رسائی ہے اور کوئی مقامی تبدیلی مدد نہیں دے گی۔

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

رسائی میں VPN میزبان کا فائر وال بھی شامل ہے، جسے پول سے UDP اور TCP 53 کی اجازت دینی چاہیے۔ بند پورٹ بالکل ٹوٹے ہوئے بھیجے کی طرح لگتا ہے، اور ایسا ہی وہ ریزولور جو صرف ٹنل نیٹ ورک کے اندر سے جواب دے۔ ایک بار منقطع اور دوبارہ منسلک ہونے کے بعد کیپچر دہرائیں، کیونکہ پہلے کنکشن پر ظاہر اور دوسرے پر غائب ہونے والی ترتیبات ہک میں دورانِ حیات نقص ہیں، گمشدہ اختیار نہیں۔

ایک مالک رکھیں اور ترتیب سے تصدیق کریں

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

چکربندھن چار جانچوں سے بند کریں: بھیجا گیا پتہ ٹنل لنک پر موجود، اندرونی نام مکمل طور پر اہل نام کے طور پر حل ہوتا ہے، وہی نام لاحقے کے بغیر حل ہوتا ہے، اور ایک بار دوبارہ منسلک ہونے کے بعد دونوں اب بھی درست ہیں۔ ایک کیپچر بتاتا ہے کہ چاروں میں کون ناکام ہوا۔ OpenVPN 2.6 دستی فہرست کرتا ہے dhcp-option اور اسکرپٹ ہدایات کو ان کے پلیٹ فارم نوٹس کے ساتھ۔