Комментарии 29
Как себя поведёт данное решение на других контроллерах — подсказать не смогу. Единственное из-за чего пришлось подключатся к локальной сети — это прогрузка конфигурайции контроллера при неправильной настройки сетевых параметров контроллера (не был прописан маршрутизатор KEENETIC).
А безопасники Ваши в курсе этой дыры?
Статья из серии "какой нельзя создавать архитектуру промышленной системы".
Опять 192.168.1.х в рабочих сетях. А если "192.168" привели "для примера" — поглядите в RFC. Там есть диапазоны для этого "TEST-NET" называются.
Еще один автор не знает, как использовать маршрутизацию.
Еще один костыль из стороннего несертифицированного продукта очень "обрадует" безопасников. Хотя, в конторе, где шлюз на keenetic, денег на безопасность наверняка совсем нет.
Цель написания данной статьи — это показать возможность удалённого подключения к промышленному ПЛК, т.к. в интернете вообще нет информации отчего следует отталкиваться.
Данный «костыль» произошёл как раз таки из сертифицированного промышленного маршрутизатора, который не имеет поддержки TAP-соединения и изначально схема выглядит вот так:
Windows TUN-сервер соединяется с промышленным сертифицированным маршрутизатором-клиентом (пусть будет PxC 2903588), который обслуживающий персонал по месту может включать/выключать по своему усмотрению с помощью переключателя (на маршрутизаторе имеются управляющие контакты). Далее к маршрутизатору подключается KEENETIC. Создаём второй TAP-интерфейс на Windows. И по второму интерфейсу (через KEENETIC) подключаемся к сети контроллера.
Не нужно носить розовые очки и каждому пациенту с насморком назначать томографию.
Возможно, в программировании Вы разбираетесь гораздо лучше. Но арзитектура сетей — это пока не Ваше.
Создавать большие L2-broadcast сегменты воообще так-себе решение. Тем более, "растягивать" их через интернет и удаленный доступ.
По поводу сертификации — покадите сертификаты. ФСТЭК на примененное Вами ПО OpenVPN.
Из-за таких непродуманных решений КИИ оказывается уязвимой.
За оформление статьи с иллюстрациями "5".
А за сетевую арзитектуру "троечка", увы.
А просто использовать KeenDNS нельзя?
А как же надёжность связи? Временны́е адержки из-за шифрования? Вы на столько доверяете и рекомендуете OpenVPN?
Нет, мои дорогие, так нельзя делать. Почему? Потому что в реальной жизни к удалёнке цепляются для устранения проблем, это всегда срочно, это всегда прессинг. И у тебя не будет времени пилить всю эту хрень, генерировать сертификаты, пробрасывать туннели потому что тебе нужно срочно проблему решать. Ты обычно даже не понимаешь, а жив ли контроллер, в каком он состоянии, не говоря уж о прочем. Единственный, более или менее рабочий способ в реальной жизни — кто-то на объекте цепляет любой комп, или ноут к ПЛК и ты через RDP или TeamViewer работаешь. Все то что писали выше про безопасность — конечно верно, но в реальной жизни то нет.
Siemens & keenetic, серьёзно? В реальной жизни VPN без доступа в Интернет и наоборот. Все операторы предоставляют эти услуги. Если есть деньги на S7, то и на каналы денег хватит.
кто-то на объекте цепляет любой компэто когда на объекте есть любой комп с _нужным_ комплектом инженерного ПО требуемых версий
Использую opnsense + kennetic для таких целей. Точечные ПК соединяю при помощи ovpn с привязкой адреса. Для объединения сетей ipsec. Мне так удобно)) на данный момент работает 28 ipsec и 25 vpn каналов и их количество будет расти. Очень удобно. Все в одном месте: шлюз для офиса, vpn сервер, генератор сертификатов и т.д и т.п. gui opnsense очень удобен и приятен в работе.
Руководство по организации удалённого подключения к промышленному ПЛК посредством OpenVPN