VPN मार्फत NFS पुनर्निर्यात प्याकेट फर्वार्डिङ होइन

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

तलका ग्राहकहरू मूल सर्भरमा सिधै पुग्न सक्थे कि भनेर सोध्नबाट सुरु गर्नुहोस्। यदि सक्छन् भने, बीचको मेसिन वैकल्पिक हो।

तीन मोडेल, स्थिरताका तीन कथाहरू

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

प्रतिकृत प्रतिलाई जीवित पुनर्निर्यात जस्तै वर्णन नगर्नुहोस्। असफलताका तरिका फरक छन्, र प्रत्येक कार्य मूल फाइलसिस्टममा पुग्छ भन्ने अपेक्षा गर्ने प्रयोगकर्ता लिङ्क विच्छेदको बेला अचम्मित हुनेछ।

पहिचान माउन्ट आदेशभन्दा लामो बाँच्छ

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

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

हरेक NFS सुविधा बीचको मेसिनबाट बाँच्दैन

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

प्रयोगकर्ता पहिचान र निर्यात नीति पनि हरेक फड्कोमा महत्त्वपूर्ण छ। VPN लगइनले सञ्जाल सहभागी प्रमाणित भएको प्रमाणित गर्छ; यसले NFS प्रयोगकर्तालाई अधिकृत गर्दैन, र गेटवेमार्फत ग्राहकको प्रमाणहरू पठाउँदैन।

गेटवेसँग दुई माथिल्ला निर्भरता छन्

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

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

माउन्टको होइन, कार्यभारको परीक्षण गर्नुहोस्

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

पुनर्निर्यात तब वैध हुन्छ जब त्यो जानाजान कारणका लागि अस्तित्वमा छ, जस्तै अलग ग्राहक सञ्जाल वा नियन्त्रित संस्करण सीमा। त्यो नराम्रो दुर्घटना हो, र फरक यो हो कि कसैले त्यो निर्णय गरेको हो कि भनेर।