Nextcloud केवल VPN से: पहले हर प्रवेश द्वार की सूची बनाएँ

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

चेकलिस्ट को क्रम में पूरा करें। पहला मद तय करता है कि इस परिनियोजन के लिए निजी का क्या अर्थ है; बाद के मद जाँचते हैं कि परिनियोजन वास्तव में उस परिभाषा से मेल खाता है या नहीं।

परिधि बदलने से पहले निजी को परिभाषित करें

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

निजी बैकएंड पता एप्लिकेशन को निजी नहीं बनाता। अगर सार्वजनिक मैपिंग, दूसरा होस्टनाम या IPv6 श्रोता अभी भी उसी Nextcloud इंस्टेंस तक पहुँचते हैं, तो प्रवेश मौजूद है, चाहे बैकएंड कहीं भी हो। सेवा को निजी घोषित करने से पहले हर नाम को बाहर से जाँचें। गुम DNS रिकॉर्ड बंद पोर्ट के समान नहीं है।

इच्छित दर्शकों पर भी सहमति बनाएँ: कर्मचारी, एक परिवार, एक साझेदार संगठन या खातों का उपसमुच्चय। उत्तर तय करता है कि सार्वजनिक साझा लिंक विशेषता है या विरोधाभास। उस दर्शक को प्रवेश योजना में लिखें। यह आगे आने वाले हर अपवाद की कसौटी है।

हर प्रवेश द्वार और हर नाम की सूची बनाएँ

सार्वजनिक पता मैपिंग, रिवर्स प्रॉक्सी, वैकल्पिक होस्टनाम, IPv6 श्रोता और सेवा तक पहुँचने वाला कोई भी टनल या मेश पता सूचीबद्ध करें। उन नामों को भी शामिल करें जो इन पतों पर हल होते हैं, क्योंकि भूला हुआ DNS रिकॉर्ड मैत्रीपूर्ण लेबल वाला प्रवेश द्वार है।

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

फिर उन प्रवेश द्वारों को अवरुद्ध करें जिन्हें आपने नहीं चुना। सार्वजनिक फ्रंटएंड वाला निजी बैकएंड केवल VPN डिज़ाइन नहीं है, और केवल IPv4 को कवर करने वाला फ़ायरवॉल नियम IPv6 श्रोता को खुला छोड़ देता है। दोनों परिवारों और दोनों नामों को एक ही बदलाव में बंद करें।

हर क्लाइंट को एक सेवा नाम दें

निजी DNS को सेवा की ओर इंगित करें, उस नाम को VPN से होकर भेजें और उसके लिए प्रमाणपत्र जारी करें। नाम को निजी पथ से हल होना चाहिए और बिना चेतावनी के सत्यापित होना चाहिए। सीधे IP तक पहुँचने वाले क्लाइंट को भी नाम के काम करने की आवश्यकता है।

असंबंधित IP पते से जुड़ने वाले क्लाइंट को डिज़ाइन काम कराने के लिए प्रमाणपत्र त्रुटियाँ खारिज नहीं करनी चाहिए। स्थिर नाम सिंक क्लाइंट को पता बदलने पर डुप्लिकेट सर्वर प्रविष्टियाँ बनाने से भी रोकता है। निजी सेवा और निजी IP के बीच यही अंतर है।

प्रमाणपत्र सत्यापन सक्षम रखें। निजी नेटवर्क जोखिम कम करता है लेकिन बिना सत्यापित TLS कनेक्शन को स्वीकार्य नहीं बनाता, और चेतावनियों को अनदेखा करने का अभ्यस्त क्लाइंट अन्य नेटवर्क पर भी उन्हें अनदेखा करेगा।

नेटवर्क पहुँच सीमित करें, पूरा LAN नहीं

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

VPN प्रवेश Nextcloud खातों, अनुमतियों या अतिरिक्त प्रमाणीकरण का स्थान नहीं लेता। एप्लिकेशन अभी भी तय करता है कि कौन उपयोगकर्ता कौन सी फ़ाइल पढ़ सकता है, और नेटवर्क परत एकमात्र नियंत्रण नहीं होनी चाहिए।

स्वीकृत स्रोत श्रेणी और सेवा पोर्ट दर्ज करें। लक्ष्य के स्वामी को देखा गया स्रोत चाहिए, और अनुरोध एप्लिकेशन तक पहुँचने से पहले NAT या प्रॉक्सी उसे फिर से लिख सकते हैं।

ब्राउज़र के बाहर के हर कार्यप्रवाह की समीक्षा करें

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

WebDAV उपकरण और कैलेंडर या संपर्क क्लाइंट अपने कॉन्फ़िगरेशन वाले अलग एकीकरण हैं। सार्वजनिक URL कैश करने वाला क्लाइंट परिधि बदलने के बाद भी उसी URL का प्रयास करता रहता है, और विफलता एप्लिकेशन समस्या जैसी दिखती है।

साझा लिंक स्पष्ट निर्णय के योग्य हैं। लिंक अपने प्राप्तकर्ता को VPN प्रवेश नहीं देता, इसलिए वास्तव में केवल VPN डिज़ाइन में बाहरी प्राप्तकर्ता लिंक वैध होने पर भी उसका उपयोग नहीं कर सकता। यदि बाहर साझा करना आवश्यक है, तो वह अपने स्वयं के प्रवेश पथ वाला जानबूझकर किया गया अपवाद है, बाद में मिलने वाली चूक नहीं।

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

स्वीकृत और अस्वीकृत दोनों स्थितियाँ स्वीकारें

स्वीकृत क्लाइंट से वेब इंटरफ़ेस और सामान्य फ़ाइल अपलोड या डाउनलोड जाँचें। फिर सिंक क्लाइंट और ब्राउज़र के बाहर एक कार्यप्रवाह जाँचें। केवल ब्राउज़र में सफलता स्वीकृति नहीं है।

अस्वीकृत पथ से पुष्टि करें कि एप्लिकेशन सूची के हर प्रवेश द्वार से अगम्य है। वैकल्पिक होस्टनाम और IPv6 पता जाँचें, केवल प्राथमिक URL नहीं।

अंत में एप्लिकेशन की उन सेटिंग्स की समीक्षा करें जिन्हें नेटवर्क नीति से आसानी से भ्रमित किया जा सकता है। trusted_domains उन नामों की सूची देता है जिन्हें इंस्टेंस स्वीकार करता है; यह क्लाइंट IP की अनुमति सूची नहीं है। यदि रिवर्स प्रॉक्सी पता जानकारी प्रदान करता है, trusted_proxies को वास्तविक प्रॉक्सी का नाम देना चाहिए, और अग्रेषित हेडर केवल उसी से स्वीकार किए जाने चाहिए।

नेटवर्क बदलाव के साथ-साथ सामान्य सख़्तीकरण का काम जारी रखें: डेटा और बैकअप को अनजाने वेब पथों से बाहर रखें, एप्लिकेशन को पैच करें, प्रशासक पहुँच की रक्षा करें और रिकवरी को उपयोगी रखें। VPN एक प्रवेश सतह हटाता है; यह पंजीकृत क्लाइंट को भरोसेमंद नहीं बनाता।