Надеждна и прозрачна отдалечена Modbus връзка: как стабилизирахме комуникацията с PLC през VPN

Предизвикателството

Свързването на отдалечени PLC устройства към централна среда за мониторинг звучи просто: изгражда се VPN, маршрутизират се отдалечените мрежи и приложенията комуникират директно с PLC-тата. Точно такъв беше и нашият първоначален подход.

От гледна точка на класическата мрежова свързаност всичко изглеждаше наред — мрежите бяха достижими, маршрутизацията работеше, а приложенията успяваха да установят TCP връзки.

Но PLC устройствата разказваха съвсем различна история. Започнахме да наблюдаваме прекъсващи връзки и нестабилна Modbus комуникация.

Предизвикателството не беше просто мрежите да станат достижими. Предизвикателството беше комуникацията да стане надеждна за самите индустриални устройства.

Първият подход: директна WireGuard връзка

Първоначалната ни архитектура използваше директна WireGuard връзка между централната среда и отдалечените мрежи — логиката беше проста: Приложение → WireGuard → отдалечен рутер → PLC.

Това е напълно разумен подход за много мрежови сценарии. В нашата среда обаче полученото поведение на трафика причиняваше проблеми с PLC връзките.

Важното откритие беше, че проблемът не се ограничаваше до едно конкретно SCADA приложение. Засегнати бяха и други услуги, използващи Modbus TCP. Това ни показа, че не се сблъскваме с проблем, специфичен за конкретно приложение — сблъсквахме се с начина, по който Modbus връзките се пренасяха през мрежата.

Когато „мрежова свързаност“ не е достатъчна

Един от най-полезните изводи от проекта беше, че традиционните тестове за свързаност невинаги са достатъчни в индустриална среда. Можехме да проверим:

• VPN свързаност;
• маршрутизация;
• достижимост;
• установяване на TCP връзки.

И въпреки това реалната индустриална комуникация можеше да остане нестабилна. Разликата е важна: това, че една мрежова връзка е технически възможна, не означава непременно, че индустриален протокол ще се държи надеждно върху нея.

Вместо да продължаваме да променяме директната VPN архитектура, направихме крачка назад и погледнахме към инфраструктурата, която вече беше налична по обектите.

Използване на съществуващата инфраструктура

Всяка отдалечена локация вече разполагаше с MikroTik рутер, отговарящ за локалната мрежа. Вместо да заменяме тази архитектура, решихме да използваме съществуващите рутери като контролирана точка за комуникация между централната среда и мрежите на PLC устройствата.

Това ни отведе далеч от директния маршрутизиран Modbus трафик. Вместо това изградихме криптиран SSH транспорт между централната Linux инфраструктура и отдалечените рутери: централна среда → криптиран тунел → отдалечен рутер → локална TCP връзка → PLC.

Важната разлика беше, че самата връзка към PLC се инициираше от отдалечената мрежа. VPN-ът на практика пренасяше сигурната транспортна връзка, вместо да излага директно Modbus сесията през VPN.

Вторият проблем: запазване на прозрачността

Имаше и друго изискване: не искахме да пренавивайваме приложенията около новата архитектура. Съществуващите приложения вече познаваха PLC устройствата по нормалните им мрежови адреси. Промяна на всяко приложение да използва специални адреси на тунела или локални proxy портове би създала нов оперативен проблем.

Затова проектирахме решението така, че механизмът за тунелиране да е прозрачен за приложенията. Приложението продължава да комуникира с PLC чрез нормалния му адрес. Зад кулисите централният Linux firewall пренасочва тази връзка в подходящия сигурен тунел: приложение → нормален адрес на PLC → централен firewall → прозрачно пренасочване → криптиран тунел → отдалечен рутер → PLC.

Приложението не се нуждае да знае, че тунелът изобщо съществува. Това се оказа една от най-важните характеристики на крайната архитектура.

Firewall-ът стана част от решението

Firewall-ът не се използваше само за сигурност. Той се превърна в механизма, който ни позволи да разделим логическата връзка от физическия транспортен път.

От гледна точка на приложението: Приложение → PLC.

Зад кулисите: приложение → транслация от firewall-а → криптиран тунел → отдалечен рутер → PLC.

