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 मैनुअल चारों विकल्पों को उनके अपने दायरे के साथ सूचीबद्ध करता है, और यही प्रोफ़ाइल के पास रखने योग्य जाँच-सूची है।

अपने प्रशासनिक पहुँच को ले जाने वाली टनल रीस्टार्ट करने से पहले सर्वर तक आउट-ऑफ़-बैंड रास्ता रखें। वही एक सावधानी इस परिदृश्य से पैदा होने वाली अधिकांश घटनाओं को रोकती है।