Android में हमेशा चालू VPN: एंडपॉइंट नाम पहले कैसे हल होता है

Android टनल बनने से पहले ट्रैफ़िक रोकता है, फिर भी क्लाइंट को अपना एंडपॉइंट हल करना पड़ता है। यह क्रम है, और यहीं यह अटकता है।

फ़ोन रीबूट होता है, हमेशा चालू सक्षम है, VPN के बिना कनेक्शन ब्लॉक करें चालू है, और टनल कभी नहीं उठता। कुछ भी गलत कॉन्फ़िगर नहीं है: ब्लॉक अपना काम कर रहा है, और क्लाइंट का अपना एंडपॉइंट तक पहुँचने का प्रयास भी उसके अधीन है। एंडपॉइंट को टनल मौजूद होने से पहले हल करना होता है, ऐसे क्लाइंट द्वारा जिसे नेटवर्क से बात करने की अनुमति है जबकि किसी अन्य ऐप को नहीं। कौन सा घटक ऐसा करता है और किस क्रम में, यह समझना रहस्य को कॉन्फ़िगरेशन प्रश्न में बदल देता है।

VPN बिल्डर वास्तव में क्या माँगता है

Android VPN ऐप प्लेटफ़ॉर्म को सर्वर पता नहीं देता। यह एक स्थानीय इंटरफ़ेस बनाता है: टनल के लिए पते और रूट, वे रिज़ॉल्वर जो ऐप्स को अंदर उपयोग करने चाहिए, और फिर establish() एक फ़ाइल डिस्क्रिप्टर लौटाता है जिसे ऐप कच्चे IP पैकेट के रूप में पढ़ता और लिखता है। दूर का एंडपॉइंट उस बिल्डर में कहीं नहीं आता।

यही मुख्य संरचनात्मक तथ्य है। प्लेटफ़ॉर्म tun इंटरफ़ेस बनाता है और उस पर नीति लागू करता है; ऐप ट्रांसपोर्ट को उपयोगकर्ता स्थान में लागू करता है, यानी ऐप स्वयं अपने एंडपॉइंट का नाम हल करता है और एन्क्रिप्टेड कनेक्शन खोलता है। इसलिए होस्टनाम एंडपॉइंट संभव है, इसलिए नहीं कि प्लेटफ़ॉर्म नामों का समर्थन करता है, बल्कि इसलिए कि प्लेटफ़ॉर्म एंडपॉइंट को कभी नहीं देखता।

बिल्डर का एक फ़ील्ड पते लेता है: DNS सर्वर। वे संख्यात्मक रिज़ॉल्वर पते होने चाहिए, आमतौर पर वे जिन्हें ऑपरेटर टनल से पूछना चाहता है। वह फ़ील्ड बताता है कि टनल उठने के बाद ऐप्स अपनी क्वेरी कहाँ भेजते हैं। यह नहीं बताता कि क्लाइंट एंडपॉइंट कैसे खोजता है, और दोनों को एक ही सेटिंग मानना ही भ्रम की शुरुआत है।

दो DNS प्रश्न, एक नहीं

पहला प्रश्न है: टनल उठने के बाद ऐप्स अपनी क्वेरी कहाँ भेजते हैं? उत्तर टनल के अंदर का रिज़ॉल्वर पता है, tun इंटरफ़ेस से पहुँचने योग्य, स्वभाव से संख्यात्मक।

दूसरा प्रश्न है: क्लाइंट उस टनल के बनने से पहले अपना एंडपॉइंट कैसे खोजता है? वह खोज टनल के बाहर, नीचे के नेटवर्क पर, क्लाइंट की प्रक्रिया में होती है। यह नाम का उपयोग कर सकती है, और ऐसा रिज़ॉल्वर उपयोग करना चाहिए जहाँ डिवाइस VPN के बिना पहुँच सके।

चरणकौन हल करता हैमार्गविफलता कैसी दिखती है
एंडपॉइंट खोजVPN ऐपनीचे का नेटवर्क, सुरक्षित सॉकेटकभी कनेक्ट नहीं होता; tun इंटरफ़ेस पर ट्रैफ़िक नहीं
पीयर प्रमाणीकरणक्लाइंट और सर्वरटनल ट्रांसपोर्टकनेक्ट होता है फिर गिर जाता है; प्रमाणपत्र या कुंजी त्रुटि
निजी नाम खोजटनल के ज़रिए ऐप्सtun के अंदर रिज़ॉल्वरटनल ऊपर, आंतरिक साइटें हल नहीं होतीं

तीन चरण, तीन अलग लक्षण। कनेक्ट नहीं हो सकता जैसा एक त्रुटि संदेश उन्हें एक कर देता है, और इसीलिए लोग DNS सर्वर फ़ील्ड संपादित करके ऐसी समस्या ठीक करते हैं जो उस फ़ील्ड के पढ़े जाने से पहले ही होती है।

बूटस्ट्रैप क्यों अटक सकता है