Това ни позволи да въведем новия транспортен механизъм, без да пренастроваме приложенията, използващи Modbus. Означаваше също, че различните услуги можеха да продължат да работят нормално, без да бъдат конфигурирани индивидуално за тунелите.

Важно откритие при диагностиката

По време на внедряването се сблъскахме с още един проблем. Криптираният тунел се установяваше успешно, но комуникацията с PLC все още не работеше.

Разследването ни отведе до SSH конфигурацията на отдалечения рутер: SSH forwarding беше изключен по подразбиране. След като включихме съответната функционалност за пренасочване, рутерът успя да установи необходимата връзка към PLC.

Това беше добро напомняне, че диагностиката на подобни системи изисква проверка на всеки слой поотделно: VPN → SSH → Firewall → отдалечен рутер → TCP → Modbus → PLC.

Тестването на всеки слой поотделно ни позволи да установим точно къде спираше комуникацията.

Направихме решението устойчиво

• Тунел, който работи само докато администратор го наблюдава, не е производствено решение — връзките трябваше да са постоянни и самовъзстановяващи се.
• Реализирахме тунелите като управлявани услуги с автоматично повторно свързване.
• Устойчивост срещу временни прекъсвания на интернет връзката.
• Устойчивост срещу прекъсвания на VPN и SSH сесиите.
• Устойчивост срещу рестарт на отдалечения рутер или на централния сървър.
• Резултатът: свързаност, която работи непрекъснато без ръчна намеса.

Защо не запазихме просто директния VPN

Директният VPN подход беше технически привлекателен, защото беше прост от гледна точка на маршрутизацията. Нашата цел обаче не беше да изградим най-елегантната теоретична мрежа — целта беше да осигурим стабилна индустриална комуникация.

Директният подход водеше до нестабилно поведение при PLC устройствата. Алтернативната архитектура ни позволи да:

• използваме повторно съществуващите отдалечени рутери;
• изолираме Modbus връзките;
• контролираме как връзките достигат до PLC устройствата;
• запазим приложенията непроменени;
• управляваме свързаността централно;
• възстановяваме автоматично прекъснатите тунели.

Тази комбинация направи SSH базирания подход по-подходящ за нашата конкретна среда.

Крайната архитектура

Резултантната архитектура може да се обобщи така: приложенията се свързват с нормалния адрес на PLC → централният firewall извършва прозрачно пренасочване → криптиран тунел → съществуващ рутер → PLC.

Сложността умишлено е поставена под нивото на приложението. За софтуера, използващ Modbus, PLC устройството продължава да изглежда като същото PLC.

Какво научихме

1. Индустриалните мрежи не винаги се решават с още маршрутизация.

Решение, което изглежда съвършено на мрежовата диаграма, все още може да доведе до нежелано поведение, когато в играта влязат реални индустриални устройства.

2. Успешният подход дойде от комбинация на относително прости технологии.

Криптирана свързаност, съществуващи гранични рутери, контролирано SSH пренасочване, прозрачно пренасочване от firewall-а и автоматично възстановяване на тунела.

3. Нито един от компонентите поотделно не беше особено сложен.

Инженерното предизвикателство беше да ги комбинираме така, че да решат реалния проблем, без да налагат промени върху приложенията или PLC устройствата.

4. Крайното решение не беше за скриване на сложността заради самата нея.

Беше за поставяне на тази сложност там, където може да бъде контролирана — създадохме контролиран слой за свързаност под приложенията и PLC устройствата, вместо да искаме от всяко от тях да разбира VPN архитектурата.

5. Разделянето на логическата връзка от физическия транспорт е това, което направи архитектурата достатъчно надеждна за производствена употреба.

Приложенията виждат PLC устройства. Мрежата вижда криптирани тунели. Отдалечените рутери обработват локалната връзка. А PLC устройствата виждат предвидима връзка от собствената си локална мрежа.

Имате ли нестабилна връзка с отдалечени индустриални устройства?

Ако вашата PLC или SCADA свързаност се държи непредвидимо въпреки „изправна“ мрежа, проблемът вероятно е в начина, по който протоколът се пренася — не само в маршрутизацията. Ще прегледаме архитектурата ви безплатно.

Заявете преглед на индустриалната си свързаност →