के प्रयोगकर्ता सत्रले VPN माथिको SSHFS माउन्टको स्वामित्व लिनुपर्छ?

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

दुई पहिचान, दुई छुट्टै अनुमति

VPN क्लाइन्टलाई मार्ग र इन्टरफेस परिवर्तन गर्न विशेषाधिकार चाहिन्छ। SSHFS माउन्टलाई फाइल सर्भरले स्वीकार गर्ने SSH पहिचान र फाइल पढ्ने खाताको स्वामित्वमा रहेको FUSE माउन्ट चाहिन्छ। रूटको रूपमा चल्ने एउटा स्क्रिप्टले पहिलो आवश्यकता पूरा गर्छ र दोस्रोलाई चुपचाप तोड्छ।

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

कुनै पनि अटोमेसन लेख्नु अघि कुन खाता माउन्टको मालिक हो निर्णय गर्नुहोस्, किनकि त्यो छनोटले ट्रिगर कहाँ बस्छ र कुन क्रेडेन्सियलसम्म पुग्न सक्छ भन्ने निर्धारण गर्छ।

पहिले हातले प्रयोगकर्ता-स्वामित्वको माउन्ट स्थापना गर्नुहोस्

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

mkdir -p "$HOME/mnt/team"
sshfs [email protected]:/exports/team "$HOME/mnt/team"
mount | grep sshfs

नामहरू उदाहरण हुन्, त्यसैले तपाईंको सर्भरले वास्तवमा प्रदान गर्ने होस्ट र निर्यात मार्ग प्रतिस्थापन गर्नुहोस्। पहिलो जडानमा स्वीकृत प्रक्रियामार्फत होस्ट कुञ्जी प्रमाणित गर्नुहोस्। VPN खाताको पासवर्ड स्वतः स्टोरेज खाताको क्रेडेन्सियल नहुने कुरा ध्यान दिनुहोस्, र यो असफल प्रयासहरूको सामान्य कारण हो।

यसलाई सामान्य प्रयोगकर्ताको रूपमा, त्यो प्रयोगकर्ताको स्वामित्वमा रहेको माउन्टपोइन्टसँग चलाउनुहोस्। पूर्वनिर्धारित रूपमा माउन्ट गर्ने खाता मात्र फाइलहरूसम्म पुग्छ, र allow_other ले त्यो सीमा हरेक स्थानीय प्रयोगकर्तासम्म विस्तार गर्छ। त्यो पहुँचको जानाजानी विस्तार हो, अटोमेसनका लागि वैकल्पिक उपाय होइन।

ट्रिगरलाई त्यही सत्र सन्दर्भमा कार्य गर्न दिनुहोस्

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

कार्यले अपेक्षित होस्टनाम पुष्टि गर्नुपर्छ, अवस्थित माउन्टलाई ध्यान दिनुपर्छ र एउटा सीमित प्रयास गर्नुपर्छ। हरेक केही सेकेन्डमा नयाँ SSHFS प्रक्रिया सुरु गर्ने वा सर्भर बन्द हुँदा क्रेडेन्सियल अनुरोध दोहोर्याउने पोल लूपले छोटो अवरोधलाई अड्किएका प्रक्रियाहरूको थुप्रोमा परिणत गर्छ। प्रयासलाई टाइमआउट र एउटा पुनः प्रयासले सीमित गर्नुहोस्।

nmcli -g UUID connection show --active
systemctl --user list-units 'sshfs*'
pgrep -a sshfs

पहिलो आदेशले डिस्प्याचरले मिलाउनुपर्ने जडान पहिचानकर्ता दिन्छ। बाँकी दुईले प्रयास पहिले नै चलिरहेको छ कि छैन देखाउँछन्, र यही दोहोरो रोक्ने जाँच हो।

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

बलपूर्वक सफाइ अघि विच्छेदनको योजना बनाउनुहोस्

योजना गरिएको विच्छेदनका लागि, फाइल कार्यहरू पूरा गर्नुहोस् र माउन्ट गर्ने प्रयोगकर्ताको आफ्नै कार्यप्रवाहबाट अनमाउन्ट गर्नुहोस्। प्रक्रियाको सट्टा माउन्टपोइन्टलाई लक्षित गर्नुहोस्, र सफलता रिपोर्ट गर्नु अघि नतिजा पुष्टि गर्नुहोस्।

fusermount3 -u "$HOME/mnt/team"
mountpoint "$HOME/mnt/team"

यो कार्यप्रवाहले सिर्जना गरेको माउन्ट मात्र अनमाउन्ट गर्नुहोस्। यदि यो व्यस्त छ भने, त्यो अनुप्रयोगको निर्णय हो: हुकलाई सफलता फर्काउनका लागि अवस्थित बलपूर्वक डिट्याचले डेटा हानि रोक्नुको सट्टा लुकाउँछ।

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

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