Android VPN निर्यात: नयाँ फोनमा वास्तवमा के जान्छ
Android VPN निर्यातले सेटिङ र कहिलेकाहीँ कुञ्जी पठाउँछ, तर यन्त्रको अधिकार कहिल्यै पठाउँदैन। पुरानो फोन मेट्नु अघि वास्तवमा के जान्छ जाँच्नुहोस्।
Android बाट VPN प्रोफाइल निर्यात गर्नु ब्याकअप चरणजस्तो लाग्छ, र त्यो प्रस्ताव गर्ने मेनुले त्यो धारणा सुधार्न केही गर्दैन। तपाईंसँग रहने कुरा parser इनपुट, अपरेटिङ सिस्टमले सायद कहिल्यै फर्काउन नसक्ने कुञ्जी, र त्यही फोनका लागि जारी गरिएको अधिकार हो। यी तीन छुट्याउनुहोस् र उपयोगी प्रश्न आउँछ: नयाँ यन्त्रमा अझै कुन भाग छुटेको छ?
फाइल सजिलो भाग हो। बाँकी दुईले स्थानान्तरण काम गर्छ कि गर्दैन भन्ने निर्धारण गर्छन्।
निर्यात गरिएको प्रोफाइलमा वास्तवमा के हुन्छ
विश्वास गर्नु अघि फाइल टेक्स्ट एडिटरमा खोल्नुहोस्। OpenVPN प्रोफाइल एउटा सानो कन्फिगरेसन भाषा हो: remote, proto, data-ciphers, र प्रायः क्लाइन्टले आफ्नो TLS स्ट्याकलाई दिने इनलाइन <ca>, <cert>, <key> वा <tls-crypt> ब्लकहरू। WireGuard कन्फिग बढी समतल हुन्छ: [Interface] मा PrivateKey र Address हुन्छन्, त्यसपछि प्रत्येक इन्डपोइन्टका लागि एउटा [Peer] जसले PublicKey, AllowedIPs र Endpoint बोक्छ। IKEv2 कुञ्जी ब्लकको सट्टा पेलोड शब्दकोशसहित .mobileconfig का रूपमा आउँछ।
ती मध्ये कुनै पनि आफैंमा प्रमाण होइन। प्रमाण निजी कुञ्जी हो, र प्रत्येक ढाँचाले त्यसलाई भित्र टाँस्छ वा यसलाई बनाउने क्लाइन्टभित्र मात्र समाधान हुने उपनामतर्फ संकेत गर्छ।
Android मा कुञ्जी वास्तवमा कहाँ बस्छ
Android ले एप डेटा /data/data/<package> मुनि राख्छ, जुन त्यो एपको UID ले मात्र पढ्न सक्छ। root नगरिएको फोनबाट अर्को एपको निजी डाइरेक्टरी प्रतिलिपि गर्ने कुनै समर्थित तरिका छैन, र Android 12 ले यसलाई हटाएपछि र क्लाइन्टहरूले allowBackup="false" घोषणा गर्न थालेपछि adb backup सामान्य उत्तर रहेन। त्यसैले Android क्लाइन्टबाट निर्यात भन्नाले त्यो क्लाइन्टले लागू गर्ने कुरा हो, फाइल प्रणालीको प्रतिलिपि होइन।
परिचय तह एपको मुनि हुन्छ। यदि क्लाइन्टले तपाईंको कुञ्जी Android Keystore मा आयात गरेको छ भने, सामग्री त्यहीँ उत्पन्न वा बेरिन्छ, र पछिका निर्यातहरूले बाइटको सट्टा Keystore उपनामको सन्दर्भ बोक्न सक्छन्। हार्डवेयर-समर्थित कुञ्जीहरू मालिक एपले पनि पढ्न नसक्ने गरी बनाइएका हुन्छन्, जसरी Keystore documentation वर्णन गर्छ, त्यसैले त्यो उपनामतर्फ संकेत गर्ने प्रोफाइल त्यही फोनमा सफा आयात हुन्छ र अन्यत्र सबै ठाउँमा असफल हुन्छ।
त्यो बिग्रेको निर्यात होइन। त्यो प्लेटफर्मसँग मागिएको गुण हो।
प्रोफाइलले के बोक्न सक्दैन
वस्तुहरूलाई गन्तव्यले स्वीकार गर्ने कुरासँग तुलना गर्नुहोस्:
| वस्तु | जान्छ? | किन |
|---|---|---|
| प्रोटोकल र इन्डपोइन्ट | हो, यदि गन्तव्य क्लाइन्टले बुझ्छ भने | प्रोफाइलमा सादा पाठ |
| CA प्रमाणपत्र र होस्टनाम जाँच | सामान्यतया | सार्वजनिक सामग्री, तर होस्टनाम प्रमाणपत्रसँग मिल्नुपर्छ |
| क्लाइन्ट प्रमाणपत्र | हो, यदि यो प्रत्येक यन्त्रसँग बाँधिएको छैन भने | प्रमाणपत्रहरू बोक्न सकिन्छ; एउटा कति यन्त्रले प्रयोग गर्न सक्छ भनी जारीकर्ताले निर्धारण गर्छ |
| निजी कुञ्जी | Keystore बाहिर उत्पन्न भएको खण्डमा मात्र | हार्डवेयर-समर्थित कुञ्जीहरू निर्यात गर्न सकिँदैन, प्रतिस्थापन मात्र गर्न सकिन्छ |
| खाता, MFA, SSO सत्र | होइन | टोकनहरूको म्याद सकिन्छ र ती प्राप्त गर्ने यन्त्रसँग बाँधिएर रहन्छन् |
| मार्ग, DNS र एप दायरा | कन्फिगरेसन पाठका रूपमा मात्र | Android ले जडान गर्दा VpnService.Builder मार्फत लागू गर्छ |
| स्प्लिट-टनेल एप सूची | दुर्लभ | प्याकेज नाम यन्त्रअनुसार फरक हुन्छन्, र सूची क्लाइन्ट स्थिति हो |
दुई पङ्क्तिले धेरैजसो भ्रम पैदा गर्छन्। यन्त्रमा उत्पन्न भई निर्यात गर्न नसकिने भनी चिन्ह लगाइएको कुञ्जी साँच्चै एप डेटासँगै जान्छ, त्यसैले प्रतिस्थापन नयाँ कुञ्जी र त्यसका लागि जारी गरिएको प्रमाणपत्र हो। नयाँ फोनमा प्रतिलिपि गरिएको सत्र टोकन सामान्यतया पहिलो रिफ्रेसमै मर्छ, जुन असफल आयातजस्तो देखिन्छ।
आयात भनेको पार्स, त्यसपछि सहमतिको अनुरोध
प्राप्त गर्ने पक्षमा, आयात भनेको पार्स र त्यसपछि कमिट हो। क्लाइन्टले कन्फिग पढ्छ, सन्दर्भित प्रत्येक ब्लक अवस्थित छ कि भनी जाँच्छ, त्यसपछि टनेलको परिभाषा आफ्नै स्यान्डबक्समा लेख्छ, त्यसैले डाउनलोडबाट छानिएको फाइल पछि जडान हुने कुरा होइन।
त्यसपछि कुनै पनि फाइलले छोड्न नसक्ने अधिकार चरण आउँछ। टनेल स्थापना गर्नु अघि Android ले एपले VpnService.prepare() कल गरी तपाईंको सहमति लिनुपर्ने माग गर्छ, त्यसैले भर्खरै आयात गरिएको प्रोफाइलले पनि एक पटक प्रणाली संवाद देखाउँछ। त्यसपछि टनेल स्पष्ट रूपमा addAddress, addRoute, addDnsServer, र प्रति-एप राउटिङका लागि addAllowedApplication वा addDisallowedApplication मार्फत बनाइन्छ। यीमध्ये कुनै पनि इन्डपोइन्टबाट निहित हुँदैन, त्यसैले एउटै प्रोफाइलले दुई क्लाइन्टमा फरक प्रभावकारी मार्ग समूह उत्पन्न गर्न सक्छ।
प्रमाणपत्र-आधारित सेटअपले अर्को शाखा थप्छ। सर्भरले निश्चित यन्त्रलाई प्रमाणपत्र जारी गर्दा, MDM र SCEP दर्ताले गरेजस्तै, दोस्रो फोनमा यसको पुनःप्रयोग सर्भरले प्रत्येक पहिचानका लागि एउटा सत्र लागू नगरेसम्म काम गर्छ वा TLS ह्यान्डसेकमा असफल हुन्छ। पुनःप्रयोगको योजना बनाउनु अघि जारीकर्ताको नीति जाँच्नुहोस्।
पुरानोलाई अवकाश दिनु अघि नयाँ यन्त्र प्रमाणित गर्नुहोस्
नयाँ फोनले हरियो आइकनभन्दा राम्रो केही पास नगरेसम्म पुरानो फोन जोडिएको राख्नुहोस्। नयाँ यन्त्रबाट निर्गमन ठेगाना र यसले वास्तवमा प्रयोग गरेको DNS रिजोल्भर पुष्टि गर्नुहोस्। यदि split tunneling महत्त्वपूर्ण छ भने, टनेल बाइपास गर्नुपर्ने एप र नगर्नुपर्ने एप सुरु गर्नुहोस्, त्यसपछि कुनले तपाईंको ISP सम्म पुग्छ हेर्नुहोस्।
एउटा जाँचले निर्गमन ठेगाना टुङ्गो लगाउँछ। फोनको ब्राउजरमा https://ifconfig.me खोल्नुहोस्, त्यसपछि उही Wi-Fi मा रहेको ल्यापटपबाट curl -s https://ifconfig.me चलाउनुहोस् र दुवै उत्तरलाई तपाईंको प्रदायकले तोकेको ठेगानासँग तुलना गर्नुहोस्।
त्यसपछि मात्र पुरानो पहिचान अवकाश दिनुहोस्, र त्यो जारीकर्तामार्फत गर्नुहोस्: प्रमाणपत्र रद्द गर्नुहोस् वा खाताबाट यन्त्र हटाउनुहोस्। डाउनलोडबाट फाइल मेट्दा केही सकिँदैन, किनकि एउटै प्रमाणपत्र भएका दुई यन्त्र सर्भर लगमा उस्तै देखिन्छन्।
यदि निर्यात नबोकिने ठहरिन्छ भने, समाधान सार्वजनिक कन्फिगरेसन बन्डल होइन, नयाँ दर्ता हो। दोस्रो यन्त्रका लागि प्रोफाइल माग्नुहोस्, वा नयाँ फोनमा कुञ्जी जोडी उत्पन्न गरी CSR पेस गर्नुहोस्; ढिलो छ, र जारीकर्ताले समर्थन गर्ने बाटो त्यही हो।
केही मेट्नु अघि चेकलिस्ट चलाउनुहोस्: नयाँ यन्त्र जडान हुन्छ, निर्गमन ठेगाना र DNS मिल्छ, प्रति-एप दायरा तपाईंले चाहेजस्तै छ, पुरानो पहिचान रद्द भएको छ, र राखिएको कुनै पनि कन्फिग फाइल इन्क्रिप्टेड भण्डारणमा छ।