Descoperirea PLC eșuează prin VPN? Țineți Ethernetul la mașină

Butonul de descoperire se învârte la nesfârșit, nu găsește nimic, iar tichetul spune că mașina este offline. Mașina este în regulă. Ceea ce folosește instrumentul pentru a localiza dispozitive pe acel segment nu supraviețuiește căii care i-a fost dată, iar reflexul este să întindeți Ethernetul clientului peste legătura sitului ca butonul să funcționeze din nou. Stabiliți mai întâi dependența. Majoritatea instrumentelor de mentenanță au nevoie de o rută; când unul are cu adevărat nevoie de cablu, răspunsul durabil este un host administrat lângă mașină, nu o rețea punte între două clădiri.

De ce descoperirea moare la marginea unui tunel rutat

Un tunel rutat transportă pachete unicast între subrețele. Cadrele de difuzare și multicast rămân într-un singur domeniu de difuzare, iar punctul final al VPN este exact acolo unde se termină acel domeniu. Un instrument care găsește dispozitive strigând în segment primește tăcere, pentru că strigătul nu a fost niciodată transmis mai departe.

Același lucru este valabil pentru protocoale care nu sunt deloc IP, și pentru cadrele producătorului care merg direct pe Ethernet. Acelea nu pot fi rutate prin nicio configurație, de aceea adăugarea de rute și reguli de firewall la o problemă de descoperire adesea nu schimbă nimic.

Observați ce încă funcționează în acea stare. Un ping către o adresă cunoscută și o conexiune unicast la un port cunoscut reușesc de obicei, pentru că acelea sunt părțile pentru care a fost construit tunelul. Această combinație, accesibilă după adresă dar invizibilă pentru descoperire, este semnul unui domeniu de difuzare lipsă, nu al unei rețele defecte.

Numiți dependența înainte de a alege un transport

Citiți documentația instrumentului despre cum găsește dispozitivele și cum vorbește cu ele, apoi comparați cu acest tabel.

Dacă fiecare cerință din cazul dumneavoastră este în primul rând, opriți-vă aici și reparați rutarea. Este o schimbare mai ieftină și mult mai ușor de revizuit decât orice lucru de topologie, și ține sesiunea de mentenanță în calea de acces pe care clientul a aprobat-o deja.

Descoperirea multicast stă într-un mijloc incomod. Un reflector sau un repetator poate transmite o parte din ea între subrețele, ceea ce face butonul să funcționeze și lărgește în tăcere ce poate atinge partea îndepărtată. Tratați asta ca pe un design deliberat cu un proprietar, nu ca pe o casetă de bifat utilă.

Puneți un host administrat pe segment și accesați-l de la distanță

Modelul care supraviețuiește unui audit nu este strălucitor. O stație de lucru de inginerie aprobată de client este conectată la segmentul de mentenanță al mașinii, iar tehnicianul se conectează la acea stație prin canalul de acces la distanță aprobat. Instrumentul rulează acolo unde este cablul; persoana lucrează de oriunde s-ar afla.

Atunci nimic din rețeaua de acasă a tehnicianului nu devine parte din Ethernetul mașinii, și nu se creează nicio punte între două situri care nu au fost niciodată de acord să împartă un domeniu de defecțiune.

Țineți domeniul local atât de mic cât permite munca. Un VLAN de mentenanță cu un host administrat are o acoperire de difuzare limitată, un domeniu de bucle limitat și o defecțiune care rămâne în fabrică în loc să se răspândească pe o legătură WAN la trei dimineața.

Dați acelui host o sarcină, un proprietar și o urmă de audit

Numiți proprietarul, listați software-ul permis, definiți cum se aplică patch-urile și înregistrați ce utilizatori pot ajunge la el. Țineți fișierele de lucru și acreditările legate de clientul corect, pentru că un laptop de inginerie partajat care a vizitat șase situri este o problemă de frontieră a datelor care așteaptă să fie descoperită.

Apoi uitați-vă la canalele pe care oamenii le uită. Sincronizarea clipboard-ului, transferul de fișiere, discurile mapate și partajarea adaptorului mută toate datele peste frontieră, iar o sesiune de afișare la distanță nu face nimic din toate acestea gratis. Decideți explicit pentru fiecare în parte la acest loc de muncă, în loc să moșteniți ce face clientul implicit. Fereastra de modificări a clientului face și ea parte din acea decizie, întrucât accesibilitatea nu este același lucru cu permisiunea de a acționa.

În ceea ce privește cadrul de politică, documentul NIST SP 800-82r3 tratează mentenanța la distanță ca acces controlat la sistemul operațional, unde conectivitatea și consecințele asupra echipamentului sunt analizate împreună.

Analizați o extensie L2 ca pe un design propriu

Dacă cineva vrea totuși Ethernetul întins, analizați-o ca pe un proiect separat cu riscurile sale. Întrebați cum arată domeniul combinat de difuzare și de arbore de acoperire, cum se administrează adresarea între două organizații, ce se întâmplă când o parte intră în buclă și cine aprobă modificările la fiecare capăt. Un test de laborator reușit nu răspunde la niciuna dintre aceste întrebări și cu siguranță nu validează compatibilitatea dispozitivelor, debitul sau recuperarea după o defecțiune a legăturii.

Acceptați modelul cu host local dovedind trei lucruri: instrumentul efectuează operațiunea pentru care există, utilizatorul de la distanță este autorizat pentru acest loc de muncă, și sistemele refuzate rămân inaccesibile de la acel host. Apoi revocați accesul temporar la finalul convenit al lucrării și confirmați că a dispărut.

Asta lasă clientului un loc controlat pentru a efectua mentenanță locală, ceea ce este o promisiune mai mică decât o rețea unificată și mult mai ușor de ținut.