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

एउटा मेनु प्रविष्टिको पछाडि दुई नतिजा

दुवै मोडले एउटै तरिकाले प्रमाणीकरण गर्छन्, र त्यसैले तिनीहरूमा भ्रम हुन्छ। प्रोफाइललाई ठ्याक्कै उही तरिकाले, उही प्रमाणहरूसँग छान्दा तपाईंसँग रुट गर्न सकिने इन्टरफेस वा एउटा एपलाई जानकारी दिनुपर्ने सुन्ने सकेट रहन सक्छ।

कार्यलाई वास्तवमा कुन नतिजा चाहिन्छ भनेर निर्णय गरेर सुरु गर्नुहोस्। पूरै सबनेटमा पुग्ने आवश्यकतालाई यन्त्र चाहिन्छ। टाढाको होस्टमा एउटा सेवालाई फर्वार्ड चाहिन्छ, र त्यसका लागि टनेल बनाउँदा सामान्यतया समस्याले योग्य ठानेभन्दा बढी रुटिङ काम सिर्जना हुन्छ।

काम गर्नुअघि प्रत्येक मोडमा के हुनुपर्छ

परियोजनाले दुवै मोडको दस्तावेज राख्छ, र पूर्वसर्तहरू यति फरक छन् कि एउटा छुट्दा यो डिजाइनको विकल्प नभई प्रोटोकलको असफलता जस्तो देखिन्छ।

ModeWhat must existWhat still has to be true
Tunnel deviceCompatible TUN/TAP arrangement on both ends, permission, addressingA route policy that actually sends the intended prefixes into it
Forwarding onlyA chosen SOCKS, local-forward or remote-forward listenerA permitted destination path on the far side

दायाँ स्तम्भ ध्यान दिएर पढ्नुहोस्, किनकि यस्ता धेरै टिकटहरू त्यहीँ अन्त्य हुन्छन्। पूर्ण रूपमा बनेको टनेल यन्त्रले पनि रुटिङले त्यसमा पठाउने कुरा मात्र समेट्छ, र पूर्ण फर्वार्डले पनि यो प्रयोग गर्न भनिएका एपहरूलाई मात्र मद्दत गर्छ।

डमी इन्टरफेस टनेल होइन

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

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

nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"

त्यसपछि नतिजालाई एपसँग मिलाउनुहोस्। SOCKS बुझ्ने प्रोग्रामलाई प्रोक्सी प्रयोग गर्न कन्फिगर गर्नुपर्छ। स्थानीय फर्वार्डको उपभोक्तालाई यसको सुन्ने ठेगानातर्फ निर्देशित गर्नुपर्छ। दुवैले फर्वार्ड आफैं पत्ता लगाउँदैनन्, र हरियो भइसकेको जडान सूचकले दुवैलाई मद्दत गर्दैन।

टाढाको पक्षलाई जबरजस्ती नगरी तयार पार्नुहोस्

साधारण SSH खाताले टाढाको टनेल यन्त्र उठाउने कुनै अनुमति बिना प्रमाणीकरण गर्न सक्छ। परियोजनाले root-रहित मार्गको दस्तावेज राख्छ जसमा प्रशासकले त्यो प्रयोगकर्ताका लागि यन्त्र पहिले नै बनाउँछ, र त्यसपछि क्लाइन्टले मिल्ने नम्बर छान्छ।

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

तपाईंले गर्नु नहुने कुरा भनेको नमुना चलोस् भनेर असीमित फर्वार्डिङ वा टाढाको root लगइन सक्षम गर्नु हो। जहाँ अपरेटरसँग टाढाको सञ्जालको सेटअप छ, त्यहाँ ती आदेशहरू त्यही मालिककहाँ छोड्न समर्थित व्यवस्था प्रयोग गर्नुहोस्, र डिस्कनेक्ट हुँदा विरोधाभासी ठेगानाहरू पुनःस्थापित गर्ने दोस्रो सहायकलाई बेवास्ता गर्नुहोस्।

प्रमाणीकरणको सन्दर्भ, र टिकटमा के राख्ने

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

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

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