hosts फ़ाइल को बहाल करने वाले VPN कार्य बाद के संपादन मिटा देते हैं
कनेक्ट होते समय hosts फ़ाइल का स्नैपशॉट लें और डिस्कनेक्ट होते समय उसे बहाल करें, और बीच में किया गया हर संपादन खो जाता है। स्नैपशॉट के बजाय हर मैपिंग को एक स्वामी दें।
कनेक्शन कार्य Windows hosts फ़ाइल की प्रतिलिपि बनाता है, एक निजी पता जोड़ता है, और डिस्कनेक्शन कार्य सहेजी गई आवृत्ति को वापस प्रतिलिपि कर देता है। यह हफ़्तों तक काम करता है और फिर एक दोपहर मशीन ऐसी आंतरिक साइट तक नहीं पहुँच पाती जिसका VPN से कोई संबंध नहीं है। बहाली ने ठीक वही किया जो उसे बताया गया था: उसने किसी और के संपादन से पहले की फ़ाइल वापस रख दी। गड़बड़ी मॉडल में है, प्रतिलिपि आदेश में नहीं।
कोई भी कार्यप्रवाह जो साझा फ़ाइल का स्नैपशॉट लेता है और बाद में उसे बहाल करता है, बीच में हुए हर परिवर्तन को हानि के रूप में विरासत में पाता है।
बाद में बहाल किया गया बैकअप अभी का बैकअप नहीं है
एक सामान्य क्रम से गुज़रें। कार्य फ़ाइल सहेजता है और टनल के लिए एक प्रविष्टि जोड़ता है। बाद में एक प्रशासक असंबंधित सुधार जोड़ता है, और दूसरी प्रोफ़ाइल अपनी प्रविष्टि जोड़ती है। डिस्कनेक्ट पर बहाली मूल स्नैपशॉट वापस रख देती है, जिससे दूसरी प्रोफ़ाइल की प्रविष्टि और प्रशासक का सुधार दोनों हट जाते हैं। दोनों में से कोई VPN का नहीं था, और दोनों अब चले गए।
एक ही स्थिर बैकअप फ़ाइलनाम स्थिति को और बिगाड़ता है। बाद की कनेक्शन घटना पहले से संशोधित फ़ाइल को तथाकथित मूल पर प्रतिलिपि कर सकती है, इसलिए बहाली का आधार अंतिम घटना के समय फ़ाइल जैसी दिखती थी उस ओर सरक जाता है।
हर घटना एक सूचना है, लेन-देन नहीं
घटना-चालित कार्य एक सूचना है। पुनःकनेक्शन, अधूरा शटडाउन या दूसरी प्रोफ़ाइल आवश्यक स्थिति को फिर से आकार दे सकते हैं, जबकि पिछला कार्य अभी लिख रहा होता है। कोई भी दोनों को क्रमबद्ध नहीं करता, और कोई भी आधा अधूरा परिवर्तन वापस नहीं लेता। इसके अलावा अकेला घटना पहचानकर्ता प्रदाता और उसके डेटा के बिना यह नहीं बताता कि वह किस प्रोफ़ाइल का है। कार्य को लेन-देन मानना वही धारणा है जो विफल होती है।
दोहराई गई कनेक्शन घटनाएँ दूसरा आधा हिस्सा हैं: जाँच के बिना जोड़ना दूसरी समान प्रविष्टि बनाता है, और फिर कुछ रिज़ॉल्वर एक नाम के लिए दो उत्तर देखते हैं।
हर मैपिंग को एक स्वामी दें
hosts फ़ाइल की हर पंक्ति एक होस्टनाम को पते से मैप करती है और यह नहीं बताती कि कौन-सी टनल चालू है। अगर स्वचालन अपरिहार्य है, तो VPN द्वारा प्रबंधित मैपिंग के लिए एक स्वामी नियुक्त करें। उस स्वामी को केवल अपनी प्रविष्टियाँ अद्यतन करनी चाहिए, असंबंधित वर्तमान सामग्री सुरक्षित रखनी चाहिए, दोहराई गई घटना पर अनुलिपियों से बचना चाहिए, और याद रखी गई सूची के बजाय उन कनेक्शनों से मेल बैठाना चाहिए जो वास्तव में सक्रिय हैं।
जब दो जीवित टनल को एक ही मैपिंग चाहिए, तो एक डिस्कनेक्शन उसे तब नहीं हटा सकता जब दूसरे स्वामी को उसकी अभी भी ज़रूरत हो। इसके लिए बूलियन नहीं, संदर्भ गणना या स्पष्ट स्वामित्व रिकॉर्ड चाहिए।
समीक्षित बहाली के लिए बैकअप का अभी भी मूल्य है। उसे सामान्य डिस्कनेक्शन क्रिया नहीं होना चाहिए, और फ़ाइल में क्या था इसका एकमात्र रिकॉर्ड भी नहीं होना चाहिए।
जब सशर्त DNS ही असली ज़रूरत हो
अगर असली आवश्यकता एक निजी नामस्थान है जो केवल तभी हल होता है जब टनल चालू हो, तो hosts गलत तंत्र है। Windows NRPT किसी नामस्थान के लिए एक रिज़ॉल्वर चुन सकता है, और वह स्वयं पता रिकॉर्ड नहीं बनाता; रिज़ॉल्वर को फिर भी उत्तर देना होता है। यह अलग स्वामी वाला अलग डिज़ाइन है, और यह हर संक्रमण पर फ़ाइल संपादन पूरी तरह हटा देता है।
अगर hosts एक स्थिर सेवा के लिए जानबूझकर रखा गया है, तो सुनिश्चित करें कि उसका पता इच्छित मार्ग से पहुँचने योग्य रहे और उसका होस्टनाम स्थिर रहे ताकि एप्लिकेशन पहचान जाँच काम करती रहें। DNS कैश साफ़ करना उस पुरानी प्रविष्टि को ठीक नहीं कर सकता जिसे अगली खोज फिर पढ़ेगी।
दोहराए गए कनेक्शन, दो साथ-साथ चलती प्रोफ़ाइल और असंबंधित संपादन के बाद का डिस्कनेक्शन जाँचें। परिणाम यह होना चाहिए कि VPN की मैपिंग बाकी मशीन को पीछे धकेले बिना अपने स्वामी का अनुसरण करे।