hosts فائل بحال کرنے والے VPN کام بعد کی تبدیلیاں مٹا دیتے ہیں

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

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

بعد میں بحال کی گئی بیک اپ ابھی کی بیک اپ نہیں ہے

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

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

ہر واقعہ ایک اطلاع ہے، لین دین نہیں

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

بار بار ہونے والے کنکشن واقعات دوسرا نصف ہیں: بغیر جانچ کے شامل کرنا دوسرا یکساں اندراج بناتا ہے، اور پھر کچھ حل کرنے والے ایک نام کے لیے دو جواب دیکھتے ہیں۔

ہر نقشہ بندی کو ایک مالک دیں

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

جب دو زندہ سرنگوں کو ایک ہی نقشہ بندی درکار ہو، تو دوسرے مالک کو ابھی بھی اس کی ضرورت ہونے کے دوران ایک منقطع ہونا اسے نہیں ہٹا سکتا۔ اس کے لیے بولین نہیں، حوالہ جات کی گنتی یا واضح ملکیت کا ریکارڈ درکار ہے۔

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

جب مشروط DNS ہی اصل ضرورت ہو

اگر اصل ضرورت ایسی نجی نام کی جگہ ہے جو صرف اس وقت حل ہوتی ہے جب سرنگ چل رہی ہو، تو hosts غلط طریقہ ہے۔ Windows NRPT نام کی جگہ کے لیے حل کرنے والا منتخب کر سکتا ہے، اور وہ خود پتے کا ریکارڈ نہیں بناتا؛ حل کرنے والے کو پھر بھی جواب دینا ہوتا ہے۔ یہ مختلف مالک والا مختلف ڈیزائن ہے، اور یہ ہر منتقلی پر فائل کی تدوین مکمل طور پر ہٹا دیتا ہے۔

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

بار بار کنکشن، بیک وقت دو پروفائل اور غیر متعلقہ تبدیلی کے بعد منقطع ہونا جانچیں۔ نتیجہ یہ ہونا چاہیے کہ VPN کی نقشہ بندی باقی مشین کو پیچھے دھکیلے بغیر اپنے مالک کی پیروی کرے۔