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 ट्रांसपोर्ट की रक्षा करता है, लेकिन अलग-अलग रहते हुए वह दो नेटवर्क को समतुल्य नहीं बनाता। इस पर निर्भर होने से पहले तय करें कि निजी मार्ग का भरोसा डेटा से मेल खाता है या नहीं।