VPN के ज़रिए NFS पुनर्निर्यात पैकेट अग्रेषण नहीं है

एक Linux बॉक्स किसी VPN से जुड़ता है, कोई दूरस्थ NFS निर्यात माउंट करता है, और फिर उस माउंट को क्लाइंट के दूसरे समूह को परोसता है। यह व्यवस्था अतिरिक्त चरणों वाले राउटिंग जैसी लगती है, और यह पहली ग़लत धारणा है। बीच की मशीन ऊपरी सर्वर की क्लाइंट और निचले क्लाइंट के लिए सर्वर है, और वह दोनों फ़ाइल-सेवा संबंधों में भाग लेती है। पैकेट अग्रेषण का फ़ाइलहैंडल, लॉकिंग या फ़ाइलसिस्टम पहचान पर कोई मत नहीं है; पुनर्निर्यात का है।

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

तीन मॉडल, संगति की तीन कहानियाँ

सीधा माउंट सबसे सरल है: हर क्लाइंट टनल के ज़रिए मूल सर्वर माउंट करता है, और उस सर्वर की निर्यात नीति पहुँच को नियंत्रित करती है। पुनर्निर्यात यह है कि बीच की मशीन एक अलग सेवा सीमा प्रस्तुत करती है, जो तब उपयोगी होता है जब क्लाइंट की ओर का नेटवर्क सीधे सर्वर तक न पहुँच सके। प्रतिकृति तीसरा मॉडल है, और वह प्रश्न को संगति से समन्वयन और द्वंद्व समाधान की ओर बदल देती है।

प्रतिकृत प्रति को जीवंत पुनर्निर्यात की तरह न बताएँ। विफलता के तरीके अलग हैं, और जो उपयोगकर्ता यह अपेक्षा करता है कि हर क्रिया मूल फ़ाइलसिस्टम तक पहुँचेगी, वह लिंक बाधा के दौरान चौंक जाएगा।

पहचान माउंट आदेश से अधिक जीती है

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

फ़ाइलहैंडल दूसरी पहचान सीमा हैं: पुनर्निर्यात मूल हैंडल को लपेटता है, जिससे वह बड़ा हो जाता है और क्लाइंट की सीमा से अधिक हो सकता है। सफल माउंट यह सिद्ध नहीं करता कि हर निर्यात लेआउट संगत है।

हर NFS सुविधा बीच की मशीन से नहीं बचती

कर्नेल की पुनर्निर्यात मार्गदर्शिका कहती है कि पुनर्निर्यात करने वाला सर्वर लॉकिंग या प्रत्यायोजन अनुरोधों का समर्थन नहीं करता। जो अनुप्रयोग उन क्रियाओं पर निर्भर हैं, उन्हें अलग मार्ग या उनके विरुद्ध सत्यापित डिज़ाइन चाहिए। सफल माउंट और काम कर रही निर्देशिका सूची यह नहीं दिखाते कि अनुप्रयोग की वास्तविक क्रियाएँ काम करती हैं।

उपयोगकर्ता पहचान और निर्यात नीति भी हर छलांग पर मायने रखती हैं। VPN लॉगिन सिद्ध करता है कि कोई नेटवर्क भागीदार प्रमाणित हुआ; यह किसी NFS उपयोगकर्ता को अधिकृत नहीं करता, और गेटवे के पार क्लाइंट के क्रेडेंशियल अग्रेषित नहीं करता।

गेटवे की दो ऊपरी निर्भरताएँ हैं

गेटवे ऊपरी माउंट के लिए VPN पर और फ़ाइलसिस्टम के लिए ऊपरी सर्वर पर निर्भर है। अभी चल रही स्थानीय निर्यात प्रक्रिया अनुपलब्ध संग्रहण को स्वस्थ नहीं बना सकती। शुरुआती क्रम, पुनःकनेक्शन व्यवहार और सर्वर पुनःआरंभ की योजना बनाएँ, जिसमें यह भी शामिल है कि क्लाइंट के पास पहले से मौजूद फ़ाइलहैंडल का क्या होगा। जो क्लाइंट गेटवे से होकर माउंट कर चुका है और अपना हैंडल खो चुका है, उसे पुनःमाउंट चाहिए, और यह एक परिचालन घटना है, पारदर्शी पुनर्प्राप्ति नहीं।

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

कार्यभार का परीक्षण करें, माउंट का नहीं

नियंत्रित वातावरण में वास्तविक फ़ाइल कार्यभार का अभ्यास करें: अनुप्रयोग जो क्रियाएँ करता है, जो फ़ाइल आकार उपयोग करता है और जो समवर्तीता अपेक्षित है। केवल परिवहन त्रुटियों नहीं, सुविधा अंतरालों पर ध्यान दें। फिर लिखें कि आपने कौन सा मॉडल चुना और क्यों, क्योंकि अन्यथा अगला व्यक्ति मान लेगा कि गेटवे एक राउटर है।

पुनर्निर्यात वैध है जब वह जानबूझकर किसी कारण से हो, जैसे अलग क्लाइंट नेटवर्क या नियंत्रित संस्करण सीमा। यह एक बुरा संयोग है, और अंतर यह है कि किसी ने उसका निर्णय लिया या नहीं।