TAP कि TUN? Android OpenVPN क्लाइन्ट र ब्रिज गरिएका सर्भर
TAP ले इथरनेट फ्रेम बोक्छ, TUN ले IP प्याकेट बोक्छ, र Android एपले दोस्रो प्रकार मात्र पाउँछ। दुवैको तुलना गर्नुहोस्, त्यसपछि सर्भर पक्ष सुधार्नुहोस्।
ल्यापटपमा चल्ने प्रोफाइल फोनमा असफल हुन्छ। स्पष्ट कदम क्लाइन्ट कन्फिगमा एउटा शब्द बदल्नु हो। त्यो शब्दले सहयोग गर्दैन, किनकि दुवै छेउ एउटै प्रकारको ट्राफिकको कुरा गरिरहेका छैनन्।
TAP ले इथरनेट फ्रेम बोक्छ। TUN ले IP प्याकेट बोक्छ। Android VPN एपलाई IP इन्टरफेस दिइन्छ, जसले कन्फिग जे भने पनि दुईमध्ये एउटा व्यवस्थालाई सम्भव र अर्कोलाई असम्भव बनाउँछ।
तुलना छोटो छ, तर यसले तपाईं यसलाई फोनमै सुधार्न सक्नुहुन्छ कि सेवा नै बदल्नुपर्छ भन्ने निर्धारण गर्छ।
फरक पेलोड भएका दुई प्रकारका टनेल
TAP इन्टरफेस इथरनेट एडाप्टरजस्तै व्यवहार गर्छ। यसले फ्रेम बोक्छ, अर्थात् ARP, ब्रोडकास्ट र IP मुनि LAN ले बोक्ने सबै कुरा। यसैले ब्रिजिङ सम्भव बनाउँछ: टनेलले ब्रोडकास्ट डोमेन विस्तार गर्छ र क्लाइन्टहरू स्विचमा जोडिएझैं व्यवहार गर्छन्।
TUN इन्टरफेसले आफूलाई ठेगाना गरिएका IP प्याकेट बोक्छ। वार्ता गर्न कुनै लिङ्क तह छैन, ARP छैन र ब्रोडकास्ट छैन। टनेलमा के प्रवेश गर्ने भन्ने राउटिङले निर्धारण गर्छ, र सर्भर-साइड कन्फिगले ब्रिजको सट्टा सबनेट प्रयोग गर्छ।
दुवै छेउले यी दुईमध्ये कुन गरिरहेका छन् भन्नेमा सहमत हुनुपर्छ। एउटा पक्षमा dev tap लाई dev tun मा बदल्नाले सेवा रूपान्तरण हुँदैन; राउटेड टनेल अपेक्षा गर्ने क्लाइन्ट र अझै फ्रेम पठाउने सर्भर उत्पन्न हुन्छ, र उपयोगी केही पनि नगए पनि ह्यान्डशेक सफल हुन सक्छ।
Android एपलाई वास्तवमा के दिन्छ
प्लेटफर्मको VpnService API ले एपलाई IP प्याकेटका लागि भर्चुअल इन्टरफेस दिन्छ, जो ठेगाना, रुट र MTU ले कन्फिगर गरिएको हुन्छ। त्यो API मा कुनै इथरनेट एडाप्टर छैन, र एपले एउटा बनाउने उपाय पनि छैन।
त्यसैले OpenVPN Connect ले Android मा TAP ब्रिजिङको सट्टा राउटेड TUN जडानहरूको समर्थन अभिलेख गर्छ। Android FAQ यो सीमाबारे क्लाइन्ट-पक्षको कथन हो, र यो प्लेटफर्म API सँग मिल्छ।
रुट नेटवर्किङ उपकरण, अनुकूलित फर्मवेयर वा स्पष्ट अनुवाद तह लागू गर्ने उत्पादन फरक व्यवस्था हुन्। सामान्य अवस्था त्यही हो जसको वरिपरि योजना बनाउनुपर्छ: तपाईंको फाइल आयात गर्न सक्ने र सामान्य प्रयोगकर्ताका रूपमा चल्न सक्ने एप, IP इन्टरफेससँग र त्यसको मुनि केही पनि नभई।
तैपनि प्रयास गर्दा कस्तो देखिन्छ
जडान सामान्यतया स्थापित हुन्छ। यसैले असफलतालाई भ्रमित बनाउँछ: क्लाइन्टले जडान भएको जनाउँछ, सर्भर लगले सहभागी देखाउँछ, र कुनै एप्लिकेसन चल्दैन।
फोनलाई दिइएको ठेगानामा पठाइएको ट्राफिक पुग्दैन, किनकि सर्भरले फ्रेमलाई फोनसँग कहिल्यै नभएको MAC ठेगानामा ब्रिज गर्छ। ब्रोडकास्टमा निर्भर खोजी खाली रहन्छ। यदि LAN ब्रिजमार्फत DHCP मा निर्भर छ भने, फोनले त्यसरी लिज पाउँदैन, र ब्रिज गरिएको सबनेटमा हातले दिइएको ठेगानाले पनि छुटेको इन्टरफेस बनाउँदैन।
केही क्लाइन्ट अगावै असफल हुन्छन्, प्रोफाइल आयातमा, जब तिनीहरूले लागू गर्न नसक्ने यन्त्र प्रकार देख्छन्। दुवै व्यवहारले एउटै कुरा बुझाउँछ, र रुट थपेर, DNS बदलेर वा टनेलको ठेगाना दायरा फराकिलो बनाएर कुनै पनि सुधार हुँदैन।
सर्भर पक्षले के बदल्नुपर्छ
सुधार VPN सेवा चलाउने व्यक्तिको हो, र यो सामान्यतया स्थानान्तरण नभई थप हो। राउटेड यन्त्र, आफ्नै क्लाइन्ट सबनेट र ठेगाना दिई फोनलाई आवश्यक रुट पठाउने सर्भर-साइड कन्फिगसहित दोस्रो OpenVPN इन्स्टेन्स चलाउनुहोस्। हालको ब्रिज गरिएको इन्स्टेन्सले इथरनेट साँच्चै आवश्यक पर्ने यन्त्रहरूलाई सेवा दिइरहन्छ।
दुई विवरणले यसलाई व्यवहारमा चलाउँछन्। नयाँ क्लाइन्ट सबनेटका लागि LAN लाई VPN होस्टतर्फ देखाउने फिर्ता रुट चाहिन्छ, नत्र जवाफ कहिल्यै फर्किएर आउँदैन। र टनेल होस्टको फायरवालले टनेल इन्टरफेस र LAN बीच फर्वार्ड गर्नुपर्छ, र होस्टबाटै गरिएको परीक्षण सफल हुँदा सबैभन्दा धेरै छुट्ने चरण यही हो।
यदि अपरेटरले सेवा थप्न सक्दैन भने, विकल्प ब्रिजमा सामेल हुन सक्ने यन्त्र हो, अर्थात् फोनको तर्फबाट काम गर्ने ल्यापटप वा राउटर। यो आफ्नै व्यवस्थापन लागत भएको अस्थायी उपाय हो, Android कन्फिग होइन।
टनेलबाट होइन, एप्लिकेसनबाट निर्णय गर्नुहोस्
फोनले वास्तवमा केसम्म पुग्नुपर्छ सोध्नुहोस्, त्यसपछि त्यसको नक्सा बनाउनुहोस्। नाम वा ठेगानाबाट पुगिने फाइल सेयरिङ वा इन्ट्रानेट साइट IP आवश्यकता हो, र DNS ले नाम समाधान गरी रुट अवस्थित भएपछि राउटेड टनेलले त्यो पूरा गर्छ। स्थानीय ब्रोडकास्ट डोमेन ब्राउज गर्ने खोजी उपकरण IP आवश्यकता होइन, र जति पनि राउटिङ दिए पनि त्यो भरिँदैन।
| Requirement | Tunnel that satisfies it |
|---|---|
| File server or intranet by hostname | Routed TUN, with working DNS |
| Broadcast or ARP-based discovery | Ethernet bridging, so not an ordinary Android client |
| Multicast delivery | Bridging or an explicit multicast relay |
| One application to one address | Routed TUN, narrowest possible route |
त्यो तालिका पठाउनुपर्ने अनुरोध पनि हो। एप्लिकेसन, यसले प्रयोग गर्ने ठेगाना वा नाम, र यो खोजीमा निर्भर छ कि छैन भन्ने बताउनुहोस्। अपरेटरले त्यो विवरणमा आधारित काम गर्न सक्छ, जडान नहुने फोनमा कसैले गर्न सक्दैन।
अन्तमा, हरेक क्लाइन्टलाई LAN एडाप्टरको नक्कल गराउनुको सट्टा आवश्यक पर्ने यन्त्रहरूका लागि TAP सेवा राख्नुहोस्। स्पष्ट उद्देश्य भएका दुई सेवालाई समर्थन गर्न सबैका लागि आधा चल्ने एउटाभन्दा सजिलो हुन्छ।