HTTP प्रॉक्सी, SSH टनल या VPN: सही परत चुनें

तीन इंजीनियरों से पूछें कि किसी आंतरिक सेवा तक कैसे पहुँचा जाए और आपको तीन डिज़ाइन मिलेंगे: एक वेब प्रॉक्सी, एक SSH टनल या पूरा VPN। तीनों दूर की सेवा को पहुँच में ला सकते हैं, और तीनों ट्रैफ़िक को कहीं और से आता दिखा सकते हैं। अंतर बाद में सामने आते हैं, जब इस्तेमाल किया गया प्रोटोकॉल वह नहीं होता जिसकी चुना गया उपकरण अपेक्षा करता है। तेज़ ब्राउज़र जाँच पास करने वाला डिज़ाइन अक्सर उस एप्लिकेशन पर विफल होता है जिसने अनुरोध की वजह बनी।

दो तथ्यों से तय करें: कौन से प्रोटोकॉल पार होने चाहिए, और जुड़े नाम कौन हल कर सकता है। बाकी सब प्राथमिकता है।

प्रॉक्सी केवल वही हिलाता है जो वह समझता है

वेब प्रॉक्सी उस प्रोटोकॉल का विश्लेषण करता है जिसके लिए उसे बनाया गया था। क्लाइंट उसे अनुरोध देता है और वह उसे आगे भेजता है, इसलिए बिना प्रॉक्सी सेटिंग वाला एप्लिकेशन बिल्कुल भाग नहीं लेता। HTTPS के लिए क्लाइंट को अपारदर्शी चैनल चाहिए, जो प्रॉक्सी CONNECT के ज़रिए देता है, अनुरोध पढ़कर नहीं।

SSH डायनामिक फ़ॉरवर्ड एक स्थानीय पोर्ट खोलता है जो SOCKS बोलता है, और वह पोर्ट TCP स्ट्रीम को क्लाइंट के बताए किसी भी गंतव्य तक भेजता है। TCP पर बने प्रोटोकॉल आम तौर पर उससे काम करते हैं। UDP नहीं, जब तक कोई उपकरण स्पष्ट रूप से समर्थन न जोड़े। स्थानीय फ़ॉरवर्ड और भी सँकरा है: एक स्थानीय पोर्ट एक निश्चित होस्ट और पोर्ट पर मैप, जो एक ज्ञात सेवा देता है और कुछ नहीं।

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN पैकेट हिलाता है। क्लाइंट जो कुछ टनल में भेजता है वह सब उससे होकर जाता है, UDP और ICMP सहित, इसलिए यह एक कनेक्शन की नहीं, नेटवर्क की ज़रूरत पर बैठता है।

किसी को नाम हल करना होगा

जब लक्ष्य नाम केवल दूर के नेटवर्क के DNS में मौजूद हो, तो खोज करने वाली मशीन को वह ज़ोन दिखना चाहिए। वेब प्रॉक्सी खुद खोज करता है, इसलिए आंतरिक नाम उससे होकर काम करता है, भले ही लैपटॉप नाम बिल्कुल हल न कर पाए। SOCKS भी वैसा ही व्यवहार कर सकता है, पर केवल तब जब क्लाइंट नाम आगे भेजे, ऐसे पते से जुड़ने के बजाय जिसे वह पहले ही हल कर चुका है। वह चुनाव क्लाइंट में है, सर्वर में नहीं।

curl अलगाव साफ़ दिखाता है: एक फ़्लैग होस्टनाम प्रॉक्सी को देता है, दूसरा उसे पहले स्थानीय रूप से हल करता है। स्थानीय हल के साथ केवल-आंतरिक नाम किसी भी टनल को छूने से पहले विफल होता है, और त्रुटि प्रॉक्सी को उस बात का दोषी ठहराती है जो असल में DNS का फ़ैसला था।

VPN तीसरा रास्ता लेता है: रूट के बगल में निजी रिज़ॉल्वर और खोज डोमेन स्थापित करके। यह सुविधाजनक है, और यह एक जाना-पहचाना भ्रम पैदा करता है: जो रूट ऐसे रिज़ॉल्वर के साथ मौजूद है जो जवाब नहीं देता, वह ठीक मरे हुए टनल जैसा दिखता है, जबकि पैकेट दूसरी तरफ़ पहुँच रहे होते हैं।

