Android always-on VPN: इन्डपोइन्ट नाम कसरी पहिले समाधान हुन्छ
Android ले टनेल अस्तित्वमा आउनुअघि नै ट्राफिक अवरोध गर्छ, तैपनि क्लाइन्टले आफ्नो इन्डपोइन्ट समाधान गर्नुपर्छ। यो क्रम र अड्किने ठाउँ यहाँ छ।
फोन रिबुट हुन्छ, always-on सक्रिय छ, «VPN बिना जडान अवरोध गर्नु» खुला छ, तर टनेल कहिल्यै आउँदैन। केही पनि गलत कन्फिगर गरिएको छैन: अवरोधले आफ्नो काम गरिरहेको छ, र क्लाइन्टको आफ्नै इन्डपोइन्टसम्म पुग्ने प्रयास पनि त्यसैको अधीनमा छ। इन्डपोइन्टको नाम टनेल अस्तित्वमा आउनुअघि नै समाधान गर्नुपर्छ, त्यस्तो क्लाइन्टले जसलाई नेटवर्कसँग बोल्न अनुमति छ, जबकि अरू सबै एपलाई छैन। कुन घटकले यो गर्छ र कुन क्रममा, भन्ने बुझ्नुले यो रहस्यलाई कन्फिगरेसनको प्रश्न बनाउँछ।
VPN बिल्डरले वास्तवमा के माग्छ
Android VPN एपले प्लेटफर्मलाई सर्भरको ठेगाना दिँदैन। यसले स्थानीय इन्टरफेस बनाउँछ: टनेलका लागि ठेगाना र मार्गहरू, भित्र एपहरूले प्रयोग गर्नुपर्ने रिजोल्भरहरू, र त्यसपछि establish() ले फाइल डिस्क्रिप्टर फर्काउँछ, जसलाई एपले कच्चा IP प्याकेटका रूपमा पढ्छ र लेख्छ। टाढाको इन्डपोइन्ट त्यो बिल्डरमा कतै देखिँदैन।
यो नै मुख्य संरचनात्मक तथ्य हो। प्लेटफर्मले tun इन्टरफेस बनाउँछ र त्यसमा नीति लागू गर्छ; एपले प्रयोगकर्ता स्थानमा यातायात कार्यान्वयन गर्छ, अर्थात् एप आफैले आफ्नो इन्डपोइन्टको नाम समाधान गर्छ र इन्क्रिप्टेड जडान खोल्छ। त्यसैले होस्टनामका रूपमा इन्डपोइन्ट सम्भव छ — प्लेटफर्मले नाम समर्थन गर्छ भनेर होइन, प्लेटफर्मले इन्डपोइन्ट कहिल्यै देख्दैन भनेर।
बिल्डरको एउटा फिल्डले भने ठेगाना लिन्छ: DNS सर्भरहरू। ती अंकीय रिजोल्भर ठेगाना हुनुपर्छ, सामान्यतया ऑपरेटरले टनेलमार्फत सोध्न चाहने। त्यो फिल्डले टनेल आएपछि एपहरूले क्वेरी कहाँ पठाउँछन् भन्ने वर्णन गर्छ। क्लाइन्टले इन्डपोइन्ट कसरी भेट्टाउँछ भन्नेबारे यसले केही भन्दैन, र यी दुईलाई एउटै सेटिङ मान्नेबाटै अन्योल सुरु हुन्छ।
एक होइन, दुई DNS प्रश्न
पहिलो प्रश्न: टनेल आएपछि एपहरूले क्वेरी कहाँ पठाउँछन्? उत्तर टनेलभित्रको रिजोल्भर ठेगाना हो, tun इन्टरफेसमार्फत पुग्न सकिने, र बनावटैले अंकीय।
दोस्रो प्रश्न: त्यो टनेल अस्तित्वमा आउनुअघि क्लाइन्टले आफ्नै इन्डपोइन्ट कसरी भेट्टाउँछ? त्यो खोजी टनेलबाहिर, आधारभूत नेटवर्कमा, क्लाइन्टको प्रक्रियामा हुन्छ। यसले नाम प्रयोग गर्न सक्छ, र VPN बिना यन्त्रले पुग्न सक्ने रिजोल्भर प्रयोग गर्नैपर्छ।
| Stage | Who resolves | Path | Failure looks like |
|---|---|---|---|
| Endpoint lookup | The VPN app | Underlying network, protected socket | Never connects; no tunnel interface traffic |
| Peer authentication | Client and server | Tunnel transport | Connects then drops; certificate or key error |
| Private name lookup | Apps via the tunnel | Resolver inside the tun | Tunnel up, internal sites do not resolve |
तीन चरण, तीन फरक लक्षण। «जडान हुन सक्दैन» भन्ने एउटै त्रुटि सन्देशले तिनलाई एकै ठाउँमा मिलाउँछ, र त्यसैले मानिसहरू त्यो फिल्ड पढिनुअघि नै हुने समस्या सुधार्न DNS सर्भर फिल्ड सम्पादन गर्न थाल्छन्।
bootstrap किन अड्किन सक्छ
always-on मा अवरोध खुला हुँदा VPN भित्र नभएको ट्राफिक खारेज हुन्छ, VPN भएको एपको ट्राफिक पनि। निस्कने बाटो स्पष्ट छ: एपले सकेटमा protect() बोलाउँछ, जसले यसलाई आधारभूत नेटवर्कमा बाँध्छ, त्यसैले यो टनेल छल्दै बाहिर जान अनुमति पाउँछ। हरेक VPN क्लाइन्टले आफ्नो यातायातका लागि यो गर्नैपर्छ, नत्र सर्भरसम्म कहिल्यै पुग्दैन।
अब त्यस्तो परिनियोजन विचार गरौँ जहाँ इन्डपोइन्टको नाम जान्ने एउटै रिजोल्भर आफै टनेलभित्र छ। नाम समाधान गर्न क्लाइन्टलाई टनेल चाहिन्छ, र टनेल बनाउन नाम चाहिन्छ। यो साँचो चक्रीय निर्भरता हो, र कुनै क्लाइन्ट कन्फिगरेसनले यसलाई समाधान गर्दैन। यो डिजाइन त्रुटि हो, बग होइन।
समयले त्यही निर्भरता हलुका रूपमा देखाउँछ। बुटको समयमा, पहिलो अनलकअघि, यन्त्रसँग अझै उपयोगी नेटवर्क नहुन सक्छ; captive portal मा नेटवर्क छ तर पोर्टलबाहेक सबै अवरोध गर्छ; Wi-Fi बाट मोबाइलमा जाँदा सुरक्षित सकेटको आधारभूत नेटवर्क फेरिन्छ र क्लाइन्टले त्यो थाहा पाएर फेरि समाधान गर्नुपर्छ। यी हरेक bootstrap घटना हुन्, र हरेकलाई राति 3 बजे पत्ता लगाउनुभन्दा जानाजान परीक्षण गर्न लायक छ।
उत्तर स्थिर गर्नु किन समाधान होइन
लोभ्याउने बाटो भनेको नाम एकचोटि समाधान गरेर आएको ठेगाना अंकीय फिल्डमा टाँस्नु, वा अनुकूलित बिल्डमा हार्डकोड गर्नु हो। यो चलेको जस्तो देखिन्छ, र नामलाई तस्बिरमा बदल्छ। ऑपरेटरले इन्डपोइन्ट सार्दा — स्थानान्तरण, anycast परिवर्तन, नयाँ क्षेत्रीय ठेगाना — क्लाइन्टले पुरानैलाई फोन गरिरहन्छ र UI मा कतै कारण खुल्दैन।
DNS रेकर्डमा आयु हुनुको कारण नै उत्तरहरू फेरिन सक्नु हो; क्यासिङ त्यही आयुका आधारमा परिभाषित हुन्छ, सधैंका लागि होइन। उत्तर स्थिर गर्नु भनेको नामलाई ठेगानाभन्दा राम्रो बनाउने संयन्त्र त्याग्नु हो, र नाम प्रयोग गरेको सञ्चालन लागत भने कायम राख्नु।
स्थिर गर्ने क्रममा प्रायः दोस्रो नराम्रो बानी पनि आउँछ: जडान अहिले फरक तरिकाले असफल हुने भएकाले पहिचान जाँच कमजोर बनाउनु। सर्भरको पहिचान प्रमाणीकरण bootstrap समस्याको भाग होइन, र यसलाई कमजोर बनाउनुले DNS को असुविधालाई अवरोधको जोखिमसँग साट्छ।
रिबुट सहने डिजाइनहरू
टिकाउ व्यवस्था आकर्षक छैन। सुरक्षित सकेट ठीकसँग कार्यान्वयन गर्ने र इन्डपोइन्ट आधारभूत नेटवर्कमा समाधान गर्ने क्लाइन्ट प्रयोग गर्नु, र त्यसलाई सार्वजनिक रूपमा वा टनेलअघि पुग्न सकिने रिजोल्भरमार्फत समाधान हुने इन्डपोइन्ट नाम दिनु। अवरोध खुला राख्नु; DNS चल्नका लागि यसलाई पूरै बन्द गर्नुले परिनियोजन जुन गुणका लागि छ त्यो हटाउँछ।
इन्डपोइन्ट निजी रहनुपर्ने ठाउँमा प्लेटफर्मले प्रयोग गर्न सक्ने स्पष्ट bootstrap बाटो दिनु — टनेलबिना पुग्न सकिने रिजोल्भर, वा ऑपरेटरले राख्ने व्यवस्थापन जडान — र त्यो अपवाद साँघुरो राख्नु, प्रयोगकर्ता टगलको होइन, नीतिको स्वामित्वमा राख्नु। Android VpnService को कागजात सुरक्षा र जीवनचक्रबारे प्लेटफर्मले के ग्यारेन्टी दिन्छ भन्ने सन्दर्भ हो, र VpnService.Builder सन्दर्भ ले DNS फिल्डले अंकीय ठेगाना लिन्छ भनी पुष्टि गर्छ।
त्यसपछि रिबुटपछिको नयाँ जडानमा तीन चरण क्रमैले जाँच्नु: इन्डपोइन्टको नाम समाधान हुन्छ, टनेल स्थापित हुन्छ र सहकर्मी प्रमाणित हुन्छ, र निजी नाम टनेलको रिजोल्भरमार्फत समाधान हुन्छ। पहिलो चरण असफल भयो भने पछिको केही चल्न सक्दैन, र सुधार bootstrap बाटोमा पर्छ — कहिल्यै रिजोल्भर फिल्डमा होइन।
- इन्डपोइन्ट समाधान एपभित्र, टनेलबाहिर, सुरक्षित सकेटमा हुन्छ।
- बिल्डरको DNS फिल्ड टनेलभित्रका एपका लागि हो, क्लाइन्टको आफ्नै इन्डपोइन्टका लागि होइन।
- टनेलमार्फत मात्र पुग्न सकिने रिजोल्भर अड्किनु हो, ढिलो सुरुवात होइन।
- रिबुटपछि इन्डपोइन्ट, प्रमाणीकरण र निजी खोजी छुट्टाछुट्टै परीक्षण गर्नु।