इंटरनेट लिंक के बिना LAN पर Raspberry Pi का प्रशासन

निजी LAN पर दो डिवाइस बिना किसी अपलिंक के सुरक्षित ट्रैफ़िक का आदान-प्रदान कर सकते हैं। जो वे नहीं कर सकते वह है उन सेवाओं को ज़ाहिर करना जिनकी अपेक्षा उनका चुना हुआ सुरक्षा मॉडल करता है। इसलिए काम आधा चुनाव और आधा सूची है: कार्य के अनुरूप सुरक्षा चुनें, फिर वह सब सूचीबद्ध करें जो चुपचाप इंटरनेट की ओर बढ़ता।

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

सुरक्षा कार्य के अनुसार चुनें, आदत के अनुसार नहीं

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

एक अतिरिक्त TCP सेवा अधिकृत SSH फ़ॉरवर्ड से तब जा सकती है जब सर्वर अनुमति दे: स्थानीय श्रोता को कसकर बाँधें और गंतव्य को स्पष्ट रखें, और याद रखें कि यह उस एक सेवा को आगे भेजता है, ईथरनेट खंड को फिर से नहीं बनाता।

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

सूची बनाएँ कि LAN क्या छोड़ेगा

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

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

फिर बाहरी निर्भरताओं के लिए प्रमाणीकरण और सत्यापन मॉडल पढ़ें: नामांकन, पहचान प्रदाता, बहु-कारक अनुमोदन, प्रमाणपत्र स्थिति प्राप्ति, समय स्रोत। इनमें से प्रत्येक आइसोलेटेड नेटवर्क पर संभावित बाधा है। उन्हें रखरखाव विंडो से पहले सूचीबद्ध करें, उसके दौरान नहीं, क्योंकि गलत क्षण में पता चली निर्भरता पाँच मिनट के काम को पूरी दोपहर बना देती है। स्वीकृत पहुँच-योग्य व्यवस्था दें या ऐसा मॉडल चुनें जो ऑफ़लाइन काम करे, और कभी चुपचाप कोई जाँच इसलिए बंद न करें कि उसकी सेवा गायब है।

पहचान जाँचें वहीं रखें जहाँ वे होनी चाहिए

अपेक्षित होस्ट कुंजी या प्रमाणपत्र को उस प्रावधान प्रक्रिया से सत्यापित करें जिस पर आप भरोसा करते हैं, और घड़ी को वहाँ सही रखें जहाँ प्रोटोकॉल प्रमाणपत्र समयों को मान्य करता है। किसी डिवाइस के साथ स्विच साझा करना उस डिवाइस को वह नहीं बनाता जिस तक आप पहुँचना चाहते थे, और उल्टा मानना ठीक वही गलती है जो उसी खंड पर बैठा हमलावर आपसे करवाना चाहेगा।

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

अपलिंक वास्तव में अनुपस्थित होने पर परखें

अपलिंक हटाएँ, फिर ठीक वही रखरखाव कार्य करें जिसके लिए आपने रचना की: टर्मिनल सत्र, फ़ाइल की प्रतिलिपि, फ़ॉरवर्ड की गई सेवा, रूटेड कनेक्शन। पुष्टि करें कि अस्वीकृत पहचान या निषिद्ध संसाधन अब भी अस्वीकृत हैं, क्योंकि केवल सुखद मार्ग प्रमाणित करने वाली रचना की कोई परीक्षा ही नहीं हुई। ऐसा करते समय लॉग पढ़ें, क्योंकि दिलचस्प विफलताएँ वही हैं जो परिणाम बदले बिना निशान छोड़ती हैं।

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