VPN सक्रिय रहँदा दोस्रो निजी मार्गमा SSH

एउटा मेसिन VPN मार्फत अर्कोमा पुग्छ, र अब कसैले त्यही शेल प्रदायकको निजी सञ्जालमा चाहन्छ। मार्ग अवस्थित छ, पिङ सफल हुन्छ, तैपनि SSH अस्वीकार गर्छ। सामान्य कारण डेमनले नयाँ ठेगानामा कहिल्यै सुनेको छैन, त्यसैले जोडिन केही छैन। यो फायरवालको समस्या हुनुअघि ठेगाना-बाइन्डिङको समस्या हो।

नयाँ मार्गले नयाँ श्रोता किन बनाउँदैन

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

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

ठेगाना र श्रोताहरूको सूची बनाउनुहोस्

केही सम्पादन गर्नुअघि होस्टमा भएका ठेगाना र अहिले भएका सकेटहरू अभिलेख गर्नुहोस्।

ip -br addr
ss -ltnp | grep ':22'

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

बाइन्डिङ थप्नुहोस् र पुरानो राख्नुहोस्

OpenSSH धेरै ListenAddress प्रविष्टि स्वीकार गर्छ, त्यसैले निजी मार्ग थपिँदा VPN मार्ग रहन सक्छ। फाइल पुनः लोड गर्नुअघि परीक्षण गर्नुहोस्।

sshd -t
systemctl reload sshd

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

पुरानो सत्र बन्द गर्नुअघि नयाँ सत्र जाँच्नुहोस्

मूल सत्र अझै खुला रहँदा नयाँ ठेगानामा जोडिनुहोस्, र कुन ठेगाना र कुञ्जी प्रयोग भयो हेर्न विस्तृत आउटपुट प्रयोग गर्नुहोस्। परीक्षण दुई पटक सफल नहुँदासम्म मूल सत्र खुला राख्नुहोस्।

ssh -v [email protected]

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

SSH ले यातायातको सुरक्षा गर्छ, तर एक्लैले दुई सञ्जाललाई समान बनाउँदैन। त्यसमा भर पर्नुअघि निजी ट्रान्जिटको विश्वास डेटासँग मिल्छ कि मिल्दैन निर्णय गर्नुहोस्।