Ipari hálózatok hibaelhárítása Wiresharkkal: Modbus és Profinet forgalom

Miért más az ipari hálózat hibaelhárítása?

Irodai hálózaton a hibakeresés jellemzően próbálgatás: újraindítod az eszközt, lecseréled a kábelt, lefuttatsz egy szkennelést. Egy gyártósoron ezek közül több is leállást okozhat. Az ipari eszközök sokszor régiek, kevés erőforrással dolgoznak, és egy hálózati szkennelés vagy egy váratlan csomag elég ahhoz, hogy egy PLC kapcsolata megszakadjon.

Ezért az ipari hálózat hibaelhárításának egy alapszabálya van: előbb megfigyelj, aztán nyúlj hozzá. A megfigyelés eszköze a forgalom passzív rögzítése, az elemzésé a Wireshark.

1. Mielőtt bármit csinálsz

Ne futtass aktív szkennelést (Nmap, ping sweep) az ipari szegmensen. Ez az egyik leggyakoribb oka annak, hogy egy hibakeresés újabb hibát okoz
Kérj engedélyt és időablakot az üzemeltetéstől. Amit te "csak megnézésnek" látsz, annak lehet hatása a folyamatra
Tudd, mi a normális. Hibát csak ahhoz képest lehet észrevenni, hogy mi a szokásos forgalom. Ha van korábbi mérés vagy hálózati dokumentáció, az többet ér bármilyen szűrőnél
Írd le, mit láttál és mikor. A hiba gyakran időszakos, és a naplóból derül ki, hogy mihez köthető

2. Hogyan rögzítsd a forgalmat, hogy ne zavarj?

Két bevált, passzív módszer van:

SPAN (port mirroring): a menedzselhető switch az egyik port forgalmát átmásolja egy másik portra, amire a laptopod csatlakozik. Gyors és olcsó, de terhelt switchen a tükrözött forgalom egy része elveszhet
Network TAP: külön eszköz, ami fizikailag a kábel közé kerül, és hibátlanul másolja a forgalmat. Kritikus vonalakon ez a megbízhatóbb

Mindkét esetnél a rögzítő laptop csak hallgat: a tükörport felé nem küldhet adatot. Ellenőrizd, hogy a hálózati kártyád ne kapjon IP-címet és ne küldjön semmit ezen az interfészen.

3. Alap szűrők, amikkel érdemes kezdeni

Az ipari protokollok jellemző portjai:

Protokoll	Port
Modbus/TCP	502
Siemens S7	102
EtherNet/IP	44818
DNP3	20000
EtherCAT	34980 (UDP)

A Wireshark szűrők, amiket a leggyakrabban használok:

tcp.port == 502                        # minden Modbus/TCP forgalom
tcp.analysis.retransmission            # újraküldések: csomagvesztés, terhelt vonal
tcp.flags.reset == 1                   # megszakított kapcsolatok
arp.duplicate-address-detected         # IP-cím ütközés
stp                                    # spanning tree változások, hurok gyanú

Ha egy PLC és a HMI közötti kapcsolat időnként megszakad, gyakran az újraküldések és a kapcsolat-resetek arányából már látszik, hogy fizikai (kábel, csatlakozó, switch port) vagy logikai (IP-ütközés, túlterhelt eszköz) a probléma.

4. Modbus/TCP: mi a gyanús?

A Modbus a legelterjedtebb ipari protokoll, és nincs benne azonosítás: aki eléri a hálózatot, az olvashat és írhat is. Ezért a forgalmában ezeket érdemes keresni.

Írási műveletek. A 01-04-es függvénykódok olvasnak, az 5, 6, 15 és 16-os írnak. Egy rendszer, ami normálisan csak olvas, és hirtelen írási parancsot kap, gyanús:

modbus.func_code in {5 6 15 16}

Kivételválaszok. Ha az eszköz hibát jelez vissza, az a válaszban látszik. Sok kivétel egy időben rossz konfigurációra, rossz regiszterre vagy próbálkozásra utal:

modbus.exception_code

Listen only mód. Van olyan diagnosztikai függvénykód (08), amivel az eszköz "csak hallgat" módba kényszeríthető, vagyis nem válaszol többé. Ha ilyet látsz, az szinte biztosan nem szokásos működés.

Új eszköz a hálózaton. Ha egy ismeretlen IP-cím kezd beszélgetni a PLC-vel, az a leggyorsabban észrevehető eltérés. A Wiresharkban a Statistics, majd Conversations menüben látod, ki kivel kommunikál. Vesd össze a hálózati dokumentációval.

Időzítési anomáliák. A Modbus lekérdezés-válasz alapú, és a lekérdezések ütemezettek. Ha hirtelen megváltozik a lekérdezési gyakoriság, késnek a válaszok, vagy hiányoznak, az terhelést, hibás eszközt vagy illetéktelen forgalmat jelezhet.

5. Profinet: mire figyelj?

A Profinet Ethernet alapú, és a hozzá tartozó forgalom a Wiresharkban külön szűrhető. A hibakeresésnél két dolog hasznos:

pn_dcp: az eszközök felderítési és konfigurációs protokollja. Normál működés közben ritka. Ha egy eszköz nevét vagy IP-címét valaki átállítja, az itt látszik. Váratlan, sok DCP forgalom gyanús
pn_rt és pn_io: a valós idejű és az adatforgalom. Kimaradó ciklusok, vagy egy eszköz, ami hirtelen eltűnik a cserebeszélgetésből, jó támpont a hiba helyéhez

A Profinet nem tartalmaz beépített azonosítást és titkosítást, és minden Ethernet-es sérülékenységet örököl. Ezért is fontos, hogy az ipari hálózat el legyen választva az irodaitól.

6. Tipikus tünetek és a valószínű okok

Tünet	Valószínű ok
Időnként megszakad a HMI és a PLC kapcsolata	Kábel, csatlakozó vagy switch port hiba; sok újraküldés
Az egész szegmens lelassul	Broadcast vihar, hálózati hurok (STP hiba)
Egy eszköz nem érhető el, a többi rendben	IP-cím ütközés, hibás eszköz, hibás port
Sok kivételválasz Modbusnál	Rossz regiszterkiosztás vagy konfiguráció
Ismeretlen eszköz a PLC-vel beszélget	Nem dokumentált eszköz, vagy illetéktelen hozzáférés

7. Mikor érdemes szakembert hívni?

Ha a hiba időszakos és nem reprodukálható, ha az üzem leállása költséges, vagy ha nincs hálózati dokumentáció, amihez viszonyíthatsz, a hibakeresés gyorsan időigényessé válik. Ebben segít egy előre elkészített hálózati térkép és eszközlista, mert a hibaelhárítás fele az, hogy tudd, mi kivel beszél.

Az ipari hálózatok hibaelhárítása és a passzív hálózati felmérés a PeterProg egyik fő szolgáltatása Békéscsaba és Békés megye térségében.