VPN सर्ल्यो: तपाईंको OpenVPN क्लाइन्टले अझै पुरानो IP मा किन डायल गर्छ

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

DNS ले के भन्छ होइन, प्रोफाइलले के डायल गर्छ हेर्नुहोस्

तपाईंले वास्तवमै प्रयोग गर्ने जडान खोल्नुहोस् र remote लाइन पढ्नुहोस्। त्यहाँको अंकीय ठेगानाले रेकर्ड जतिसुकै सही भए पनि होस्टनाम अपडेट कहिल्यै पछ्याउँदैन।

त्यसपछि तपाईंले सम्पादन गरेको प्रोफाइल क्लाइन्टले लोड गरेको हो कि जाँच्नुहोस्। आयात गरिएका प्रोफाइल सामान्य हुन्छन्: प्रबन्धकले महिनौं अघि प्रतिलिपि लिएर आफ्नै संस्करण राखेको हुन सक्छ, त्यसैले तपाईंको डाउनलोड फोल्डरको फाइल र एपको प्रविष्टि फरक हुन सक्छ। DNS डिबग गर्नुअघि नै क्लाइन्टकै जडान विवरणमा रहेको इन्डपोइन्ट तुलना गर्नुहोस्।

दुई फाइल, एउटा इन्डपोइन्ट — यहाँ सामान्य भेटिने यही हो।

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

क्लाइन्टको अर्को जडान प्रयास पढ्नुहोस्

विस्तृत लगिङसहित जडान पुनः सुरु गर्नुहोस् र सम्पर्क गर्ने ठेगाना उल्लेख भएको लाइन पढ्नुहोस्। त्यही मान महत्त्वपूर्ण हो, तपाईंको ब्राउजरले रिजोल्भ गरेको होइन।

रिजोल्भरको क्यासमा अघिल्लो उत्तर अझै रहन सक्छ, र केही नेटवर्कले रेकर्डको TTL माग गरेभन्दा बढी समय राख्छन्। अन्यत्रबाट परीक्षण गरिएको सार्वजनिक रिजोल्भरलाई होइन, क्लाइन्टले वास्तवमै प्रयोग गर्ने रिजोल्भरलाई सोध्नुहोस्।

लगले नयाँ ठेगाना देखाउँछ र जडान अझै असफल हुन्छ भने समस्या सरेको छ: प्याकेट कतै जाँदैछ र कोही जवाफ दिँदैन। यो श्रोता, फायरवाल वा पोर्ट फर्वार्डिङको प्रश्न हो, र यो क्लाइन्टको रिजोल्युसन मार्गमा होइन, सर्भरको पक्षमा छ। यी दुई असफलतालाई छुट्टै राख्नुहोस्, किनभने पुग्न नसकिने श्रोतालाई DNS समस्या मान्नाले तपाईंलाई उही लुपमा दुई पटक घुमाउँछ।

तपाईं कुन रिस्टार्ट गर्दै हुनुहुन्छ जान्नुहोस्

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

निरन्तरताका सेटिङ पनि महत्त्वपूर्ण छन्, किनभने ती नयाँ ठेगानाको पछि दौडन होइन, प्रमाणित भएको कुरा जोगाउन बनाइएका हुन्।

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

चार विकल्प र तिनका छुट्टाछुट्टै काम

होस्टनामसहितको remote त्यही सेटिङ हो जसले पुनः रिजोल्भ गर्न सम्भव बनाउँछ; त्यो लाइनमा शाब्दिक ठेगाना हुँदा यो असम्भव हुन्छ। resolv-retry लुकअप असफल हुँदा के हुन्छ नियन्त्रण गर्छ, र 2.6 ले यसलाई पहिल्यै पूर्वनिर्धारित रूपमा अनन्त राख्छ। त्यसैले यो थप्दा केही बदलिँदैन, र यसले फरक उत्तरका लागि कहिल्यै आवधिक जाँच तय गर्दैन। यो नयाँ ठेगाना सर्वेक्षण गर्छ भन्नेले पुनःप्राप्ति र ताजगी मिसाएको छ।

persist-remote-ip ताजगी होइन, निरन्तरताको कुरा हो: यसले अन्तिम पटक प्रमाणित भएको इन्डपोइन्टलाई, यसले समर्थन गर्ने नरम रिस्टार्टहरूभरि पुनः प्रयोग गर्छ। तपाईं स्थानान्तरण परीक्षण गर्दै हुनुहुन्छ भने यो तपाईंले चाहेको कुराको उल्टो हो। तपाईंको बिल्डले यसलाई सक्षम गर्छ भने परीक्षणका लागि बन्द गर्नुहोस्, र नयाँ इन्डपोइन्ट प्रमाणित भएपछि पुनः सक्षम गर्नुहोस्। खुला राख्दा, सफल पुनःजडानले DNS बारे तपाईंलाई केही नबताउन सक्छ।

float ले सत्रको बीचमा ठेगाना बदलिएको प्रमाणित सहकर्मीलाई स्वीकार गर्छ, र यसलाई समर्थन गर्ने व्यवस्थामा मात्र। यसले DNS ताजा गर्दैन, र प्रदायक परिवर्तन आफैं पछ्याउँदैन। यसलाई घुम्ने सहकर्मीहरूका लागि लचिलोपन सुविधा ठान्नुहोस्, सर्भरका लागि गतिशील ठेगाना संयन्त्र होइन।

क्लाइन्टलाई दोष दिनुअघि नयाँ इन्डपोइन्ट पुष्टि गर्नुहोस्

तपाईंको नेटवर्क बाहिरबाट, नयाँ ठेगानामा कन्फिगर गरिएको पोर्टमा श्रोता छ कि र प्रदायकको फर्वार्डिङ त्यतै संकेत गर्छ कि जाँच्नुहोस्। खुला पोर्ट नभएको मेसिनका लागि सही A रेकर्डले मानिसहरूले क्यासिङमा लगाउने ठ्याक्कै त्यही लक्षण उत्पन्न गर्छ।

त्यसपछि फेरि जडान गर्नुहोस् र दुई कुरा पुष्टि गर्नुहोस्: क्लाइन्टले अपेक्षित सर्भर प्रमाणपत्रविरुद्ध प्रमाणित गर्यो, र सत्र तपाईंले लक्ष्य गरेको स्रोतमा पुग्छ। ठेगाना परिवर्तनले पहिचानका आवश्यकता घटाउँदैन, र गलत इन्डपोइन्टमा सफल हुने जडान असफल हुनेभन्दा नराम्रो हो। OpenVPN 2.6 म्यानुअल ले चारै विकल्प आ-आफ्नो दायरासहित सूचीबद्ध गर्छ, र त्यही प्रोफाइलको छेउमा राख्नुपर्ने जाँचसूची हो।

तपाईंको प्रशासनिक पहुँच बोक्ने टनेल रिस्टार्ट गर्नुअघि सर्भरमा पुग्न ब्यान्डबाहिरको बाटो राख्नुहोस्। त्यो एउटै सावधानीले यो परिदृश्यले निम्त्याउने अधिकांश घटना रोक्छ।