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 जोडल्याने कोण काय पाहतो हे बदलते आणि साखळीतील स्थान कोणती उडी सिफरटेक्स्ट पाहते हे ठरवते।

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

बनावट पत्ता हा पर्याय नाही

दुसऱ्याच्या स्रोत पत्त्याने पॅकेट बनवल्याने काहीही उपयुक्त मिळत नाही: उत्तरे खऱ्या मालकाकडे जातात आणि बहुतेक संजाळे रहदारी सरळ टाकून देतात। मध्यस्थ यामुळेच आवश्यक आहे की स्रोत कल्पून काढता येत नाही आणि तेच तीनही आराखड्यांचे प्रामाणिक समर्थन आहे।

हे त्यांपैकी प्रत्येकजण काय दावा करू शकतो हेही मर्यादित करते। ठराविक पत्त्यावरून येत असल्यासारखे दिसणे हा तो पत्ता कायदेशीरपणे कुठे दिला आहे आणि कोण त्याला मार्गस्थ करू शकतो याचा प्रश्न आहे, कोणते साधन शीर्षलेख बनावट करू शकते याचा नाही। आराखडा उलट गृहीत धरत असेल तर ते गृहीतक ते गाळणाऱ्या पहिल्या पुरवठादाराकडे कोसळते। गृहीतक लिहून ठेवा, म्हणजे अपयश आल्यावर ओळखता येईल।

प्रोटोकॉल आणि नावांवरून ठरवा

एका वेब क्लायंटला एक वेब सेवा हवी असेल आणि प्रॉक्सी सेटिंग असेल तर प्रॉक्सी निवडा। काही ज्ञात TCP सेवा पुरेशा असतील आणि SSH प्रवेश आधीच असेल तर SSH बोगदा निवडा। अनेक अनुप्रयोग, TCP नसलेली रहदारी, खाजगी DNS किंवा पुन्हा वापरता येणारा मार्ग गरजेचा भाग असेल तर VPN निवडा।

मग खऱ्या क्लायंटने आणि खऱ्या नावाने तपासा। प्रॉक्सीमधून पान लोड करणे तुम्हाला UDP बद्दल काहीच शिकवत नाही आणि एक साधन SOCKS वर चालवणे सिस्टम निराकरणकर्त्याबद्दल काहीच शिकवत नाही। प्रक्रिया कोणत्या स्थानिक पत्त्याला बांधली गेली आणि कोणी निराकरणकर्त्याने उत्तर दिले ते वाचा। चालणारा मार्ग आणि एकदा योगायोगाने चाललेला मार्ग यातला फरक हाच।