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 ખેંચવા માંગે છે, તો તેને પોતાના જોખમો સાથે અલગ પ્રોજેક્ટ તરીકે સમીક્ષા કરો. પૂછો કે સંયુક્ત બ્રોડકાસ્ટ અને સ્પેનિંગ-ટ્રી ડોમેન કેવું દેખાય છે, બે સંસ્થાઓ વચ્ચે સરનામાંકન કેવી રીતે સંભાળવામાં આવે છે, એક બાજુ લૂપ થાય ત્યારે શું થાય છે, અને દરેક છેડે ફેરફારો કોણ મંજૂર કરે છે. સફળ લેબ પરીક્ષણ એમાંના કોઈ પણ પ્રશ્નનો જવાબ આપતું નથી, અને તે ઉપકરણ સુસંગતતા, થ્રુપુટ કે લિંક નિષ્ફળતા પછીની પુનઃપ્રાપ્તિની ચોક્કસપણે ચકાસણી કરતું નથી.
સ્થાનિક-હોસ્ટ પેટર્ન સ્વીકારો ત્રણ વસ્તુઓ સાબિત કરીને: સાધન જે કામ માટે અસ્તિત્વમાં છે તે કરે છે, રિમોટ વપરાશકર્તા આ કામ માટે અધિકૃત છે, અને નકારાયેલી સિસ્ટમો તે હોસ્ટથી અપહોંચ રહે છે. પછી કામના સંમત અંતે કામચલાઉ ઍક્સેસ રદ કરો, અને તે ગઈ છે તેની ખાતરી કરો.
એ ગ્રાહકને સ્થાનિક જાળવણી કરવા માટે નિયંત્રિત સ્થળ છોડે છે, જે એકીકૃત નેટવર્ક કરતાં નાનું વચન છે અને રાખવા માટે ઘણું સરળ છે.