ब्लॉक सक्रिय होने के साथ हमेशा चालू का अर्थ है कि VPN के अंदर न होने वाला ट्रैफ़िक गिरा दिया जाता है, जिसमें VPN रखने वाले ऐप का ट्रैफ़िक भी शामिल है। बाहर निकलने का रास्ता स्पष्ट है: ऐप सॉकेट पर protect() कॉल करता है, जो उसे नीचे के नेटवर्क से बाँधता है ताकि वह टनल को बाईपास करके बाहर जा सके। हर VPN क्लाइंट को अपने ट्रांसपोर्ट के लिए यह करना होता है, वर्ना वह कभी सर्वर तक नहीं पहुँचेगा।

अब ऐसी तैनाती सोचें जहाँ एंडपॉइंट नाम जानने वाला एकमात्र रिज़ॉल्वर स्वयं टनल के अंदर है। क्लाइंट को नाम हल करने के लिए टनल चाहिए, और टनल बनाने के लिए नाम चाहिए। यह असली चक्रीय निर्भरता है, और कोई भी क्लाइंट कॉन्फ़िगरेशन इसे हल नहीं करता। यह डिज़ाइन त्रुटि है, बग नहीं।

समय वही निर्भरता हल्के रूपों में दिखाता है। पहले अनलॉक से पहले बूट के समय डिवाइस के पास अभी उपयोगी नेटवर्क न हो; कैप्टिव पोर्टल पर नेटवर्क है पर पोर्टल के अलावा सब ब्लॉक है; Wi-Fi से मोबाइल नेटवर्क पर जाने में सुरक्षित सॉकेट का नीचे का नेटवर्क बदलता है और क्लाइंट को यह देखकर फिर हल करना होता है। हर एक बूटस्ट्रैप घटना है, और रात 3 बजे पता लगाने के बजाय जानबूझकर परखे जाने योग्य है।

उत्तर को पिन करना समाधान क्यों नहीं

लुभावना रास्ता है नाम एक बार हल करके मिला पता संख्यात्मक फ़ील्ड में चिपका देना, या कस्टम बिल्ड में हार्डकोड कर देना। यह काम करता दिखता है, और नाम को एक तस्वीर बना देता है। जब ऑपरेटर एंडपॉइंट हटाता है, माइग्रेशन, anycast बदलाव या नए क्षेत्रीय पते से, क्लाइंट पुराने को ही डायल करता रहता है और इंटरफ़ेस में कुछ कारण नहीं बताता।

DNS रिकॉर्ड जीवनकाल इसलिए रखते हैं ताकि उत्तर बदल सकें; कैशिंग उसी अवधि से परिभाषित है, हमेशा के लिए नहीं। उत्तर पिन करना उस तंत्र को फेंक देता है जो नाम को पते से बेहतर बनाता है, जबकि नाम उपयोग करने की परिचालन लागत बनी रहती है।

पिन करने के साथ अक्सर दूसरी बुरी आदत आती है: पहचान जाँच ढीली करना क्योंकि कनेक्शन अब अलग तरह से विफल होता है। सर्वर पहचान सत्यापन बूटस्ट्रैप समस्या का हिस्सा नहीं है, और उसे कमज़ोर करना DNS असुविधा को इंटरसेप्शन जोखिम से बदल देता है।

रीबूट सहने वाले डिज़ाइन

टिकाऊ व्यवस्था बिना चमक की है। ऐसा क्लाइंट उपयोग करें जो सुरक्षित सॉकेट सही ढंग से लागू करे और नीचे के नेटवर्क पर अपना एंडपॉइंट हल करे, और उसे ऐसा एंडपॉइंट नाम दें जो सार्वजनिक रूप से या टनल से पहले पहुँचने योग्य रिज़ॉल्वर से हल हो। ब्लॉक चालू रखें; DNS काम कराने के लिए उसे पूरी तरह बंद करना वह गुण हटा देता है जिसके लिए तैनाती है।

जहाँ एंडपॉइंट निजी रहना चाहिए, प्लेटफ़ॉर्म के उपयोग योग्य स्पष्ट बूटस्ट्रैप मार्ग दें, जैसे टनल के बिना पहुँचने योग्य रिज़ॉल्वर या ऑपरेटर द्वारा रखरखाव किया गया प्रबंधन कनेक्शन, और उस अपवाद को संकीर्ण रखें तथा उपयोगकर्ता टॉगल के बजाय नीति के स्वामित्व में रखें। Android VpnService दस्तावेज़ यह संदर्भ है कि प्लेटफ़ॉर्म सुरक्षा और जीवनचक्र पर क्या गारंटी देता है, और VpnService.Builder संदर्भ पुष्टि करता है कि DNS फ़ील्ड संख्यात्मक पते लेता है।

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

  • एंडपॉइंट का हल ऐप में, टनल के बाहर, सुरक्षित सॉकेट पर होता है।
  • बिल्डर का DNS फ़ील्ड टनल के अंदर के ऐप्स के लिए है, क्लाइंट के अपने एंडपॉइंट के लिए नहीं।
  • केवल टनल से पहुँचने योग्य रिज़ॉल्वर गतिरोध है, धीमी शुरुआत नहीं।
  • रीबूट के बाद एंडपॉइंट, प्रमाणीकरण और निजी खोज अलग-अलग परखें।

संबंधित लेख