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 मॅन्युअल चारही पर्याय त्यांच्या स्वतःच्या व्याप्तीसह सूचीबद्ध करते, आणि तीच प्रोफाइलजवळ ठेवायची तपासणी यादी आहे।

तुमचा प्रशासकीय प्रवेश वाहून नेणारी टनेल रीस्टार्ट करण्यापूर्वी सर्व्हरमध्ये जाण्यासाठी बँडबाहेरील मार्ग ठेवा। तीच एक खबरदारी या परिस्थितीतून निर्माण होणाऱ्या बहुतेक घटना टाळते।