तुम्हाला वाटते का की 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 पत्ता परत देतो तेव्हा तो फक्त रेकॉर्ड अस्तित्वात असल्याचे सिद्ध करतो।

स्वीकृती चाचणी म्हणजे नवीन प्रोफाइल असलेल्या क्लायंटकडून ताजे प्रमाणित कनेक्शन, त्यानंतर टनेलद्वारे पोहोचता आले पाहिजे अशा खाजगी स्रोतासाठी विनंती। क्लायंट लॉगमध्ये त्याने प्रत्यक्षात वापरलेला एंडपॉइंट तपासा, तुम्ही हेतू ठेवलेला नाही। नाव योग्यरीत्या बदलण्यावर अवलंबून नसलेला व्यवस्थापन मार्ग ठेवा, जेणेकरून चुकीमुळे तुम्ही कन्सोलबाहेर कुलूपबंद होऊ नये।

नंतर, सार्वजनिक पत्ता हलल्यावर, रेकॉर्ड अद्ययावत करा आणि क्लायंट कॅशिंग व पुन्हा जोडण्याच्या वर्तनाची योजना करा। होस्टनाव क्लायंटना संख्यात्मक पत्त्यापासून वेगळे करते; ते जिवंत सॉकेट हलवत नाही किंवा अगम्य लिसनरला उत्तर देण्यास भाग पाडत नाही।