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 सेवा ठेवा। स्पष्ट उद्दिष्टे असलेल्या दोन सेवांना आधार देणे सर्वांसाठी अर्धवट चालणाऱ्या एकापेक्षा सोपे आहे।