के तपाईंलाई लाग्छ कि 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 ले ठेगाना फर्काउँदा रेकर्ड अवस्थित छ भन्ने मात्र प्रमाणित गर्छ।

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

पछि, सार्वजनिक ठेगाना सर्दा, रेकर्ड अद्यावधिक गर्नुहोस् र क्लाइन्ट क्यासिङ तथा पुनः जडान व्यवहारको योजना बनाउनुहोस्। होस्टनामले क्लाइन्टहरूलाई सङ्ख्यात्मक ठेगानाबाट अलग गर्छ; यसले जीवित सकेट सार्दैन वा नपुग्ने सुन्नेलाई जवाफ दिन बाध्य पार्दैन।