openfortivpn مسلسل DNS کیوں دوبارہ لکھ رہا ہے؟ اصل مالک تلاش کریں

کنکشن کے اوپر آنے کے لمحے سے اس کی پیروی کریں: کلائنٹ تصدیق کرتا ہے، pppd گفت و شنید کرتا ہے، اور پھر کوئی چیز آپریٹنگ سسٹم میں DNS ترتیبات لکھتی ہے۔ اگر آپ صرف یہ جانتے ہیں کہ VPN نے آپ کا حل کنندہ بدلا، تو آپ ابھی نہیں جانتے کہ ان مراحل میں سے کس نے یہ کیا۔ ان میں سے دو کر سکتے ہیں، اور دستاویزی pppd انضمام استعمال کرنے والے کلائنٹ پر وہ ایک ہی فریق کی طرح نظر آنے کے لیے کافی قریب چلتے ہیں۔ لکھنے والے کا نام لینا پہلا قدم ہے؛ اس کا متبادل چننا دوسرا ہے، اور یہ اپنے ناکامی کے طریقوں والا الگ فیصلہ ہے۔

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

کنکشن نے واقعی کیا بدلا، اسی سے شروع کریں

اپنے معمول کے حکم سے ایک بار جڑیں اور پہلے اور بعد کے حل کا موازنہ کریں۔ systemd-resolved چلانے والے Linux میزبان پر، resolvectl status ہر لنک کے لیے DNS سرورز اور تلاش کے ڈومین چھاپتا ہے، اور اپنے سرورز لے جانے والا نیا tun یا ppp لنک کلائنٹ کی طرف سے اپ ڈیٹ کا انگوٹھے کا نشان ہے۔ macOS پر، scutil --dns حل کنندہ کی ترتیب اسی ترتیب میں دکھاتا ہے جس میں ایپلیکیشنز اس سے مشورہ کرتی ہیں۔

اس کا موازنہ اس فائل سے کریں جس کے بدلنے کی آپ توقع رکھتے تھے۔ فی لنک منظر میں کنکشن سے منسلک اندراج اور دوبارہ لکھی گئی /etc/resolv.conf دو مختلف نتائج ہیں، اور دوسری کوئی اور چیز مکمل طور پر سنبھالنے والا علامتی لنک ہو سکتا ہے۔ حل کنندہ کا پتہ، تلاش کے ڈومین اور انٹرفیس کا نام اسی لمحے درج کریں؛ ان میں سے کسی میں بھی تبدیلی کسی دوسرے لکھنے والے کی طرف اشارہ کرتی ہے۔ اس بنیادی لکیر کے بغیر، ہر بعد کی درستی اس اندازے پر ہے کہ تین اجزاء میں سے کون سا ہلا۔

دو سوئچ اور وہ لکھنے والا جسے ہر ایک خاموش کرتا ہے

openfortivpn ایک اختیار ٹکڑے کی دستاویز کرتا ہے جو ان دونوں لکھنے والوں کو بند کرتا ہے جنہیں یہ کنٹرول کر سکتا ہے، اور ہر سوئچ کا ایک مکمل لکھا ہوا متبادل ہے جسے دستی وہی ترتیب مانتا ہے۔

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns کلائنٹ کو گیٹ وے سے سیکھے گئے DNS سرورز لاگو کرنے سے روکتا ہے، جبکہ --pppd-no-peerdns pppd کو ساتھی کا DNS نظام میں دھکیلنے سے روکتا ہے۔ upstream کی دستی انتباہ دیتی ہے کہ PPP کے ذریعے DNS کی تازہ کارییں کلائنٹ کی اپنی DNS تازہ کاریوں سے مقابلہ کر سکتی ہیں، اسی لیے دونوں سوئچ ٹکڑے میں ہونے چاہئیں، بجائے اس کے کہ کسی ایک کو کافی سمجھا جائے۔

کوئی سوئچ متبادل حل کنندہ کا نام نہیں لیتا، اور کوئی بھی نیٹ ورک منتظم، DHCP کلائنٹ یا الگ VPN انضمام کو بعد میں حل لکھنے سے نہیں روکتا۔ دو لکھنے والوں کو خاموش کرنا میدان کو ملکیت میں دینے کے بجائے کھلا چھوڑ دیتا ہے۔ اگر تیسرا جزو پہلے ہی DNS سنبھالتا ہے، ٹکڑا ایسی کوئی چیز نہیں بدلتا جسے آپ دیکھ سکیں؛ اگر کوئی اسے نہیں سنبھالتا، تو آپ نے ابھی نجی ناموں کے حل کا واحد ذریعہ ہٹا دیا ہے۔ یہ صرف اسی صورت میں درست انتظام ہے جب متبادل مالک پہلے منتخب ہو اور الگ سے جانچا گیا ہو۔

کچھ بھی غیر فعال کرنے سے پہلے مالک منتخب کریں

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

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

حل کی جانچ ہر لنک کے لیے کریں، ہر فائل کے لیے نہیں

محدود یا فی ڈومین حل والے میزبان پر ایپلیکیشنز واقعی کیا استعمال کرتی ہیں اس کی فہرست ایک /etc/resolv.conf نہیں ہے، اس لیے حل کنندہ کی حالت اسی طرح پڑھیں جیسے پلیٹ فارم اسے ظاہر کرتا ہے۔

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

دوبارہ جڑیں اور منقطع حالت کی تصدیق کریں

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

پھر دوبارہ جڑیں اور وہی تین اقدار پڑھیں: حل کنندہ کا پتہ، تلاش کے ڈومین، انٹرفیس۔

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