स्थानीय SOCKS श्रोता केही सञ्जालमा उपयोगी हुन्छ र केहीमा हुँदैन। OpenSSH ले प्रोक्सी आदेशलाई सर्तअनुसार छान्न सक्छ, त्यो छनोट हरेक होस्टमा लागू नगरी।

OpenBSD रूपको nc सहित OpenSSH का लागि, एउटा उदाहरण क्लाइन्ट कन्फिगरेसन यो हो:

Host work-server
    HostName ssh.example.net
    User alex

Match originalhost work-server exec "nc -z -w 1 127.0.0.1 1080"
    ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p

Match all

originalhost ले जाँचलाई SSH आदेश लाइनमा दिइएको नाममा सीमित गर्छ। exec ले यसको आदेश सफलतापूर्वक सकिँदा मेल खान्छ। अन्तिम Match all ले पछिका सेटिङहरूका लागि त्यो सर्त-आधारित दायरा अन्त्य गर्छ।

यसले पहिलेको कुनै लागू सेटिङले पहिले नै विरोधाभासी प्रोक्सी आदेश वा जम्प मार्ग नछानेको मान्छ। SSH सामान्यतया कन्फिगरेसन विकल्पका लागि पहिलो प्राप्त मान प्रयोग गर्छ, त्यसैले माथिको फराकिलो पूर्वनिर्धारित मानले पछिको सर्तले अपेक्षित प्रभाव पार्न नदिन सक्छ।

सुनिरहेको सकेट एउटा विनम्र वाचा हो

जाँचले स्थानीय पोर्टमा TCP पहुँच परीक्षण गर्छ। यसले SOCKS वार्ता पूरा गर्दैन, चाहिएको गन्तव्य जडान स्थापना गर्दैन, र त्यो पोर्ट कुन प्रोग्रामको हो भनी प्रमाणित गर्दैन। जाँचपछि श्रोता हराउन पनि सक्छ।

समय-सीमाले असफल जाँचलाई सीमित राख्छ। देखाइएका विकल्पहरू OpenBSD को nc इन्टरफेसका हुन्; त्यही फाइलनाम भएका अन्य प्रोग्रामले फरक विकल्प दिन सक्छन्।

सर्त मिलेन भने, यो उदाहरणले जडानलाई यो ProxyCommand बिना छाड्छ, जसले यसको सामान्य मार्गलाई अनुमति दिन्छ। त्यो तब मात्र उपयुक्त हुन्छ जब सिधा पहुँचलाई अनुमति छ। अनिवार्य प्रोक्सी नीतिले उपलब्धता जाँचलाई अर्को मार्गतर्फ भाग्ने अनुमति बनाउनु हुँदैन।

लक्ष्य SSH होस्टनाम र होस्ट-की जाँचहरूले अझै गन्तव्य सर्भर पहिचान गर्छन्। यातायात सहायक छान्नु अप्रत्याशित होस्ट की स्वीकार्ने कारण होइन।

सम्बन्धित लेखहरू