आफ्नो SSH क्लाइन्टमार्फत टाढाको Pi लाई SOCKS प्रोक्सी दिनुहोस्

टाढाको गतिशील फर्वार्डले SOCKS श्रोतालाई Pi मा राख्छ र अर्को जडान तपाईंको ल्यापटपको स्वीकृत VPN बाटोबाट गर्छ। दोस्रो SSH सर्भर आवश्यक छैन।

तपाईं मान्नुहुन्छ कि SOCKS प्रोक्सी नेटवर्क पहुँच पहिले नै भएको ठाउँमै चल्नुपर्छ। OpenSSH ले श्रोतालाई पूर्ण रूपमा अर्कै ठाउँमा राख्न सक्छ। टाढाको गतिशील फर्वार्डले टाढाको होस्टमा SOCKS पोर्ट खोल्छ र प्रत्येक जडान तपाईंको स्थानीय SSH क्लाइन्टबाट सुरु गर्छ, जसले तपाईंको ल्यापटपको स्वीकृत VPN बाटो बोक्छ। Pi ले सीमित प्रोक्सी पाउँछ; यसले तपाईंको टनेल वा तपाईंको विशेषाधिकार हस्तान्तरण गर्दैन.

श्रोता र जडान सुरु हुने पक्ष फरक हुन सक्छ

साधारण ssh -D 1080 श्रोतालाई तपाईंकै मेसिनमा चलाउँछ र त्यहीँबाट जडानहरू पठाउँछ। टाढाको गतिशील फर्वार्डले यसलाई उल्टाउँछ: श्रोता टाढाको होस्टमा देखिन्छ, र यसले स्वीकार गर्ने प्रत्येक जडान स्थानीय पक्षबाट खोलिन्छ। OpenSSH क्लाइन्ट म्यानुअल ले निश्चित गन्तव्य बिनाको -R लाई ठ्याक्कै यही SOCKS4/5 व्यवस्था भनी अभिलेख गर्छ।

ल्यापटपबाट समर्थित आदेश यसरी देखिन्छ, जहाँ खाता, होस्ट र पोर्ट प्लेसहोल्डर मानिन्छ:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

त्यहाँ तीन विवरणले उपयोगी काम गर्छन्। -S none ले सत्रलाई साझा नियन्त्रण मास्टरबाट टाढा राख्छ, ExitOnForwardFailure ले तपाईंलाई आधा खुला सत्र छोड्नुको सट्टा छिटो असफल हुन्छ, र PermitRemoteOpen ले टाढाको श्रोता कहाँसम्म पुग्न सक्छ भन्ने सीमित गर्छ। अधिकृत Pi खाता प्रयोग गर्नुहोस् र यीमध्ये केही थप्नु अघि होस्ट कुञ्जी प्रमाणित गर्नुहोस्।

टाढाको श्रोताले वास्तवमा के खुलासा गर्छ

श्रोतामा भर पर्नु अघि सर्भरको फर्वार्डिङ नीति जाँच्नुहोस्। GatewayPorts no सँग टाढाको फर्वार्ड loopback मा बाँधिएको रहन्छ, र त्यही नै तपाईंले चाहेको खुलासा हो। वाइल्डकार्ड फर्वार्डिङ जबरजस्ती गर्न कन्फिगर गरिएको सर्भरले उही पोर्ट हरेक इन्टरफेसमा प्रकाशित गर्छ, जसले व्यक्तिगत प्रोक्सीलाई स्थानीय नेटवर्कले पुग्न सक्ने कुरामा बदल्छ।

loopback पनि प्रति-प्रयोगकर्ता सीमा होइन। Pi मा अर्को प्रक्रियाले पोर्ट थाहा पाएमा 127.0.0.1:1080 मा जोडिन सक्छ, त्यसैले Pi का स्थानीय खाता र त्यसमा चल्ने सबै कुरा तपाईंको पहुँच डिजाइनको भाग हुन्। यो गन्तव्य सूची साँघुरो राख्ने कारण हो, नीति जाँच छोड्ने कारण होइन।

