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

निजी LAN मा दुई उपकरणले कुनै पनि अपलिंक बिना सुरक्षित ट्राफिक आदानप्रदान गर्न सक्छन्। तिनीहरूले गर्न नसक्ने कुरा भनेको तिनीहरूले छानेको सुरक्षा मोडेलले अपेक्षा गर्ने सेवाहरू जन्माउनु हो। त्यसैले काम आधा छनोट र आधा सूची हो: कामसँग मिल्ने सुरक्षा छान्नुहोस्, त्यसपछि चुपचाप इन्टरनेटतिर पुग्ने सबै कुरा सूचीबद्ध गर्नुहोस्।

यो मार्गदर्शनको मान्यता यो हो कि दुवै उपकरणसँग एउटै निजी सञ्जालमा स्वीकृत ठेगानाहरू छन्। दुवै एउटै wifi मा जोडिएको तथ्यबाट पहुँचयोग्यताको अनुमान नगर्नुहोस्; जडान, रुटिङ र पहुँच नियमहरूले अझै त्यो निर्धारण गर्छन्।

सुरक्षा कामअनुसार छान्नुहोस्, बानीअनुसार होइन

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

एउटा थप TCP सेवा सर्भरले अनुमति दिएमा अधिकृत SSH फर्वार्डबाट जान सक्छ: स्थानीय श्रोतालाई कसिलो बाँध्नुहोस् र गन्तव्य स्पष्ट राख्नुहोस्, र याद राख्नुहोस् कि यसले त्यही एउटा सेवा अगाडि पठाउँछ, इथरनेट खण्ड पुनः बनाउँदैन।

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

LAN ले के छोड्नेछ भनी सूची बनाउनुहोस्

अलग बेन्चमा भर पर्नुअघि सफ्टवेयर, होस्ट पहिचान र प्रमाणहरू तयार पार्नुहोस्, वा संस्थाले समर्थन गर्ने अफलाइन वितरण प्रक्रिया प्रयोग गर्नुहोस्। डाउनलोड आदेश त्यो मेसिनका लागि स्थापना योजना होइन जसले स्रोतसम्म पुग्न सक्दैन, र आउटेजका बेला त्यो थाहा पाउनु सिक्नका लागि नराम्रो समय हो।

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

त्यसपछि बाह्य निर्भरताका लागि प्रमाणीकरण र प्रमाणीकरण मोडेल पढ्नुहोस्: दर्ता, पहिचान प्रदायक, बहु-कारक स्वीकृति, प्रमाणपत्र स्थिति प्राप्ति, समय स्रोत। यीमध्ये प्रत्येक अलग सञ्जालमा सम्भावित अवरोध हो। तिनीहरूलाई मर्मत विन्डोअघि सूचीबद्ध गर्नुहोस्, त्यसका बेला होइन, किनकि गलत क्षणमा फेला परेको निर्भरता पाँच मिनेटको कामलाई पूरै दिउँसो बनाइदिन्छ। स्वीकृत पहुँचयोग्य व्यवस्था दिनुहोस् वा अफलाइन चल्ने मोडेल छान्नुहोस्, र कहिल्यै चुपचाप जाँच बन्द नगर्नुहोस् किनकि त्यसको सेवा छैन।

पहिचान जाँचहरू जहाँ पर्नुपर्ने हो त्यहीँ राख्नुहोस्

अपेक्षित होस्ट कुञ्जी वा प्रमाणपत्रलाई तपाईं भरोसा गर्ने तयारी प्रक्रियाबाट प्रमाणित गर्नुहोस्, र प्रोटोकलले प्रमाणपत्रका समय प्रमाणित गर्ने ठाउँमा घडी सही राख्नुहोस्। उपकरणसँग स्विच साझा गर्दा त्यो उपकरण तपाईंले पुग्न खोजेको उपकरण बन्दैन, र उल्टो मान्नु ठ्याक्कै त्यही गल्ती हो जो त्यही खण्डको आक्रमणकारी तपाईंबाट गराउन चाहन्छ।

समयले योजनामा आफ्नै लाइन पाउनुपर्छ। धेरै प्रोटोकलले घडी पर्याप्त बहकिएपछि अन्यथा वैध प्रमाणहरू अस्वीकार गर्छन्, र सञ्जाल समय स्रोत नभएको Pi महिनौंसम्म चुपचाप बहकिन सक्छ, केही गुनासो गर्नुअघि।

अपलिंक साँच्चै अनुपस्थित हुँदा परीक्षण गर्नुहोस्

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

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