तुमचा VPN DNS एन्क्रिप्ट करतो की फक्त पुढचा हॉप?

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

कॉन्फिगरेशन फाइलला हात लावण्यापूर्वी प्रत्येक टप्प्यावर क्वेरी कोणाला मिळते ते लिहून ठेवा.

दोन रचना सेटिंग्ज पृष्ठावर सारख्याच दिसतात

पहिल्या रचनेत उपकरण स्वतः DNS over TLS चालवते, आणि बोगदा फक्त ते कनेक्शन तुम्ही निवडलेल्या रिझोल्व्हरपर्यंत पोहोचवतो. TLS सत्र रिझोल्व्हरवर संपते, म्हणजे रिझोल्व्हरला क्वेरी दिसते आणि VPN एक्झिटला वाचता येणार नाही असा एन्क्रिप्टेड मजकूर दिसतो. दुसऱ्या रचनेत उपकरण सामान्य DNS बोगद्यातून VPN होस्टवरील फॉरवर्डरकडे पाठवते, आणि तो फॉरवर्डर वरच्या रिझोल्व्हरकडे स्वतःचे एन्क्रिप्टेड कनेक्शन उघडतो. वैशिष्ट्यांच्या यादीत दोन्ही "VPN सह एन्क्रिप्टेड DNS" असे दिसतात, पण वाचता येणारी क्वेरी ते वेगवेगळ्या इमारतींत ठेवतात.

फरक तात्विक नसून मोजता येणारा आहे. क्लायंटवर किंवा सर्व्हरवर TLS सत्र शोधा, आणि तुमच्याकडे प्रत्यक्षात कोणती रचना आहे ते कळेल.

बदलण्यापूर्वी रिझोल्व्हर साखळीचा नकाशा बनवा

मार्गावरील रिझोल्व्हर मोजा आणि प्रत्येकाची भूमिका नावाने सांगा. फॉरवर्डिंग घटक विनंती दुसऱ्या रिझोल्व्हरकडे सुपूर्द करतो, तर रिकर्सिव्ह रिझोल्व्हर उत्तर शोधण्याचे काम करतो आणि अधिकृत सर्व्हरशी थेट बोलू शकतो. या भूमिका याच कारणासाठी स्वतंत्रपणे परिभाषित केल्या आहेत, आणि RFC 9076 रिझोल्व्हर व्याख्या एकच वरचा गंतव्यस्थान आहे असे गृहीत धरण्यापूर्वी वाचण्यासारख्या आहेत. स्वतःचा रिकर्सिव्ह रिझोल्व्हर चालवणाऱ्या होस्टकडे एन्क्रिप्ट करण्यासाठी एकच "वरचा प्रवाह" नसतो, ज्यामुळे संपूर्ण योजना अवैध ठरते.

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

अपयशाचे वर्तनही लक्षात घ्या. एन्क्रिप्टेड वरचा प्रवाह पोहोचण्यायोग्य राहिला नाही तर फॉरवर्डर बंद स्थितीत अपयशी होतो का, स्पष्ट मजकुराकडे परत जातो का, की दुसऱ्या रिझोल्व्हरकडे वळतो? तो निर्णय नोंदीत असला पाहिजे, कारण बोगदा सर्वात अस्वस्थ असताना तो गोपनीयतेची हमी बदलतो.

कोणता हॉप एन्क्रिप्टेड आहे ते तपासा

क्लायंटपासून सुरुवात करा आणि त्याच्याकडे पोर्ट 853 वर TLS सत्र आहे का ते निश्चित करा. पोर्ट 53 मधून बरोबर सुटणारी क्वेरी एन्क्रिप्शनबद्दल काहीही सिद्ध करत नाही.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

मग VPN होस्टवर जा आणि फॉरवर्डरने उघडलेले बाहेर जाणारे एन्क्रिप्टेड कनेक्शन शोधा. सॉकेट तक्ता सांगतो की वरचे TLS सत्र आहे का आणि ते कोणत्या प्रक्रियेकडे आहे:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

क्लायंट TLS सत्र दाखवत असेल आणि सर्व्हर काहीच दाखवत नसेल, तर तुम्ही पहिल्या रचनेत आहात आणि सर्व्हर IP स्तरावर पुढे पाठवत असलेल्या क्वेरी वाचू शकत नाही. सर्व्हर TLS सत्र दाखवत असेल आणि क्लायंट बोगद्यात पोर्ट 53 ची साधी वाहतूक दाखवत असेल, तर तुम्ही दुसऱ्या रचनेत आहात: पुढचा हॉप संरक्षित आहे, पण फॉरवर्डर उपकरण विचारत असलेले प्रत्येक नाव अजूनही वाचतो. तो दुसरा निकाल अपयश नाही, पण त्याला टोकापासून टोकापर्यंत एन्क्रिप्शन म्हणणे चूक आहे.

मालक आणि अपयशाचे वर्तन नोंदवा

मालकी तुम्हाला काय वचन देण्याची परवानगी आहे हे ठरवते. उपकरणाचा मालक क्लायंट बाजूचे एन्क्रिप्टेड कनेक्शन नियंत्रित करतो, तर VPN प्रशासक आपल्या फॉरवर्डरने तयार केलेले पुढचे कनेक्शन नियंत्रित करतो. जो दोन्हीपैकी काहीही चालवत नाही तो फक्त मार्गाचे वर्णन करू शकतो.

काहीही सुरू करण्यापूर्वी अंतर्गत नावे तपासा. संस्थेची नावे सार्वजनिक रिझोल्व्हरकडे पाठवणे समतुल्य रचना नाही, आणि फक्त नेटवर्कच्या आत असलेला split-horizon झोन वरच्या प्रवाहात अजिबात सुटणार नाही. बदलानंतर एक अंतर्गत आणि एक सार्वजनिक नाव तपासा आणि निकाल कॉन्फिगरेशन बदलासोबत ठेवा. एन्क्रिप्टेड मार्ग अंतर्गत होस्टचे रिझोल्यूशन तोडत असेल, तर उपाय विस्तृत बोगदा नसून मर्यादित व्याप्तीचा रिझोल्व्हर नियम आहे.

शेवटी प्रत्येक हॉपसाठी एक वाक्य लिहा: क्वेरी कोणत्या घटकाला मिळाली, तो हॉप एन्क्रिप्टेड होता का, आणि नाव कोण वाचू शकतो. VPN होस्टबद्दलचे वाक्य अजूनही क्वेरी वाचू शकतो असे सांगत असेल, तर दस्तऐवजीकरणानेही तसे सांगावे, कारण उलटा दावा करणाऱ्या आकृतीवर कमांड कधीही न चालवलेला माणूस विश्वास ठेवेल.