VPN के ज़रिए NAS प्रशासन: नाम रखें, सार्वजनिक पोर्ट छोड़ें
प्रशासन पेज तक टनल से पहुँचें, किसी नए सार्वजनिक पोर्ट से नहीं। असली नाम हल करें, उससे प्रमाणपत्र मिलाएँ और एक स्रोत से एक ही सेवा की अनुमति दें।
NAS प्रशासन पेज घर पर काम करता है और जिस पल प्रशासक यात्रा पर जाता है काम करना बंद कर देता है, इसलिए कोई पोर्ट खोल देता है और समस्या निजता के साथ ही गायब हो जाती है। इसका एक बेहतर स्वरूप है। पेज को वहीं रहने दें, टनल को पहुँच प्रदान करने दें, और जो आप दस्तावेज़ित करते हैं उसे नामित अनुमति-पथ वाला पूरा URL बनाएँ, न कि कोई ऐसा डिवाइस पता जो संयोग से उत्तर देता हो। नीचे का हर निर्णय, नाम से प्रमाणपत्र और एकमात्र अनुमत पोर्ट तक, इसे इस तरह लिखने से ही निकलता है।
डिज़ाइन की इकाई URL है, पता नहीं
प्रवेश को उसके पोर्ट और स्कीम के साथ पूरा URL लिखें, फिर शर्तें जोड़ें: कौन इसका उपयोग कर सकता है, किस नेटवर्क से और किस पथ से। उदाहरण https://nas.corp.example:8443 हो सकता है जो केवल अनुमोदित निजी क्लाइंट के लिए प्रकाशित होता है, जहाँ नाम और पोर्ट उस चीज़ का प्रतिनिधित्व करते हैं जिस पर डिवाइस वास्तव में सुनता है।
यह ढाँचा निर्णयों को जल्दी थोप देता है। URL नाम का संकेत देता है, नाम प्रमाणपत्र का संकेत देता है, और प्रमाणपत्र विश्वास-व्यवस्था का संकेत देता है। पता इनमें से कुछ भी नहीं बताता, और इसी कारण केवल-पता वाला संस्करण पहली ब्राउज़र चेतावनी तक टिकता है और फिर उसे क्लिक करके आगे बढ़ने की आदत बन जाता है।
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
वह नाम रखें जिसके लिए प्रमाणपत्र जारी हुआ था
क्लाइंट को NAS के निजी पते तक अनुमत मार्ग चाहिए, और एक निजी DNS व्यवस्था इच्छित होस्टनाम को उस पते पर हल कर सकती है और साथ ही वह नाम बनाए रख सकती है जिसकी HTTPS सेवा अपेक्षा करती है। दोनों आधे महत्वपूर्ण हैं: मार्ग पैकेट वहाँ पहुँचाता है, नाम क्लाइंट को बताता है कि कौन-सी पहचान सत्यापित करनी है।
इसके बजाय संख्यात्मक पता लिखना पहचान की आवश्यकता बदल देता है। RFC 9525 उस नाम को जिससे क्लाइंट संपर्क करना चाहता है, उस पहचान से अलग करता है जो सेवा प्रस्तुत करती है, इसलिए nas.corp.example के लिए जारी प्रमाणपत्र वैध रूप से विफल हो सकता है जब ब्राउज़र 10.20.0.15 की ओर इंगित हो। चेतावनी सही है, और समाधान नाम है, कोई अपवाद नहीं।
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleटनल को दोष देने से पहले दोनों चलाएँ। पहला दिखाता है कि निजी नाम वहाँ हल होता है या नहीं जहाँ आप सोचते हैं, और दूसरा दिखाता है कि सेवा वास्तव में कौन-सा प्रमाणपत्र और कौन-से वैकल्पिक विषय-नाम प्रस्तुत करती है। एक निजी CA पूरी तरह सुव्यवस्थित विकल्प हो सकता है; आदत नहीं बननी चाहिए लोगों को पहचान-चेतावनियों को नज़रअंदाज़ करना सिखाना।
प्रबंधन पथ को सीमित करें
गेटवे और NAS दोनों पर, इच्छित स्रोत से ठीक प्रबंधन सेवा की अनुमति दें। वह वाक्य एक ऐसा विवरण छिपाता है जो काटता है: राउटेड क्लाइंट पूल और स्रोत-अनुवादित गेटवे अलग-अलग स्रोत पतों के साथ NAS पर पहुँचते हैं, इसलिए एक के लिए लिखा अनुमति-नियम दूसरे के लिए चुपचाप विफल हो जाता है।
NAS को वापसी पथ भी चाहिए, और ब्राउज़र को फ़ोरम पोस्ट से मिले विक्रेता डिफ़ॉल्ट के बजाय कॉन्फ़िगर किया गया पोर्ट और स्कीम उपयोग करना होगा। डिवाइस तक पहुँचना उसके हर पोर्ट तक पहुँचने की अनुमति नहीं है। पिंग का उत्तर देने वाले डिवाइस और लोड होने वाले प्रशासन पेज के बीच का अंतर दो अलग नियमों के बीच का अंतर है। उन्हें दो टिप्पणियों के साथ दो नियमों के रूप में लिखें, ताकि अगला व्यक्ति देख सके कि दोनों क्यों हैं।
VPN प्रवेश को NAS विशेषाधिकार से अलग रखें
टनल से गुज़रने दिया जाना डिवाइस का प्रशासन करने की अनुमति होने के बराबर नहीं है। जिस उपयोगकर्ता को वैध रूप से फ़ाइल भंडारण चाहिए, उसे केवल इसलिए डिवाइस प्रशासन विरासत में नहीं मिलना चाहिए कि दोनों एक ही गेटवे के पीछे रहते हैं, और NAS का खाता मॉडल वह जगह है जहाँ यह अलगाव लागू होना चाहिए।
साझा या अनुवादित निकास पता भी किसी व्यक्तिगत प्रशासक की पहचान नहीं कर सकता। यदि ऑडिट ट्रेल को किसी व्यक्ति का नाम लेना है, तो पहचान प्रमाणित खाते से आनी चाहिए, ऐसी टनल के स्रोत पते से नहीं जिसका बहुत से लोग उपयोग करते हैं।
क्या गलती से प्रकाशित न करें
सार्वजनिक रिवर्स प्रॉक्सी और विक्रेता रिले दोनों वास्तविक आर्किटेक्चर हैं, और हर एक अपने विश्वास और एक्सपोज़र के निर्णय लेकर आता है। प्रशासक के घर से दूर होने के कारण कोई भी आवश्यक नहीं होता, और मीडिया सर्वर या फ़ाइल साझा करने को उजागर करने के दुष्प्रभाव के रूप में भी कोई नहीं दिखना चाहिए।
चार चीज़ें दस्तावेज़ करें और रुकें: निजी नाम, वह लिसनर जिस पर यह मैप होता है, वह समूह जिसे इसका उपयोग करने की अनुमति है, और टनल उपलब्ध न हो तो पुनर्प्राप्ति का पथ। ये चार उन सवालों का भी उत्तर देते हैं जो किसी घटना की समीक्षा पूछेगी, जो पोर्ट-फ़ॉरवर्डिंग पेज के स्क्रीनशॉट के बारे में सच नहीं है। अंत में आपके पास एक स्थिर प्रशासनिक प्रवेश बिंदु होता है, ऐसा डिवाइस नहीं जिसकी हर सुविधा इंटरनेट की ओर हो।