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 നീട്ടാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, അതിനെ സ്വന്തം അപകടസാധ്യതകളുള്ള പ്രത്യേക പ്രോജക്റ്റായി പരിശോധിക്കുക. സംയോജിത ബ്രോഡ്കാസ്റ്റ്, സ്പാനിംഗ്-ട്രീ ഡൊമെയ്ൻ എങ്ങനെയിരിക്കും, രണ്ട് സംഘടനകൾക്കിടയിൽ വിലാസനിർണ്ണയം എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു, ഒരു വശത്ത് ലൂപ്പ് സംഭവിച്ചാൽ എന്ത് സംഭവിക്കും, ഓരോ അറ്റത്തും മാറ്റങ്ങൾ ആര് അംഗീകരിക്കും എന്ന് ചോദിക്കുക. വിജയകരമായ ലാബ് പരിശോധന ആ ചോദ്യങ്ങളൊന്നിനും ഉത്തരം നൽകുന്നില്ല, ഉപകരണ അനുകൂലത, ത്രൂപുട്ട്, അല്ലെങ്കിൽ ലിങ്ക് പരാജയത്തിനുശേഷമുള്ള വീണ്ടെടുക്കൽ എന്നിവ ഉറപ്പായും സാധൂകരിക്കുന്നില്ല.
പ്രാദേശിക-ഹോസ്റ്റ് മാതൃക സ്വീകരിക്കാൻ മൂന്ന് കാര്യങ്ങൾ തെളിയിക്കുക: ടൂൾ അതിനുവേണ്ടി നിലനിൽക്കുന്ന പ്രവർത്തനം ചെയ്യുന്നു, റിമോട്ട് ഉപയോക്താവ് ഈ ജോലിക്ക് അധികാരമുള്ളവനാണ്, നിരസിക്കപ്പെട്ട സിസ്റ്റങ്ങൾ ആ ഹോസ്റ്റിൽനിന്ന് എത്താനാകാത്തതായി തുടരുന്നു. തുടർന്ന് ജോലിയുടെ സമ്മതിച്ച അവസാനത്തിൽ താൽക്കാലിക ആക്സസ് റദ്ദാക്കി അത് പോയെന്ന് ഉറപ്പാക്കുക.
ഇത് ഉപഭോക്താവിന് പ്രാദേശിക അറ്റകുറ്റപ്പണി ചെയ്യാൻ ഒരു നിയന്ത്രിത സ്ഥലം വിടുന്നു, അത് ഏകീകൃത നെറ്റ്വർക്കിനെക്കാൾ ചെറിയ വാഗ്ദാനവും പാലിക്കാൻ വളരെ എളുപ്പവുമാണ്.