Onion सेवा विरुद्ध VPN सेवा: वेगळे प्रवेश मॉडेल

लोक Onion सेवा आणि फक्त VPN द्वारे पोहोचणारी सेवा या एकाच कल्पनेच्या दोन रूपे म्हणून वर्णन करतात: पोर्ट लपवा, गुप्त पत्ता सामायिक करा। त्या पत्ता कशाशी बांधलेला आहे, कोण पोहोचू शकतो आणि विनंती येण्यापूर्वी काय घडले पाहिजे यात भिन्न आहेत। एक Tor मधील भेटीचे ठिकाण आहे, दुसरे खाजगी नेटवर्कमधील मार्ग आहे। त्यांना परस्पर बदलण्यायोग्य मानल्यास अशा रचना तयार होतात ज्या खाजगीही नाहीत आणि टिकाऊही नाहीत।

दंतकथा: दोन्ही रचना फक्त लपलेले दार

सामाईक गुण खरा आहे पण पातळ आहे: दोन्हीपैकी कोणतीही रचना प्रशासकीय इंटरफेस थेट पोहोचता येण्याजोग्या सार्वजनिक पोर्टवर ठेवत नाही। बाकी सर्व वेगळे होते। Onion पत्ता सेवेच्या स्वतःच्या किल्लीपासून तयार होतो, म्हणून नाव ओळखीशी बांधलेले असते; VPN पत्ता तुम्हाला प्रवेश दिलेल्या नेटवर्कमधील फक्त पत्ता असतो। एक सेवा ओव्हरले स्थरात लपवतो, दुसरा तुम्हाला खाजगी टोपोलॉजीत प्रवेश देतो। दुसर्याला पहिल्याचा समानार्थी मानणे हीच गोंधळाची सुरुवात।

दोन्हीपैकी कोणताही गुण ॲपसाठी स्वतः सुरक्षा नियंत्रण नाही। लपलेले स्थान त्याच्या मागील सॉफ्टवेअरला दुरुस्त करत नाही, आणि खाजगी मार्ग लॉगिन पानावर प्रमाणीकरण जोडत नाही। दोन्ही रचनांना अजूनही ॲपच्या स्वतःच्या परवानग्या लागतात, आणि दोन्हींना अजूनही अद्ययावत आणि पुनर्प्राप्तीसाठी जबाबदार कोणीतरी लागते।

Onion पत्ता प्रत्यक्षात काय दर्शवतो

Onion पत्ता आवृत्ती v3 सेवेची सार्वजनिक किल्ली एन्कोड करतो, म्हणून कोणीही स्वतः नियंत्रित न करणाऱ्या सेवेसाठी पत्ता निवडू शकत नाही। क्लायंट Tor द्वारे भेटीच्या ठिकाणाशी जोडतो, आणि सेवा तिच्या बाजूने त्याच ठिकाणी पोहोचते; कोणताही सामान्य एक्सिट नोड ते कनेक्शन सेवेपर्यंत नेत नाही। नाव ओळख आहे, DNS रेकॉर्ड नाही।

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

म्हणून onion नावासाठी मार्ग किंवा hosts नोंद जोडण्याचा काही उपयोग होत नाही। शोध ही यंत्रणा नाही; Tor क्लायंट आणि त्याची सर्किट्स ही यंत्रणा आहेत। सेवा थोड्या लोकांच्या गटासाठी असेल तर onion क्लायंट अधिकृतता कनेक्शन स्वीकारण्यापूर्वी किल्ली मागू शकते, पण ते अजूनही ॲप लॉगिन नाही। पत्ता प्रकाशित करणेही जाणीवपूर्वक केलेली कृती आहे, कारण तो जाणणारा कोणीही तुम्ही मर्यादित केले नसेल तर जोडणीचा प्रयत्न करू शकतो।

onion रचनेचे एकमेव कारण प्रमाणीकरण सेट करणे टाळणे असेल तर थांबा। ओव्हरले स्थर ते देत नाही, आणि तुम्ही ते नंतर तसेही बनवाल।

VPN मार्ग प्रत्यक्षात काय देतो

VPN उपकरणाला नेटवर्कमध्ये प्रवेश देतो आणि त्याला गेटवे किंवा सबनेटपर्यंत मार्ग देतो। त्या गेटवेच्या मागील सेवा टनेल पूलमधून पत्ता पाहते आणि तिच्याकडे असलेली अधिकृतता लागू करते। मार्ग वापरकर्ता कोण आहे याबद्दल काहीही सांगत नाही; पॅकेट कुठे जाऊ शकतात हे सांगतो।

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

ती मॉडेल व्यवस्थापित उपकरणे असलेल्या ज्ञात गटासाठी योग्य आहे, कारण गेटवे उपकरणाची स्थिती लादू शकते आणि नेटवर्कचे ऑडिट होऊ शकते। अनामिक किंवा तात्पुरत्या भेट देणाऱ्यांसाठी ते योग्य नाही, त्यांना आधी नोंदणी करावी लागेल। जोडलेला वापरकर्ता काय वाचू शकतो हे ॲपचे स्वतःचे लॉगिन अजूनही ठरवते। पोहोचक्षमता अधिकृततेशी गोंधळवणे हाच VPN शेवटी जोडू शकणाऱ्या प्रत्येकाला संपूर्ण सबनेट देण्याचा मार्ग।

प्रेक्षक अज्ञात असतील किंवा सतत बदलत असतील तर थांबा। एक पान दाखवण्यासाठी अनोळखी लोकांना खाजगी नेटवर्कमध्ये नोंदवणे ही सेवा प्रकाशित करण्याच्या तुलनेत मोठी बांधिलकी आहे।

दोघांमधील निवड, आणि जे तसेच राहते

प्रेक्षक तांत्रिक असतील, सेवेला सार्वजनिक पत्ता अजिबात नसावा असे असेल आणि तुम्ही Tor क्लायंटच्या अटी स्वीकारू शकत असाल तर onion मॉडेल निवडा। प्रेक्षक तुम्ही व्यवस्थापित करता अशा उपकरणांचा निश्चित गट असेल आणि त्यांचा प्रवेश नेटवर्क स्थरावर नोंदवायचा असेल तर VPN मॉडेल निवडा। कोणतीही निवड ॲप प्रमाणीकरण, पॅचिंग किंवा पुनर्प्राप्ती मार्गाची गरज काढून टाकत नाही। कोणतीही तुमच्या वापरकर्त्यांसाठी महत्त्वाच्या अर्थाने आपोआप अधिक खाजगी नाही।

दोन्ही रचनांमध्ये सेवेपर्यंत कोण पोहोचू शकतो, त्यांना कसे ओळखले जाते आणि ओळखपत्र गमावल्यास काय होते ते लिहा। onion सेवेच्या उत्तरात तिच्या क्लायंट अधिकृतता किल्ल्या आणि पत्ता स्वतःच समाविष्ट आहे; VPN च्या उत्तरात खाते, उपकरण आणि गेटवे धोरण समाविष्ट आहे। ह्या वेगळ्या याद्या आहेत, आणि त्यातील फक्त एकच पुढील प्रशासकाला स्पष्ट असेल।

तुलना ॲप सुरू होतो तिथे संपते। लपलेला पत्ता आणि खाजगी मार्ग हे वाहतुकीचे पर्याय आहेत, आणि विनंतीला काय करण्याची परवानगी आहे हे ॲपने अजूनही ठरवले पाहिजे। ते निर्णय वेगळ्या दस्तऐवजांत ठेवा, मग दोन्हीपैकी कोणतीही रचना दुसर्याचे काम गुपचुप घेणार नाही।