अवस्थित HTTP प्रोक्सीमा SSH स्थानीय फर्वार्ड: दुई loopback ठेगाना

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

स्थिर प्रोक्सी पहिलेदेखि छ कि छैन निर्णय गर्नुहोस्

यो प्रविधिले पहिलेदेखि चलिरहेको सेवालाई फर्वार्ड गर्छ। यदि टाढाको होस्टमा केवल SSH डेमन छ र प्रोक्सी छैन भने जति फर्वार्ड गरे पनि त्यो बन्ने छैन, र जडान टाढाको पक्षबाट अस्वीकार हुनेछ। प्रोक्सी बाँधिएको छ कि छैन, यसको पोर्ट कुन हो, र यो 127.0.0.1 मा सुन्छ कि कुनै विशेष इन्टरफेस ठेगानामा, पुष्टि गर्नुहोस्, किनकि फर्वार्डले त्यही ठेगानालाई लक्ष्य गर्नुपर्छ।

यसलाई पहिले पुष्टि गरेमा कहिल्यै कुनै कुरासँग जोडिएको नभएको सुरुङ डिबग गर्नबाट बच्नुहुनेछ।

फर्वार्ड बनाउनुहोस् र आदेश पढ्नुहोस्

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

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N ले टाढाको आदेश दबाउँछ र -T ले termios विनियोजन दबाउँछ, किनकि तपाईंलाई शेल होइन, सुरुङ चाहिन्छ। पहिलो loopback ठेगाना ल्यापटपले सुन्ने ठाउँ हो; दोस्रो SSH सर्भरले समाधान गर्छ, त्यसैले त्यहाँको 127.0.0.1 भन्नाले त्यो मेसिनको प्रोक्सी बुझिन्छ। ExitOnForwardFailure ले स्थानीय पोर्ट पहिलेदेखि ओगटिएको भए केही पनि फर्वार्ड नगर्ने सत्र सुरु गर्नुको सट्टा आदेशलाई ठूलो स्वरमा असफल बनाउँछ। लक्ष्य ठेगाना सर्भरले समाधान गरेझैं लेख्नुहोस्, किनकि तपाईंको ल्यापटपले मात्र समाधान गर्न सक्ने नाम पारिपट्टि असफल हुनेछ।

यीमध्ये केही काम गर्नुअघि सर्भरको आफ्नै नीति लागू हुन्छ। AllowTcpForwarding ले यसलाई अनुमति दिनुपर्छ, र PermitOpen ले सत्र कुन गन्तव्य र पोर्टसम्म पुग्न सक्छ भनी सीमित गर्न सक्छ, त्यसैले ग्राहकले स्वीकार गरेको फर्वार्ड पनि सर्भरले अस्वीकार गर्न सक्छ। अस्वीकृति ग्राहकमा फर्वार्ड वा च्यानल त्रुटिका रूपमा देखिन्छ, र त्यो सन्देश पढ्नु आदेश सम्पादन गर्नुभन्दा छिटो हुन्छ।

एउटा अनुप्रयोगलाई फर्वार्डतर्फ फर्काउनुहोस्

अनुप्रयोगलाई http://127.0.0.1:13128 मा HTTP प्रोक्सी प्रयोग गर्न कन्फिगर गर्नुहोस्, टाढाको प्रोक्सीले मागेमा प्रमाणहरूसहित। HTTPS गन्तव्यका लागि अनुप्रयोगको आफ्नै प्रमाणपत्र प्रमाणीकरण राख्नुहोस्, किनकि प्रोक्सी सुरुङले त्यसलाई प्रतिस्थापन गर्दैन। यो एउटा सेवाको स्थिर फर्वार्ड हो, त्यसैले अनुप्रयोगलाई प्रोक्सीबारे भन्नुपर्छ, आफैं पत्ता लगाउन छोड्नु हुँदैन।

कुनै पनि स्थायी कन्फिगरेसनअघि छिटो जाँच: curl -x http://127.0.0.1:13128 -I https://example.com, जसले प्रोक्सीले समर्थन गर्नुपर्ने HTTP CONNECT विधिको अभ्यास गर्छ।

अधिकार जहाँ थियो त्यहीँ राख्नुहोस्

टाढाको प्रोक्सीले अझै कुन गन्तव्य र विधिलाई अनुमति दिने भनी निर्णय गर्छ, र SSH लगइनले प्रत्येक खातालाई चुपचाप सामान्य वेब रिले दिनु हुँदैन। ल्यापटपमा 127.0.0.1 मा बाँध्दा पोर्ट तपाईंको स्थानीय सञ्जालमा प्रकाशित हुनबाट बचिन्छ, र यसले पोर्टलाई एउटै मेसिनका अन्य प्रक्रियाबाट निजी बनाउँदैन। त्यो बन्धनलाई प्रोक्सी साझा गर्न wildcard ठेगानाले प्रतिस्थापन गर्नु नै अनियन्त्रित खुला रिले बन्ने बाटो हो।

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

दुवै छेउ प्रमाणित गर्नुहोस्, त्यसपछि सफा गर्नुहोस्

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

सकिएपछि, यसलाई राख्ने SSH प्रक्रिया रोक्नुहोस्, अनुप्रयोगबाट प्रोक्सी सेटिङ हटाउनुहोस्, र कामभन्दा लामो बाँच्ने सुन्ने छोड्नुको सट्टा स्थानीय पोर्ट गएको पुष्टि गर्नुहोस्।