तपाईं पुग्न खोजिरहनुभएको एप्लिकेसनका लागि अनुमत गन्तव्य विशिष्ट राख्नुहोस्। असम्बन्धित कार्यक्रम चलाउन यसलाई असीमित फर्वार्डिङले बदल्नु तपाईंले सुरु गरेको समस्याभन्दा धेरै पर बाटो फराकिलो बनाउँछ। गन्तव्य सूचीले सत्र केका लागि थियो भन्ने पनि अभिलेख गर्छ, जसले पछि अडिट गर्नेलाई सहयोग गर्छ। तपाईंले प्रयोग गरेको खाताको छेउमा यो लेख्नुहोस्।

एउटा एप्लिकेसनलाई प्रोक्सीबाट पठाउनुहोस्

Pi मा प्रोक्सी बुझ्ने क्लाइन्टले त्यसपछि अनुरोध गर्न सक्छ। socks5h उपसर्गले गन्तव्यको नाम प्रोक्सीलाई दिन्छ, त्यसैले खोज र जडान दुवै ल्यापटपको पक्षमा हुन्छन्, र यो PermitRemoteOpen मा नाम दिइएको गन्तव्यसँग मेल खान्छ:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

सामान्य प्रमाणपत्र प्रमाणीकरण र एप्लिकेसनको आफ्नै प्रमाणीकरण राख्नुहोस्। प्रोक्सीले TCP जडान कहाँ बन्छ त्यो बदल्छ; यसले प्रमाणीकरण नभएको सेवालाई सुरक्षित बनाउँदैन र स्व-हस्ताक्षरित अन्त्य बिन्दुलाई विश्वसनीय बनाउँदैन।

ल्यापटपलाई अझै पनि आफ्नै मार्ग र SSH सर्भर तथा एप्लिकेसन दुवैमा रिजोल्भर पहुँच चाहिन्छ। यसको SSH क्लाइन्टको ट्राफिक स्वीकृत VPN नीतिले छान्नुपर्छ, र split-tunnel बहिष्कारले त्यो ट्राफिक तपाईंले परीक्षण गरेको मार्गभन्दा फरक मार्गमा पठाउन सक्छ।

मार्ग प्रमाणित गर्नुहोस् र बन्द गर्नुहोस्

श्रोता तपाईंले अपेक्षा गरेको ठाउँमा छ र केवल अभीष्ट गन्तव्यले मात्र जवाफ दिन्छ भनी पुष्टि गर्नुहोस्:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure ले फर्वार्डिङ स्थापित भएको प्रमाणित गर्न सक्छ, र तैपनि एप्लिकेसनमा लगइन तलतिर सफल हुन्छ भनी प्रमाणित गर्न सक्दैन। पोर्ट मात्र होइन, एप्लिकेसन परीक्षण गर्नुहोस्। स्वीकार गरेर त्यसपछि हरेक अनुरोध असफल बनाउने श्रोता सामान्यतया टनेल असफल भयो भन्ने होइन, गन्तव्यको नाम वा ल्यापटपको मार्ग गलत छ भन्ने हो।

यो व्यवस्थाले TCP मात्र बोक्छ। UDP, ICMP र प्रोक्सी सेटिङ बेवास्ता गर्ने कार्यक्रमहरू यसबाहिर रहन्छन्, र SSH सत्र सकिएको क्षणमा फर्वार्डिङ सकिन्छ। काम सकिएपछि त्यो सत्र रोक्नुहोस् र एप्लिकेसनमा थपेको प्रोक्सी सेटिङ हटाउनुहोस्।

स्थायी पहुँचका लागि यसको सट्टा नेटवर्क मालिकको समर्थित दर्ता वा व्यवस्थापित गेटवे प्रयोग गर्नुहोस्। VPN का यन्त्र वा स्रोत प्रतिबन्ध छल्न रिभर्स प्रोक्सी गलत साधन हो; ती प्रतिबन्धभित्र प्रयोग गर्दा यो स्पष्ट सीमा भएको एउटै अधिकृत एप्लिकेसन मार्ग मात्र हो।

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