VPN द्वारे NFS पुनर्निर्यात पॅकेट फॉरवर्डिंग नाही

एक Linux बॉक्स VPN मध्ये सामील होतो, दूरचे NFS निर्यात माउंट करतो आणि नंतर ते माउंट दुसऱ्या क्लायंट गटाला पुरवतो। ही व्यवस्था अधिक पायऱ्यांसह राउटिंगसारखी दिसते, आणि ही पहिली चुकीची धारणा आहे। मधले मशीन वरच्या सर्व्हरचे क्लायंट आणि खालच्या क्लायंटसाठी सर्व्हर आहे, आणि ते दोन्ही फाइल-सेवा संबंधांमध्ये सहभागी होते। पॅकेट फॉरवर्डिंगला फाइलहँडल, लॉकिंग किंवा फाइलसिस्टीम ओळखीबद्दल काही मत नाही; पुनर्निर्यातला आहे।

खालचे क्लायंट मूळ सर्व्हरपर्यंत थेट पोहोचू शकत होते का या प्रश्नाने सुरुवात करा। शक्य असल्यास, मधले मशीन ऐच्छिक आहे।

तीन मॉडेल, सुसंगतीच्या तीन कथा

थेट माउंट सर्वात सोपे आहे: प्रत्येक क्लायंट बोगद्यातून मूळ सर्व्हर माउंट करतो, आणि त्या सर्व्हरचे निर्यात धोरण प्रवेश नियंत्रित करते। पुनर्निर्यात म्हणजे मधले मशीन वेगळी सेवा सीमा सादर करते, जे क्लायंटकडील नेटवर्कने सर्व्हरपर्यंत थेट पोहोचू नये अशा वेळी उपयुक्त असते। प्रतिकृती हे तिसरे मॉडेल आहे, आणि ते प्रश्न सुसंगतीकडून समक्रमण आणि संघर्ष निराकरणाकडे वळवते।

प्रतिकृत प्रत आयुष्यमान पुनर्निर्यातसारखी वर्णन करू नका। अयशस्वीतेच्या पद्धती वेगळ्या आहेत, आणि प्रत्येक क्रिया मूळ फाइलसिस्टीमपर्यंत पोहोचेल अशी अपेक्षा असलेला वापरकर्ता दुवा तुटल्यावर आश्चर्यचकित होईल।

ओळख माउंट आदेशापेक्षा जास्त काळ टिकते

पुनर्निर्यातीसाठी स्पष्ट फाइलसिस्टीम ID आवश्यक आहे, आणि ती ओळख पुनःसुरुवात आणि संरचना पुनर्बांधणी टिकून राहिली पाहिजे। कर्नल दस्तऐवजीकरण आवश्यकतेबद्दल स्पष्ट आहे, आणि ते असेही इशारा देते की crossmnt उप-फाइलसिस्टीम त्यांच्या स्वतःच्या ID सह निर्यात करण्याची गरज काढून टाकत नाही। वापरकर्त्याला सतत वाटणारे डिरेक्टरी वृक्ष अनेक फाइलसिस्टीम सीमा ओलांडू शकते। सध्याचे nfs-utils समर्थित संरचनांसाठी ID स्वयंचलितपणे वाटू शकतात, आणि तसे केल्यावर त्यांचा डेटाबेस गेटवेच्या स्थितीचा भाग बनतो। त्या ID एकदा वापरून टाकल्या जाणाऱ्या फाइल्स न मानता सेवा ओळख माना।

फाइलहँडल ही दुसरी ओळख सीमा आहे: पुनर्निर्यात मूळ हँडल गुंडाळते, त्यामुळे ते मोठे होते आणि क्लायंटची मर्यादा ओलांडू शकते। यशस्वी माउंट प्रत्येक निर्यात मांडणी सुसंगत आहे हे सिद्ध करत नाही।

प्रत्येक NFS वैशिष्ट्य मधल्या मशीनमधून टिकत नाही

कर्नलचे पुनर्निर्यात मार्गदर्शक सांगते की पुनर्निर्यात करणारा सर्व्हर लॉकिंग किंवा प्रतिनिधित्व विनंत्या समर्थित करत नाही। त्या क्रियांवर अवलंबून असलेल्या अनुप्रयोगांना वेगळा मार्ग किंवा त्यांच्याविरुद्ध सत्यापित रचना आवश्यक आहे। यशस्वी माउंट आणि कार्यरत डिरेक्टरी यादी अनुप्रयोगाच्या वास्तविक क्रिया कार्यरत आहेत हे दाखवत नाहीत।

वापरकर्ता ओळख आणि निर्यात धोरण प्रत्येक झेपीवर महत्त्वाचे आहे। VPN लॉगिन नेटवर्क सहभागी प्रमाणित झाला हे सिद्ध करते; ते NFS वापरकर्त्याला अधिकृत करत नाही, आणि गेटवेमधून क्लायंटची ओळखपत्रे पाठवत नाही।

गेटवेचे दोन वरचे अवलंबन आहेत

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

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

माउंटची नाही, कामाच्या भाराची चाचणी करा

नियंत्रित वातावरणात खऱ्या फाइल कामाच्या भाराचा सराव करा: अनुप्रयोग ज्या क्रिया करतो, वापरत असलेल्या फाइल आकार आणि अपेक्षित समवर्तीता। केवळ वाहतूक त्रुटींकडे नाही, वैशिष्ट्यांच्या त्रुटींकडे लक्ष द्या। नंतर तुम्ही कोणते मॉडेल निवडले आणि का ते नोंदवा, कारण अन्यथा पुढील व्यक्ती गेटवे राउटर आहे असे गृहीत धरेल।

पुनर्निर्यात तेव्हा वैध असते जेव्हा ती जाणीवपूर्वक कारणासाठी अस्तित्वात असते, जसे वेगळे क्लायंट नेटवर्क किंवा नियंत्रित आवृत्ती सीमा। तो एक वाईट अपघात आहे, आणि फरक हा आहे की कोणी ते ठरवले का।