जब नेटवर्क केवल एक ही निकास की अनुमति दे

कई कॉर्पोरेट नेटवर्क बाहर जाने वाले कनेक्शन केवल प्रमाणित वेब प्रॉक्सी से अनुमति देते हैं। OpenVPN और SSH दोनों को वहाँ चलाया जा सकता है, पहले को अपना परिवहन प्रॉक्सी से टनल करके और दूसरे को ऐसी प्रॉक्सी कमांड से जो छोटा CONNECT सहायक चलाती है।

TCP पर बनी टनलें उस बाधा को झेल जाती हैं, और UDP आधारित VPN नहीं, जिससे बहुत सी ऐसी कॉन्फ़िगरेशन समझ आती हैं जो घर पर काम करती हैं और दफ़्तर में विफल होती हैं। दूसरी क़ीमत आसानी से छूट जाती है: प्रॉक्सी वाले TCP कनेक्शन के भीतर ले जाई जा रही TCP टनल में अब दो परतें फिर से भेजती हैं, और हानि के तहत वह जोड़ी ऐसे अटकती है जैसे कोई अकेली परत नहीं बनाती।

बिचौलियों को शृंखलाबद्ध करना परत चुनने से अलग सवाल है। दूसरा प्रॉक्सी या Tor जोड़ना बदल देता है कि कौन क्या देखता है, और शृंखला में स्थान तय करता है कि कौन-सी छलाँग सिफ़रटेक्स्ट देखती है।

क्रम छलाँगों की संख्या से ज़्यादा मायने रखता है। बाहरी छलाँग एन्क्रिप्टेड स्ट्रीम देखती है जबकि भीतरी छलाँग वह सादा पाठ देखती है जो वह ले जाती है, इसलिए शृंखला उतनी ही निजी है जितनी उसकी सबसे लापरवाह कड़ी। छलाँगों के बीच प्रोटोकॉल मिलाना इसे अपने आप बेहतर नहीं करता। यह मुख्यतः विफलता के तरीक़ों के बारे में सोचना कठिन बनाता है।

जाली पता विकल्पों में से एक नहीं है

किसी और के स्रोत पते के साथ पैकेट बनाने से कुछ उपयोगी नहीं मिलता: जवाब असली मालिक तक जाते हैं, और ज़्यादातर नेटवर्क ट्रैफ़िक को सीधे गिरा देते हैं। बिचौलिया इसलिए ज़रूरी है क्योंकि स्रोत गढ़ा नहीं जा सकता, और यही तीनों डिज़ाइनों का ईमानदार औचित्य है।

यह यह भी सीमित करता है कि उनमें से कोई क्या दावा कर सकता है। किसी ख़ास पते से आता दिखना इस बात का सवाल है कि वह पता कानूनी रूप से कहाँ दिया गया है और कौन उसे रूट कर सकता है, न कि इस बात का कि कौन-सा उपकरण हेडर जाली बना सकता है। अगर कोई डिज़ाइन उल्टा मानता है, तो वह मान्यता पहले ऐसे प्रदाता पर टूटती है जो उसे फ़िल्टर करता है। मान्यता लिख लें ताकि विफलता आने पर पहचानी जा सके।

प्रोटोकॉल और नामों से तय करें

प्रॉक्सी चुनें जब एक वेब क्लाइंट को एक वेब सेवा चाहिए और उसके पास प्रॉक्सी सेटिंग हो। SSH टनल चुनें जब कुछ ज्ञात TCP सेवाएँ काफ़ी हों और SSH पहुँच पहले से हो। VPN चुनें जब कई एप्लिकेशन, ग़ैर-TCP ट्रैफ़िक, निजी DNS या दोबारा इस्तेमाल हो सकने वाला मार्ग ज़रूरत का हिस्सा हों।

फिर असली क्लाइंट और असली नाम से जाँचें। प्रॉक्सी से पेज लोड करना आपको UDP के बारे में कुछ नहीं सिखाता, और एक उपकरण को SOCKS पर चलाना आपको सिस्टम रिज़ॉल्वर के बारे में कुछ नहीं सिखाता। पढ़ें कि प्रक्रिया किस स्थानीय पते से बँधी और किस रिज़ॉल्वर ने जवाब दिया। यही काम करने वाले मार्ग और एक बार संयोग से काम कर चुके मार्ग के बीच का फ़र्क़ है।