घूमता लैपटॉप: स्थिर नाम या स्थिर ऑफ़िस पता?

आप घर से प्रबंधन कंसोल खोलते हैं, लैपटॉप को नाम से खोजते हैं और ऐसा पता पाते हैं जो ऑफ़िस छोड़ते ही वैध नहीं रहा। सहज प्रवृत्ति ऑफ़िस के पते को VPN एडाप्टर पर ले जाना है ताकि सब कुछ चलता रहे। वह सुधार आमतौर पर कुछ और तोड़ देता है, क्योंकि किसी डिवाइस को ढूँढना, उसके ट्रैफ़िक की अनुमति देना और सत्र को जीवित रखना तीन अलग समस्याएँ हैं। पता डिज़ाइन चुनने से पहले उन्हें अलग करें।

तीन आवश्यकताओं को अलग करें

लिखें कि तीनों में से वास्तव में कौन विफल हो रहा है। कोई व्यक्ति या उपकरण सेवा नहीं ढूँढ पाता; कोई सर्वर अनुरोध अस्वीकार करता है क्योंकि स्रोत पता सूची में नहीं है; या इंटरफ़ेस बदलने पर कोई एप्लिकेशन गिर जाता है। स्प्रेडशीट पर वे एक जैसे दिखते हैं और अलग सुधार चाहते हैं।

अधिकतर रोमिंग शिकायतें पहली टोकरी में आती हैं और DNS में ठीक होती हैं। स्थिर पहचान को नाम देना सस्ता है और पहला मामला कवर करता है। पता जताना महंगा है और दूसरे की मदद तभी करता है जब नीति वैसे भी फिर से लिखनी हो।

नाम को स्थिर चीज़ बनाएँ

लैपटॉप को ऐसा नाम दें जो कॉलर के पहुँच में मौजूद किसी भी पते पर हल हो। इस उदाहरण में ऑफ़िस का पता 192.168.50.42 है, रिमोट-एक्सेस पूल 10.90.0.42 देता है, और laptop17.corp.example कनेक्शन का अनुसरण करता है। कोई भी चीज़ अंतिम ऑक्टेट के मेल खाने की माँग नहीं करती, और उस मेल के इर्द-गिर्द डिज़ाइन करना बिना लाभ के काम पैदा करता है। रिकॉर्ड को उस पते की ओर इशारा करना चाहिए जो कॉलर वास्तव में इस्तेमाल कर सके, न कि हर उस इंटरफ़ेस की ओर जो लैपटॉप के पास कभी रहा हो।

dig +short laptop17.corp.example

रिज़ॉल्वर जवाब कैश करते हैं, इसलिए बदलाव सबके लिए तुरंत नहीं होता। छोटे TTL मदद करते हैं, और एप्लिकेशन का पुनः कनेक्ट तर्क अधिक मदद करता है।

जब स्रोत अनुमति-सूची ही असली बाधा हो

स्रोत अनुमति-सूची वह पता देखती है जो संरक्षित सेवा को मिलता है, किसी भी अनुवाद के बाद। यह अक्सर गेटवे या NAT पता होता है, लैपटॉप का अपना नहीं, इसलिए DNS रिकॉर्ड संपादित करना कभी अस्वीकृत अनुरोध सुधारता नहीं। जो पता वास्तव में आता है उसके लिए नीति अपडेट करें, या सूची को प्रमाणित पहचान से बदल दें।

सर्वर पर एक स्वीकृत अनुरोध पकड़ें और स्रोत फ़ील्ड पढ़ें, फिर दूरस्थ मार्ग से दोहराएँ। यदि दोनों पते अलग हैं, तो नीति को दो प्रविष्टियाँ या कोई और तंत्र चाहिए। दोनों पते नीति-प्रविष्टि के साथ लिखें ताकि अगला व्यक्ति देख सके कि दो क्यों हैं। उसी लिंक पर पहले से सक्रिय पते का दोबारा उपयोग अपने स्वयं के पहचान नियमों वाली अलग टकराव समस्या है।

निरंतरता वास्तव में क्या माँगती है

कनेक्शन की निरंतरता सबसे कठिन आवश्यकता है और सबसे अधिक गलत समझी जाती है। एक TCP कनेक्शन दोनों पतों और दोनों पोर्टों से पहचाना जाता है, इसलिए नया स्थानीय पता अलग कनेक्शन है, चाहे DNS कुछ भी कहे। महत्वपूर्ण एप्लिकेशनों को फिर से जुड़ना पड़ता है, जिसका अर्थ सत्र परत या फिर से प्रयास करने वाला क्लाइंट है, न कि कोई नेटवर्क युक्ति। स्थानांतरण के दौरान सत्र देखें और रुकावट तत्काल होती है, धीरे-धीरे नहीं।

ss -tnp state established '( dport = :443 )'

MAC पते की क्लोनिंग भी इसे नहीं सुलझाती। DHCP लीज़ पहचान स्पष्ट क्लाइंट पहचानकर्ता का उपयोग कर सकती है, और एक ही पहचान साझा करने वाले दो इंटरफ़ेसों को फिर भी समन्वित रूट चाहिए। गतिशीलता को एप्लिकेशन और आवंटन डिज़ाइन के रूप में लें, और डिवाइस की पहचान स्थिर रखें जबकि उसका पता नेटवर्क का अनुसरण करे।