VPN वरून PLC शोध अयशस्वी? Ethernet मशीनजवळ ठेवा
देखभाल साधनांना मार्ग हवा, ब्रिज केलेला Ethernet विभाग नाही। विभागावर व्यवस्थापित होस्ट ठेवा आणि LAN खेचण्याऐवजी त्या होस्टवर नियंत्रण ठेवा।
तुमचे शोध बटण अंतहीन फिरते, काहीच सापडत नाही, आणि तिकिटात मशीन ऑफलाइन असल्याचे म्हटले आहे। मशीन ठीक आहे। त्या विभागात उपकरणे शोधण्यासाठी साधन जे वापरते ते त्याला दिलेल्या मार्गातून जात नाही, आणि बटण पुन्हा काम करावे म्हणून ग्राहकाचे Ethernet साइट लिंकवरून खेचणे ही सहज प्रतिक्रिया आहे। आधी अवलंबित्व ठरवा। बहुतेक देखभाल साधनांना मार्ग हवा; जेव्हा एखाद्याला खरोखर केबल हवी असते, तेव्हा टिकाऊ उत्तर दोन इमारतींमधील ब्रिज केलेले नेटवर्क नसून मशीनजवळ ठेवलेला व्यवस्थापित होस्ट आहे।
राउटेड टनेलच्या काठावर शोध का मरतो
राउटेड टनेल सबनेटमध्ये unicast पॅकेट नेते। ब्रॉडकास्ट आणि multicast फ्रेम एकाच ब्रॉडकास्ट डोमेनमध्ये राहतात, आणि VPN एंडपॉइंट तिथेच असतो जिथे तो डोमेन संपतो। विभागात ओरडून उपकरणे शोधणाऱ्या साधनाला शांतता मिळते, कारण ती ओरड कधीच पुढे पाठवली गेली नाही।
हेच अशा प्रोटोकॉलना लागू होते जे अजिबात IP नाहीत, आणि Ethernet वर थेट चालणाऱ्या उत्पादकाच्या फ्रेमना देखील। त्या कोणत्याही कॉन्फिगरेशनने राउट करता येत नाहीत, म्हणून शोध समस्येला मार्ग आणि फायरवॉल नियम जोडल्याने बरेचदा काहीच बदलत नाही।
त्या स्थितीत अजून काय चालते ते पहा। ज्ञात पत्त्यावर ping आणि ज्ञात पोर्टवर unicast कनेक्शन सहसा यशस्वी होतात, कारण टनेल त्यांच्यासाठी बांधले गेले होते। पत्त्याने पोहोचण्यायोग्य पण शोधासाठी अदृश्य असलेले हे संयोजन तुटलेल्या नेटवर्कचे नाही, तर गहाळ ब्रॉडकास्ट डोमेनचे लक्षण आहे।
ट्रान्सपोर्ट निवडण्यापूर्वी अवलंबित्वाचे नाव द्या
साधन उपकरणे कशी शोधते आणि त्यांच्याशी कसे बोलते याबद्दल त्याचे दस्तऐवज वाचा, नंतर त्याची या तक्त्याशी तुलना करा।
| What the tool needs | Routed tunnel enough | Local segment needed |
|---|---|---|
| Unicast to a known address, such as a web interface or Modbus TCP on 502 | Yes | No |
| Broadcast or multicast discovery of unknown devices | No | Yes |
| Non-IP or vendor-specific Layer 2 frames | No | Yes |
| A tool bound to one adapter or licence keyed to a MAC address | Usually no | Usually yes |
तुमच्या प्रकरणातील प्रत्येक आवश्यकता पहिल्या रांगेत असल्यास, इथे थांबा आणि राउटिंग दुरुस्त करा। हा कोणत्याही टोपोलॉजी कामापेक्षा स्वस्त आणि खूप सोप्या पद्धतीने पुनरावलोकन करण्यायोग्य बदल आहे, आणि देखभाल सत्र ग्राहकाने आधीच मंजूर केलेल्या प्रवेश मार्गात ठेवतो।
Multicast शोध अस्वस्थ मध्यभागी बसतो। परावर्तक किंवा पुनरावर्तक त्याचा काही भाग सबनेटवरून पुढे पाठवू शकतो, ज्यामुळे बटण चालते आणि दूरची बाजू कुठवर पोहोचू शकते हे शांतपणे वाढते। याला मालक असलेली जाणीवपूर्वक रचना माना, उपयुक्त चेकबॉक्स नाही।
विभागावर व्यवस्थापित होस्ट ठेवा आणि त्यावर रिमोट व्हा
ऑडिट टिकवणारी पद्धत तेजस्वी नाही। ग्राहकाने मंजूर केलेले अभियांत्रिकी कार्यस्थान मशीनच्या देखभाल विभागाला जोडलेले असते, आणि तंत्रज्ञ मंजूर रिमोट-प्रवेश चॅनेलद्वारे त्या कार्यस्थानाशी जोडतो। साधन तिथे चालते जिथे केबल आहे; व्यक्ती जिथे आहे तिथून चालते।
मग तंत्रज्ञाच्या घरातील नेटवर्कचे काहीही मशीनच्या Ethernetचा भाग होत नाही, आणि ज्या दोन साइटींनी कधीही अपयश डोमेन सामायिक करण्यास संमती दिली नाही त्यांच्यामध्ये ब्रिज तयार होत नाही।
काम परवानगी देईल तितका स्थानिक डोमेन लहान ठेवा। एका व्यवस्थापित होस्टसह एका देखभाल VLANची ब्रॉडकास्ट व्याप्ती मर्यादित, लूप डोमेन मर्यादित आणि अपयश रात्री तीन वाजता WAN लिंकवर पसरण्याऐवजी कारखान्यातच राहते।
त्या होस्टला एक काम, एक मालक आणि एक ऑडिट ट्रेल द्या
मालकाचे नाव द्या, अनुमत सॉफ्टवेअरची यादी करा, ते कसे पॅच होते ते ठरवा आणि कोणते वापरकर्ते त्याला पोहोचू शकतात ते नोंदवा। कामाच्या फायली आणि क्रेडेन्शियल्स योग्य ग्राहकाशी बांधलेले ठेवा, कारण सहा साइटींना भेट दिलेला सामायिक अभियांत्रिकी लॅपटॉप ही शोधली जाण्याची वाट पाहणारी डेटा सीमा समस्या आहे।
नंतर लोक विसरतात त्या चॅनेलकडे पहा। क्लिपबोर्ड सिंक, फाइल हस्तांतरण, मॅप केलेले ड्राइव्ह आणि अडॅप्टर शेअरिंग सर्व सीमेपलीकडे डेटा हलवतात, आणि रिमोट डिस्प्ले सत्र त्यातील काहीही मोफत करत नाही। क्लायंटचे डीफॉल्ट वारसा घेण्याऐवजी या कामासाठी प्रत्येकावर स्पष्टपणे निर्णय घ्या। ग्राहकाची बदल विंडो देखील त्या निर्णयाचा भाग आहे, कारण पोहोचण्याची क्षमता कृतीच्या परवानगीसारखी नाही।
धोरण चौकटीबद्दल, NISTचा दस्तऐवज SP 800-82r3 दूरस्थ देखभालीकडे ऑपरेशनल सिस्टममधील नियंत्रित प्रवेश म्हणून पाहतो, जिथे कनेक्टिव्हिटी आणि उपकरणांचे परिणाम एकत्र तपासले जातात।
L2 विस्ताराचे त्याच्या स्वतःच्या रचने म्हणून पुनरावलोकन करा
जर कोणाला अजूनही Ethernet खेचायचे असेल, तर त्याचे स्वतःच्या जोखमींसह वेगळ्या प्रकल्प म्हणून पुनरावलोकन करा। एकत्रित ब्रॉडकास्ट आणि स्पॅनिंग-ट्री डोमेन कसा दिसतो, दोन संस्थांमध्ये पत्ता नियुक्ती कशी व्यवस्थापित होते, एका बाजूला लूप झाल्यास काय होते, आणि प्रत्येक टोकाला बदल कोण मंजूर करतो हे विचारा। यशस्वी प्रयोगशाळा चाचणी या प्रश्नांपैकी कोणत्याही उत्तर देत नाही, आणि उपकरण सुसंगतता, थ्रूपुट किंवा लिंक अयशस्वीनंतरची पुनर्प्राप्ती यांची खात्रीने पडताळणी करत नाही।
स्थानिक-होस्ट पद्धत तीन गोष्टी सिद्ध करून स्वीकारा: साधन ज्या कामासाठी अस्तित्वात आहे ते करते, दूरस्थ वापरकर्ता या कामासाठी अधिकृत आहे, आणि नाकारलेल्या प्रणाली त्या होस्टवरून अपोहोच्य राहतात। नंतर कामाच्या ठरलेल्या शेवटी तात्पुरता प्रवेश रद्द करा, आणि तो गेल्याची खात्री करा।
यामुळे ग्राहकाकडे स्थानिक देखभाल करण्यासाठी नियंत्रित जागा राहते, जे एकत्रित नेटवर्कपेक्षा लहान वचन आहे आणि पाळणे खूप सोपे आहे।