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 तान्न चाहन्छ भने, यसलाई आफ्नै जोखिम भएको छुट्टै परियोजनाको रूपमा समीक्षा गर्नुहोस्। संयुक्त ब्रोडकास्ट र स्प्यानिङ-ट्री डोमेन कस्तो देखिन्छ, दुई संस्थाबीच ठेगाना व्यवस्थापन कसरी हुन्छ, एक पक्षमा लुप पर्यो भने के हुन्छ, र प्रत्येक छेउमा परिवर्तन कसले स्वीकृत गर्छ भनी सोध्नुहोस्। सफल प्रयोगशाला परीक्षणले तीमध्ये कुनै प्रश्नको जवाफ दिँदैन, र यसले उपकरण अनुकूलता, थ्रुपुट वा लिंक असफलतापछिको पुनःप्राप्ति पक्कै प्रमाणित गर्दैन।
स्थानीय-होस्ट ढाँचा तीन कुरा प्रमाणित गरेर स्वीकार गर्नुहोस्: उपकरणले जुन कामका लागि अवस्थित छ त्यो गर्छ, टाढाको प्रयोगकर्ता यो कामका लागि अधिकृत छ, र अस्वीकृत प्रणालीहरू त्यो होस्टबाट अपहुँच रहन्छन्। त्यसपछि कामको सहमत अन्त्यमा अस्थायी पहुँच रद्द गर्नुहोस्, र त्यो गएको पुष्टि गर्नुहोस्।
यसले ग्राहकसँग स्थानीय मर्मत गर्न नियन्त्रित ठाउँ छोड्छ, जुन एकीकृत नेटवर्कभन्दा सानो वाचा हो र पालना गर्न धेरै सजिलो छ।