VPN पत्त्यावर बांधलेला NFS निर्यात: ते काय सिद्ध करत नाही
निर्यात नियम तपासतो की पॅकेट कुठून आले; AUTH_SYS स्थानिक UID घोषित करते आणि Kerberos वापरकर्त्याची प्रमाणिकता करते। तुमच्या फाइल सेवेला कोणती आवश्यक आहे ते ठरवा।
एक होस्ट डिरेक्टरीला VPN पत्त्यावर निर्यात करतो, माउंट यशस्वी होते, आणि रचना प्रमाणित म्हणून नोंदवली जाते। तो नियम प्रत्यक्षात फक्त पॅकेट कुठून येत असल्याचे दिसते ते मर्यादित करतो। फाइल क्रिया चालवणारी व्यक्ती तीच आहे जी ती स्वतःला म्हणते यावर NFS सुरक्षा फ्लेवरवर अवलंबून असते, आणि अशा बहुतेक निर्यातींमध्ये कोणीही ते डीफॉल्टवरून बदलले नाही।
एका विनंतीत तीन ओळखी येऊ शकतात
VPN पीअर क्लायंट सर्टिफिकेट किंवा पीअर की सारखी नोंदणीकृत ओळख बाळगतो। आतील IP पॅकेट स्रोत पत्ता बाळगते। फाइल क्रिया तिची NFS यंत्रणा जे वापरकर्ता क्रेडेन्शियल देते ते बाळगते। पत्त्याला तिन्हींचा पर्याय मानणारी रचना तपासायचा भागच शांतपणे गृहीत धरते।
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
ती तीन ओळी लिहिणे हाच संपूर्ण सराव आहे। निर्यात सुरक्षित आहे की नाही यावरील बहुतेक वाद कोणते नियंत्रण कोणत्या ओळीत राहते हे स्पष्ट होताच कोसळतो।
पत्त्याची मालकी ही अंमलबजावणीची तपशील आहे
गेटवे स्वीकारलेल्या पीअरला सुरंग पत्ता देऊ शकतो, किंवा त्यासाठी मार्गनिर्देशित उपजाळे अधिकृत करू शकतो। नंतर अंमलबजावणी आतील स्रोत दुसऱ्या क्लायंटचा असलेले पॅकेट नाकारते का हे त्या अंमलबजावणीचे गुणधर्म आहे, आणि गृहीत धरण्याऐवजी ते तपासणे योग्य आहे।
पारंपरिक Community OpenVPN वापरकर्ता-जागा सर्व्हर कोड, उदाहरणार्थ, पॅकेट TUN उपकरणातून पोहोचवण्यापूर्वी दुसऱ्या क्लायंटशी संबंधित स्रोत नाकारू शकतो। हे खऱ्या मूल्याचे पत्ता-मालकी तपासणी आहे, आणि ते अजूनही NFS वापरकर्ता प्रमाणीकरण नाही, कारण कोणते खाते क्रिया करत आहे याबद्दल ते काहीही सांगत नाही।
स्रोत भाषांतर तेही झिजवते। NAT गेटवे प्रत्येक क्लायंटला एकच पत्ता म्हणून सादर करू शकतो, आणि मग निर्यात नियम त्याच्या मागील लोकांमध्ये फरक करू शकत नाही। नियमाची दिसणारी अचूकता मग आकृतीने टिकवलेली कल्पना बनते। निर्यात महत्त्वाची असल्यास, पत्तानिर्देश स्पष्ट ठेवा, भाषांतरकाराला कोण कोणाच्या जागी मोजला जातो हे ठरवू देऊ नका।
निर्यातीवर विश्वास ठेवण्यापूर्वी सुरक्षा फ्लेवर वाचा
Red Hat चे NFS मार्गदर्शन sec=sys, जे AUTH_SYS द्वारे स्थानिक UNIX UID आणि GID वापरते, ते Kerberos पद्धतींपासून वेगळे करते। krb5 वापरकर्ता प्रमाणीकरण जोडते, krb5i अखंडता संरक्षण जोडते, आणि krb5p रहदारीसाठी गोपनीयता संरक्षण जोडते।
AUTH_SYS क्रेडेन्शियलमध्ये कॉलरचे UID आणि गट ओळखकर्ते अशी क्षेत्रे असतात, आणि RFC 5531 स्पष्ट इशारा देते की हे फ्लेवर स्वतः कोणतीही सुरक्षा देत नाही आणि बाह्य संरक्षणावर अवलंबून आहे। ते VPN च्या आत चालवल्याने वाहतुकीस संरक्षण मिळते आणि पॅकेटच्या आतल्या दाव्यात काहीही बदलत नाही।
exportfs -v
showmount -e nfs.example.internalक्लायंट यादी वाचण्यापूर्वी त्या आउटपुटमधील फ्लेवर वाचा। मर्यादित दिसणारी निर्यात केवळ पत्त्याने मर्यादित असू शकते तर प्रत्येक कॉलर अजूनही हवा तो UID घोषित करतो।
मॉडेल निवडा, मग परवानग्या ठेवा
तुम्ही खरोखर व्यवस्थापित करता त्या क्लायंटसाठी योग्य असे फाइल-सेवा प्रमाणीकरण मॉडेल निवडा। Kerberos ला मागे ओळख आणि सेवा तैनाती लागते, म्हणून एक माउंट पर्याय बदलणे हे स्थलांतर नाही आणि Kerberos डोमेन, प्रिन्सिपल आणि keytab नसल्यास ते फक्त अयशस्वी होईल।
दोन्ही मॉडेलमध्ये, प्रमाणित प्रिन्सिपल काय करू शकतो हे मर्यादित करणाऱ्या निर्यात परवानग्या आणि फाइलसिस्टम अधिकृतता ठेवा। प्रमाणीकरण सांगते कोण विचारत आहे; अधिकृतता ठरवते उत्तर होय असावे का। हे दोन्ही एका सेटिंगमध्ये विलीन करणे हाच स्थलांतर जुन्या संरचनेपेक्षा जास्त अधिकार देऊन संपण्याचा मार्ग आहे।
पत्ता नियम त्याच्या खऱ्या उद्देशासाठी वापरा
सेवेला मंजूर मार्ग आणि स्रोतांपुरती मर्यादित ठेवणे अजूनही फायद्याचे आहे, VPN एंडपॉइंट आणि NFS सर्व्हर एकच मशीन सामायिक करतात तेव्हा होस्ट इनपुट धोरणासह। रहदारी पुढे पाठवणारे नियम खालीलकडे लक्ष्यित विनंत्या नियंत्रित करत नाहीत: त्याच होस्टवर स्थानिकपणे चालणारी सेवा। ही तफावत खाजगी असायला हव्या होत्या अशा आश्चर्यकारक संख्येने निर्याती स्पष्ट करते। सुरंग नियम ते झाकतात असे गृहीत धरण्याऐवजी स्थानिक इनपुट धोरण स्पष्टपणे तपासा।
दुसरे इंटरफेस किंवा स्रोत-भाषांतर करणारा गेटवे नियम अनपेक्षितपणे पूर्ण करू शकत नाही याची तपासणी करा, आणि पत्ता बनावट करणे कार्यरत माउंटची हमी देते या दाव्याऐवजी उगम स्थापित करण्याचे कारण म्हणून त्याकडे पाहा।
एकाऐवजी तीन स्वीकृती प्रकरणे चालवा। मंजूर क्लायंट मंजूर वापरकर्ता म्हणून काम करण्यापासून सुरुवात करा, मग कधीही मंजूर न झालेल्या पीअरपासून पुनरावृत्ती करा, मग मंजूर वापरकर्त्याला अजून परवानगी नसलेली गोष्ट करून पाहा। नंतर विचारा की अधिकृत क्लायंटशी तडजोड झाल्यास काय बदलते, कारण वाहतूक प्रमाणीकरण त्या मशीनवरील प्रत्येक प्रक्रियेला विश्वसनीय करत नाही। चोरी झालेले सर्टिफिकेट आणि जिज्ञासू स्थानिक खाते वेगवेगळ्या नियंत्रणांसह वेगवेगळ्या समस्या आहेत।