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 सर्भरले एउटै मेसिन साझा गर्दा होस्ट इनपुट नीतिसमेत। ट्राफिक अगाडि पठाउने नियमहरूले तलका तर्फ लक्षित अनुरोधहरू नियन्त्रण गर्दैनन्: एउटै होस्टमा स्थानीय रूपमा चलिरहेको सेवा। यो अन्तरले निजी हुनुपर्ने अचम्मलाग्दो संख्याका निर्यातहरू व्याख्या गर्छ। सुरुङ नियमहरूले यसलाई ढाक्छन् भनी मान्नुभन्दा स्थानीय इनपुट नीति स्पष्ट रूपमा जाँच्नुहोस्।
अर्को इन्टरफेस वा स्रोत-अनुवाद गर्ने गेटवेले नियम अप्रत्याशित रूपमा पूरा गर्न नसक्ने जाँच्नुहोस्, र यसलाई ठेगाना जाली बनाउँदा काम गर्ने माउन्टको ग्यारेन्टी हुन्छ भन्ने दाबी नभई उत्पत्ति स्थापित गर्ने कारण मान्नुहोस्।
एउटाको सट्टा तीन स्वीकृति केसहरू चलाउनुहोस्। स्वीकृत ग्राहकले स्वीकृत प्रयोगकर्ताका रूपमा काम गरेको अवस्थाबाट सुरु गर्नुहोस्, त्यसपछि कहिल्यै स्वीकृत नभएको सहकर्मीबाट दोहोर्याउनुहोस्, त्यसपछि स्वीकृत प्रयोगकर्तालाई अझै अनुमति नभएको कुरा प्रयास गर्नुहोस्। त्यसपछि सोध्नुहोस् कि अधिकृत ग्राहक सम्झौता भएमा के बदलिन्छ, किनकि यातायात प्रमाणीकरणले त्यो मेसिनका प्रत्येक प्रक्रियालाई विश्वसनीय बनाउँदैन। चोरी भएको प्रमाणपत्र र जिज्ञासु स्थानीय खाता फरक नियन्त्रण भएका फरक समस्याहरू हुन्।