रिभर्स SSH प्रोक्सी लिस्नर सर्भरमा मात्र किन पहुँचयोग्य हुन्छ
प्रोक्सी प्रोटोकल वा प्रमाणहरू परिवर्तन गर्नु अघि रिमोट लिस्नरको bind ठेगाना र GatewayPorts मोड जाँच गर्नुहोस्।
रिमोट फर्वार्ड SSH सर्भरबाट काम गर्न सक्छ तर अर्को मेसिनबाट आउने जडान अस्वीकार गर्न सक्छ, किनकि यो loopback मा मात्र सुन्छ। पहिले वास्तविक सुन्ने ठेगाना जाँच गर्नुहोस्।
सर्भर पट्टि GatewayPorts | रिमोट-फर्वार्ड bind |
|---|---|
no, पूर्वनिर्धारित | लिस्नरहरूलाई loopback मा सीमित गर्छ |
yes | wildcard bind लाई बाध्य गर्छ |
clientspecified | क्लाइन्टलाई विशेष bind ठेगाना माग्न अनुमति दिन्छ |
एउटा नियन्त्रित इन्टरफेसका लागि लक्षित लिस्नरका लागि, सर्भरले यो प्रयोग गर्न सक्छ:
GatewayPorts clientspecifiedत्यसपछि क्लाइन्टले आफ्नो -R स्पेसिफिकेसनमा उपयुक्त ठेगाना माग्छ। त्यो ठेगाना रिमोट मेसिनमा हुनुपर्छ, र अन्य फर्वार्डिङ प्रतिबन्धहरू अझै लागू हुन्छन्। क्लाइन्ट-साइड -g यो दिशाका लागि अदलबदल गर्न मिल्ने नियन्त्रण होइन।
तीन अनुमतिहरू छुट्टै रहन्छन्: फर्वार्ड सिर्जना गर्न SSH अनुमति, यसको लिस्नरमा नेटवर्क पहुँच, र HTTP वा SOCKS सेवाको आफ्नै पहुँच नीति। SSH लगइनले सुरुङ सिर्जना गर्नेलाई प्रमाणित गर्छ; यसले साझा लिस्नरको प्रत्येक पछिको कलरलाई प्रमाणित गर्दैन र SOCKS पासवर्ड चुनौती थप्दैन।
यदि रिमोट कलर अझै जडान गर्न सक्दैन भने, bind ठेगाना, सर्भरका फर्वार्डिङ प्रतिबन्ध र फायरवाल मार्ग यही क्रममा जाँच गर्नुहोस्। TCP लिस्नरमा पुगेपछि, असफल प्रोक्सी ह्यान्डशेक पछिको समस्या हो।