क्या आपको लगता है कि Pritunl सर्वर का नाम बदलने से उसका एंडपॉइंट बदल जाता है?

Pritunl सर्वर का नाम बदलने से कंसोल में एक लेबल बदलता है। यह उस पते को नहीं बदलता जिससे क्लाइंट प्रोफ़ाइल जुड़ते हैं, और यह कोई DNS रिकॉर्ड नहीं बनाता। मायने रखने वाला मान होस्ट का सार्वजनिक पता है, और वह नाम को पते की तरह ही सहजता से स्वीकार करता है।

जिस नाम से क्लाइंट जुड़ते हैं वह होस्ट के एक ही फ़ील्ड में रहता है

Pritunl होस्ट की सार्वजनिक पता सेटिंग के ज़रिए एंडपॉइंट उजागर करता है, जो सार्वजनिक IP पता या DNS नाम स्वीकार करती है। वहाँ vpn.example.net रखें, और बनी प्रोफ़ाइल तथा प्रमाणित सिंक वह नाम क्लाइंट को सौंप देंगे। रिकॉर्ड पहले से मौजूद होना चाहिए और उस लिसनर की ओर रिज़ॉल्व होना चाहिए जो VPN ट्रांसपोर्ट स्वीकार करता है; यह फ़ील्ड एक गंतव्य की घोषणा करता है, उसे प्रकाशित नहीं करता। सर्वर ऑब्जेक्ट का प्रदर्शित नाम प्रशासनिक मेटाडेटा है और कभी क्लाइंट के कनेक्शन प्रयास तक नहीं पहुँचता।

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

तीन फ़ील्ड जो एक जैसे दिखते हैं और हैं नहीं

स्थानीय पता Pritunl होस्ट के बीच प्रतिकृति और रूटिंग का काम करता है। लिंक पता बताता है कि जुड़े सर्वर एक-दूसरे तक कैसे पहुँचते हैं। इनमें से कोई भी वह पता नहीं है जिससे क्लाइंट जुड़ता है, और सार्वजनिक नाम इनमें कॉपी करने से वह टोपोलॉजी टूट जाती है जिसका ये वर्णन करते हैं। सार्वजनिक IPv6 पता अपने अलग रिकॉर्ड और पथ वाला अलग फ़ील्ड है; IPv4 के लिए A रिकॉर्ड IPv6 पहुँच स्थापित नहीं करता।

DNS नाम भी कोई पोर्ट मैपिंग या लिसनर नहीं ले जाता। अगर सेवा 1194 UDP पर सुनती है, तो नाम फिर भी ऐसे होस्ट पर रिज़ॉल्व होता है जिसे 1194 UDP स्वीकार करना होगा। पोर्ट 443 पर HTTP रिवर्स प्रॉक्सी जो वेब कंसोल परोसता है, VPN ट्रांसपोर्ट एंडपॉइंट नहीं है, भले ही दोनों एक ही नाम साझा करें।

टनल के भीतर डोमेन-आधारित रूटिंग एक और अलग परत है। बाहरी एंडपॉइंट का नाम देना इस बारे में कुछ नहीं कहता कि क्लाइंट किन निजी गंतव्यों तक पहुँच सकता है।

नया नाम मौजूद क्लाइंट तक पहुँचाएँ

फ़ील्ड बदलने से उन प्रोफ़ाइल को फिर से नहीं लिखा जाता जो पहले ही सर्वर छोड़ चुकी हैं। Pritunl का प्रमाणित कॉन्फ़िगरेशन सिंक होस्ट पता और पोर्ट के बदलाव संगत क्लाइंट तक पहुँचा सकता है, और दस्तावेज़ीकृत CLI क्लाइंट जुड़ने या फिर जुड़ने से पहले सिंक करता है। NetworkManager या स्वतंत्र OpenVPN क्लाइंट में आयातित प्रोफ़ाइल के पास ऐसा कोई चैनल नहीं है और उसे स्वीकृत प्रतिस्थापन चाहिए। मौजूदा सत्र कुछ साबित नहीं करते, क्योंकि वे पुराने मान के विरुद्ध स्थापित हुए थे।

जब वेब कंसोल लोड बैलेंसर के पीछे होता है, तो Pritunl सिंक पथ के लिए अलग सिंक पता सेटिंग का दस्तावेज़ीकरण करता है। सिर्फ़ इसलिए कि दोनों Pritunl हैं, VPN लिसनर के लिए कंसोल का होस्टनाम फिर से इस्तेमाल न करें।

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

बदलाव को असली कनेक्शन से स्वीकारें

रिज़ॉल्यूशन सबसे कमज़ोर संभव परीक्षण है। dig +short vpn.example.net जो पता लौटाता है, केवल यह साबित करता है कि एक रिकॉर्ड मौजूद है।

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

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