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 मा चलाउँदा प्रणाली रिजोल्भरबारे केही सिकिँदैन। प्रक्रिया कुन स्थानीय ठेगानामा बाँधियो र कुन रिजोल्भरले जवाफ दियो पढ्नुहोस्। काम गर्ने बाटो र एकचोटि संयोगले काम गरेको बाटोबीचको फरक यही हो।