नया राउटर, वही VPN सर्वर: उसका सार्वजनिक प्रवेश स्थानांतरित करें

आप नया राउटर लगाते हैं, इंटरनेट लौट आता है, और फ़ोन का VPN क्लाइंट अभी भी उस पते की ओर देख रहा है जो अब जवाब नहीं देता। VPN सर्वर पर कुछ नहीं बदला, क्योंकि सर्वर कभी हिला ही नहीं। राउटर ही सार्वजनिक प्रवेश बिंदु था, और उसे बदलने से पता, फ़ॉरवर्डिंग नियम और शायद गतिशील DNS अपडेटर एक साथ बदल गए।

बदली को एक नहीं, दो सुपुर्दगी मानें, और काम करते समय प्रशासन इंटरफ़ेस तक जाने का स्थानीय रास्ता बनाए रखें।

प्लग निकालने से पहले सुपुर्दगी लिख लें

LAN प्रीफ़िक्स, सर्वर का पता और वह कैसे दिया जाता है, VPN जो लिसनर और ट्रांसपोर्ट वास्तव में इस्तेमाल करता है, उसे प्रकाशित करने वाला इनबाउंड नियम और क्लाइंट द्वारा सहेजा गया नाम दर्ज करें। फिर लिखें कि आज कौन-सी मशीन गतिशील DNS रिकॉर्ड अपडेट करती है: यह राउटर, स्वयं सर्वर या किसी दूसरे होस्ट पर अलग एजेंट हो सकता है। यह तब करें जब पुराने प्रशासन पृष्ठ अभी लोड हो रहे हों। इनबाउंड नियम का स्क्रीनशॉट याद किए गए पोर्ट नंबर से बेहतर है।

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

उस रिकॉर्ड को सुरक्षित जगह रखें। राउटर बैकअप में WAN लिंक की साख हो सकती है। निर्यात फ़ाइल को सेटिंग्स की नोट नहीं, पासवर्ड की तरह मानें।

पहले पता ले जाएँ, फिर फ़ॉरवर्ड

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

फिर VPN जो ट्रांसपोर्ट इस्तेमाल करता है उसके लिए ठीक एक इनबाउंड नियम बनाएँ। स्थानीय सर्वर तक फ़ॉरवर्डिंग बताने वाले निर्माता के मार्गदर्शन तंत्र दिखाते हैं, सार्वभौमिक विधि नहीं, इसलिए नियम को ब्लॉग की सूची नहीं, अपने वास्तविक प्रोटोकॉल और पोर्ट से मिलाएँ। नए राउटर पर फ़ॉरवर्ड उसके ऊपर बैठा ऑपरेटर-स्तरीय NAT नहीं हटा सकता, और यदि प्रदाता पहले से एक साझा करता है तो कोई स्थानीय नियम निजी पते को इंटरनेट से पहुँच योग्य नहीं बनाएगा।

पुष्टि करें कि सर्वर का अपना फ़ायरवॉल अब भी वह ट्रैफ़िक अनुमत करता है। जाँचें कि राउटर और इंटरनेट के बीच दूसरा गेटवे बैठा है या नहीं, क्योंकि कई प्रदाता मॉडेम और राउटर मिलाकर देते हैं। नए उपकरण पर WAN पता पढ़ें और क्लाइंट जो पता हल करते हैं उससे तुलना करें। यदि वे अलग हैं, तो आपका फ़ॉरवर्ड ऐसी चीज़ पर उतर रहा है जो किनारा नहीं है।

तय करें कौन सार्वजनिक नाम अपडेट करेगा

एंडपॉइंट अपडेट के लिए एक ही मालिक चाहिए, और केवल एक। यदि पुराना राउटर नाम प्रकाशित करता था, तो प्रतिस्थापन पर समर्थित अपडेटर सेट करें और पुष्टि करें कि रिकॉर्ड वास्तव में बदला। यदि सर्वर पहले से प्रकाशित कर रहा था, तो दो पतों के बीच डोलने वाला प्रतिद्वंद्वी अपडेटर जोड़ने के बजाय उस व्यवस्था को वैसे ही रहने दें।

जब परिनियोजन दोनों पता-परिवार प्रकाशित करता है, तो A और AAAA दोनों रिकॉर्ड पढ़ें। हर एक को ऐसी सेवा की ओर इशारा करना है जो सचमुच सुन रही हो और अपने फ़ायरवॉल मार्ग से अनुमत हो, और चलता हुआ IPv4 मैपिंग IPv6 पक्ष के बारे में कुछ नहीं कहता। क्लाइंट प्रोफ़ाइल में पहचान जाँच भी रखें: बदला हुआ सार्वजनिक पता बेमेल प्रमाणपत्र या पीयर कुंजी स्वीकार करने का कारण नहीं है।

बाहर से बदली साबित करें

LAN के भीतर से नहीं, अधिकृत बाहरी कनेक्शन और नए सत्र से परखें। सार्वजनिक पते के विरुद्ध भीतरी परीक्षण हेयरपिन व्यवहार पर निर्भर है और असली क्लाइंट से अलग रास्ता तय करता है।

वही क्रम अपनाएँ जो क्लाइंट अपनाता है: नाम हल करें, टनल पर बातचीत करें, पहचान सत्यापित करें, फिर किसी निजी संसाधन पर एक क्रिया करें। यही अंतिम चरण लोग छोड़ देते हैं, और लौटने का रास्ता केवल वही साबित करता है। यदि लॉगिन सफल हो पर निजी क्रिया विफल, तो नया LAN प्रीफ़िक्स, क्लाइंट द्वारा चुने गए मार्ग और संसाधन का उत्तर-पथ अपनी सुपुर्दगी टिप्पणियों से मिलाएँ।

चारों चरण पार होने के बाद ही पुराना राउटर हटाना सुरक्षित है। उसे अलग करें, फिर बाहरी परीक्षण एक बार और दोहराएँ। पुराने पते पर अब भी हल होने वाला पुराना रिकॉर्ड पहले ही चरण में विफल होता है, और पुराना उपकरण अभी शेल्फ़ पर रहते हुए उसका निदान करना आसान है।

नया मैपिंग अपनी पुनर्प्राप्ति टिप्पणियों के साथ रखें

अंतिम सर्वर आवंटन, इनबाउंड नियम और अपडेट मालिक का नाम स्थानीय रूप से राउटर तक पहुँचने की प्रक्रिया के साथ संग्रहित करें। अगली बदली traceroute से नहीं, उसी पृष्ठ से शुरू होनी चाहिए।

ऊपर के सब के बाद भी यदि टनल बाहर से विफल रहे, तो जाँचें कि राउटर जो सार्वजनिक पता बताता है वह क्लाइंट के हल किए पते से मेल खाता है या नहीं। वही एक तुलना DNS समस्या को फ़ॉरवर्डिंग समस्या से अलग करती है, और दूसरी पोर्ट-फ़ॉरवर्डिंग मार्गदर्शिका पढ़ने से कम समय लेती है।