OpenVPN DNS पाठवते, पण तुमचा रिझॉल्व्हर ते कधीच पाहणार नाही असे होऊ शकते

क्लायंट लॉग पाठवलेला DNS सर्व्हर दाखवतो, टनेल जोडलेली आहे, आणि अंतर्गत नाव तरीही कशातही सुटत नाही. पाठवण्यात स्वतःत काहीच तुटलेले नाही. पर्याय पोहोचला आणि ऑपरेटिंग सिस्टमच्या रिझॉल्व्हरने तो कधीच वापरला नाही, कारण बहुतेक Unix क्लायंटवर OpenVPN मूल्य सोपवून ॲप्लिकेशन प्लॅटफॉर्मवर सोडते.

लक्षण: लॉग DNS दाखवतो आणि नावे अजूनही अयशस्वी होतात

OpenVPN dhcp-option DNS आणि डोमेन माहिती वाहून नेते, आणि क्लायंटला काय मिळाले ते नोंदवते. काही अंमलबजावणींमध्ये क्लायंट ती सेटिंग्ज आतून लागू करतो; इतरांमध्ये तो त्या इंटिग्रेशन स्क्रिप्ट किंवा नेटवर्किंग सेवेसाठी निर्यात करतो. लॉग ओळ कथेचा फक्त पहिला अर्धा भाग वर्णन करते. दुसरा अर्धा भाग क्लायंट नियंत्रित न करणाऱ्या ठिकाणी घडतो. अयशस्वीता सहसा तिथेच असते.

म्हणूनच जोडलेली टनेल आणि अयशस्वी अंतर्गत नाव इतक्या वेळा एकत्र असतात. मूल्य आहे, वापरणारा नाही किंवा चुकीच्या पद्धतीने कॉन्फिगर केलेला आहे, आणि रिझॉल्व्हर शांतपणे कनेक्शनपूर्वी वापरलेला सार्वजनिक सर्व्हर वापरत राहतो.

मिळणे म्हणजे लागू करणे नाही

सिस्टम रिझॉल्व्हर अजूनही दुसऱ्या सेवेच्या मालकीचा असताना क्लायंट पाठवलेले DNS मूल्य नोंदवू शकतो. ब्राउझरची स्वतःची एन्क्रिप्टेड-DNS धोरणे असू शकतात जी सिस्टम रिझॉल्व्हरला पूर्णपणे टाळतात, ज्यामुळे एक ॲप्लिकेशन अंतर्गत नावे सोडवते आणि दुसरे सोडवत नाही अशी लक्षात राहणारी परिस्थिती निर्माण होते.

प्रत्येक Unix क्लायंट तीच फाइल पुन्हा लिहितो असे गृहीत धरण्याऐवजी अंमलबजावणीचे समर्थित इंटिग्रेशन तपासा. हेच गृहीतक लोकांना अशी रिझॉल्व्हर कॉन्फिगरेशन संपादित करायला लावते जी काहीही वाचत नाही.

प्रत्येक प्लॅटफॉर्मवर रिझॉल्व्हरचा मालक शोधा

Windows वर नाव रिझोल्यूशन धोरण सारणी विशिष्ट प्रत्यय विशिष्ट सर्व्हरकडे पाठवू शकते, आणि VPN क्लायंट तिथे नियम स्थापित करू शकतो. फक्त ॲडॉप्टरची DNS यादी नाही, धोरण तपासा. Linux वर NetworkManager किंवा systemd-resolved कॉन्फिगरेशनचे मालक असू शकतात, आणि त्यापैकी कोण मालक आहे यावर पुन्हा जोडल्यावर काय टिकेल हे ठरते.

प्रत्यक्षात प्रश्नांना उत्तर देणाऱ्या साधनाने प्रभावी स्थिती वाचा: systemd-resolved होस्टवर resolvectl query internal.example.net, किंवा प्लॅटफॉर्मचे समतुल्य. नंतर त्या उत्तराची क्लायंट लॉग पाठवले असा दावा करणाऱ्या DNS सर्व्हरशी तुलना करा.

समन्वयाशिवाय रिझॉल्व्हर सेटिंग्जवर लिहिणाऱ्या अनेक सेवा चालवणे टाळा. दोन मालक अधूनमधून दिसणारा निकाल देतात, आणि प्रत्येक पुन्हा जोडणी तो यादृच्छिकपणे दुरुस्त किंवा तोडत असल्याचे दिसते.

स्क्रिप्ट आणि foreign_option

OpenVPN पाठवलेले पर्याय foreign_option_N नावाच्या चलांद्वारे स्क्रिप्टमध्ये निर्यात करते, आणि स्क्रिप्ट त्यांचे रिझॉल्व्हर आदेशांमध्ये भाषांतर करू शकते. ही व्यवस्था समर्थित इंटिग्रेशन आहे, स्वयंचलित वर्तन नाही, आणि ती क्लायंटवर स्थापित करून आवाहन करावी लागते.

तुम्ही स्क्रिप्टवर अवलंबून असाल तर तिची अंमलबजावणी आणि निर्गमन स्थिती नोंदवा. चालते पण शांतपणे अयशस्वी होणारी स्क्रिप्ट स्क्रिप्ट नसल्यासारखेच लक्षण ठेवते, आणि कॉन्फिगरेशन पूर्ण दिसत असल्याने ते लक्षात घेणे कठीण. स्क्रिप्ट फाइल नाही, स्क्रिप्टचे आउटपुट तपासा. फाइल असणे म्हणजे स्क्रिप्ट चालली नाही.

लॉग नाही, नाव तपासा

जोडल्यानंतर क्लायंटकडून केवळ-अंतर्गत होस्टनाव विचारा, नंतर सार्वजनिक नाव विचारा, नंतर कोणत्या सर्व्हरने उत्तर दिले ते तपासा. कार्यरत सेटअपमध्ये दोन्ही उत्तरे वेगवेगळ्या ठिकाणांहून येतात, आणि दोन्ही डिझाइनशी जुळली पाहिजेत.

नाव सुटले पण सेवा अयशस्वी झाली तर पुन्हा DNS बदलण्याऐवजी राउटिंग आणि ॲप्लिकेशन प्रवेश कडे जा. OpenVPN मॅन्युअल dhcp-option आणि स्क्रिप्ट वातावरणाचे दस्तऐवजीकरण करते; दुसरी रिझॉल्व्हर फाइल संपादित करण्यापूर्वी तुमच्या क्लायंटने काय लागू करावे याची खात्री करण्यासाठी ते वापरा.