Введение.
Несколько десятков лет назад я мечтал о том, чтобы не отрывая задницу от стула, можно было подключиться к контроллеру промониторить что-то, а не идти в шумный, вонючий и пыльный цех по каждой мелочи. Или даже из дома, лёжа на диване не дёргаться когда звонят по пустякам. И да, до 2019 года на предприятии не существовало однотипной, отказоустойчивой, доверительной и конфиденциальной системы обмена информации c производственным сегментом. Определения эти и другие встречающиеся в тексте в трактовке нормативных документов по ИБ (информационная безопасность), если не указано иное. Создание такой системы в принципе было затруднительно из-за того, что локальные сети разных производственных линий очень часто имели одни и те же IP сетей. Наиболее часто встречалась сеть 192.168.1.1/24 потому что данная сеть применяется по умолчанию в контроллерах Simatic и производитель оборудования не удосужился её изменить или подразумевался коммерческий смысл. Так, за работы по изменению IP адресов 4-х хостов в сети 192.168.1.1/24, удалённо (!), на какую-либо другую сеть европейская фирма запросила 1730 швейцарских франков без НДС (!). Коммерческий смысл подразумевали также программы написанные одним из бывших сотрудников предприятия.
Сеть в целом должна быть маршрутизируемой, нельзя использовать NAT (Network Address Translation) потому что не все программные продукты (протоколы) корректно работают через NAT. Самое главное через NAT корректно не работает Step 7 и TIA Portal. Соответственно была проведена большая работа по исключению дублирования сетей. Цель: у каждой производственной линии своя отдельная сеть. В настоящее время это целевое требование удовлетворяется на 96 %. Эту цель нужно “держать в голове”, не сваливаться к хаосу и стремиться к ней.
Дальше, нельзя разные сети просто взять и объединить при помощи коммутатора. Кто-то скажет: “Я так делал и всё работало”. Не буду спорить, до определённого момента развития действительно всё будет работать, потому что коммутатору всё равно какие IP коммутировать. Этот самый момент настанет тогда, когда количество коммутаторов последовательно соединённых превысит 5..6, после чего пропускная способность сети будет снижаться. Принципиально неважно что представляют из себя эти коммутаторы, будь это встроенный в частотный преобразователь Siemens двухпортовый коммутатор или навороченный промышленный Cisco ie3000. Снижение производительности определяется в первую очередь особенностями протокола IP, для которого топология сети типа “звезда” является нативной, а топология “шина” нет, и лишь отчасти снижение производительности зависит от производительности процессора внутри коммутатора. Теоретический предел, при котором пропускная способность сети снизиться до ноля, при неограниченной производительности процессоров внутри коммутаторов, 17 коммутаторов подряд. На практика это случалось уже даже при 11. Чтобы это не произошло нужно принимать специальные меры. Лучше стремиться к тому, чтобы самая длинная цепочка внутри отдельной сети производственной линии была меньше шести.
Таким образом построить большую территориально распределённую “плоскую” IP сеть невозможно. Сеть должна быть иерархической, маршрутизируемой, контролируемой. Строительством сетей передачи данных должны заниматься профессионалы и слава Богу на предприятии такие в отделе информационных технологий есть.
Специфические требования к информационному обмену с АСУТП производственных линий.
Совещаний на тему информационного обмена с АСУТП производственных линий было немало, требования выдвигались иной раз противоречивые, иногда с недосказанным обоснованием, надеюсь ничего не забыл:
Требования АСУТП:
- ИТ-шники не должны лезть к системам АСУТП (это главное), мало ли что "прилетит" от них
- у линейных инженеров АСУТП должна быть возможность подключившись с ноутбука к контроллеру наблюдать за технологическим процессом в любой точке, закреплённой за линейным инженером производственной линии, это нужно для выяснения причин в случае сбоев в работе линии
- должна быть возможность предоставления внешнего доступа к сети АСУТП, но только конкретному представителю производителя оборудования, для подключения к конкретной производственной линии и в заранее определённом временном окне, потому что своих компетенций не всегда хватает. Событие подключения и событие отключения должны регистрироваться.
- поскольку в АСУТП нет специалистов ни по сетям передачи данных, ни по серверным операционным системам, ни по серверному аппаратному обеспечению, всё это должно быть в зоне хозяйственной ответственности ИТ
- ИТ должно предоставить линейным специалистам АСУТП автономные лицензии антивируса для их рабочих ноутбуков, потому что это надо
Требования ИТ:
- данные с систем АСУТП должны размещаться конфиденциальным и доверительным способом в базы данных ИТ, всё что просим, без ограничений, так надо
- ноутбуки линейных инженеров АСУТП должны иметь доступ только к сетям АСУТП производственных линий и ни к чему больше, такова Политика которую мы уже написали и утвердили
- у АСУТП не должно быть устройств создающих помехи сети Wi-Fi развёрнутой на производстве
- от контроллеров и АРМ-ов АСУТП не должно быть никакого исходящего трафика в сторону сетей ИТ, такова наша Политика безопасности
- Требования общие, нормативные: физическая защита и контроль физического и логического доступа к информационным системам.
Что касается физической защиты то прямых требований у ФСТЭК нет, поэтому ответ на вопрос что такое физическая защита объектов информатизации, коими безусловно являются и системы АСУТП, следует искать в других нормативных документах. Физическая защита включает не только ограждающие конструкции, но и запорные устройства, климатические установки и системы пожаротушения. Регулятор ещё не сформулировал прямые нормативные требования к шкафам АСУТП, которые гарантированно снижают уровень рисков до приемлемого для текущего уровня развития общества и технологий, но поскольку информация признаётся активом, ценностью, то возможно в будущем мы столкнёмся с прямым требованием регулятора об установке на шкафы АСУТП двух замков не ниже 3-го класса охранных свойств и прочее, прочее. Пока такие требования наш ЧОП не задвигает. Но, как говорил поэт: “О сколько нам открытий чудных ….”
Выбор технического решения
Достоверную передачу информации между физически защищёнными локациями может обеспечить, например, применение CRC, но одновременно достоверную и конфиденциальную передачу информации, как это требуют руководящие документы, может обеспечить только шифрование трафика.
Следует отметить, что последнее время некоторые производители оборудования наладили выпуск PLC которые “из коробки” имеют возможности шифрования трафика. Из российских это ОВЕН ПЛК210. Этот контроллер работает под управлением линукс операционной системы OpenWrt версии 18. Ссылка на руководство пользователя ПЛК210 в конце статьи, причём версия руководства свежая, сентябрь 2025 года, я сам ещё не читал эту версию, обязательно изучу. Впрочем, судя по картинкам, версия OpenWRT по-прежнему 18-я. На профильной выставке, осенью 2024 года, я интересовался у представителей производителя: почему на ПЛК210 используется до сих пор версия операционной системы 2018 года? Оказывается, проблема обновления версии операционной системы связана с санкциями. Активатор лицензий Runtime CODESYS, который куплен производителем оборудования, работает только под OpenWrt версии 18 максимум. Купить активатор более свежий не представляется возможным из-за санкций Евросоюза против России.
Поэтому, а также потому что заменить имеющиеся контроллеры Siemens на какие-либо другие в обозримом будущем не представляется возможным, логично что на производственной линии должно быть некое пограничное устройство которое выполняло бы функцию шифрования трафика “во внешний”, по отношению к производственной линии, мир. То есть устройство поддержки VPN (virtual private network) на стороне АСУТП и не только. В последние годы такие устройства получили название IES (Industrial Edge Server).
Выбор типа шифрования.
На самом деле вопроса выбора типа шифрования не стояло вообще. OpenVPN это единственная настоящая сеть, существующие альтернативы IPsec и WireGuard, хотя и называются VPN, сетями не являются, это туннели плюс некий набор средств маршрутизации (ака костылей) позволяющий объединить эти туннели в сеть, или даже “из коробки” без костылей (IPsec). IPsec отпал также из-за условий лицензирования и личного негативного опыта использования (из-за того что не вся документация есть в открытом доступе). WireGuard относительно свежий протокол, стремительно завоёвывающий популярность благодаря поддержке на уровне ядра линукс, но у него есть заметный недостаток – заметность. Трафик WireGuard легко обнаруживаемый, а значит его относительно легко перекрыть.
В корпоративной сети маршрутизация средствами VPN не нужна, для этого есть более серьёзные инструменты, однако пилотная система разворачивалась как самостоятельная, на Synology в качестве сервера поддержки VPN. На начальном этапе альтернативы OpenVPN по сути не было. Кстати, ПЛК210 использует OpenVPN, соответственно на сайте производителя есть подробнейшая инструкция по настройке. К сожалению, об этом примечательном PLC я узнал тогда, когда у меня уже было всё настроено. Шанс сэкономить время был упущен. Однако, то что команда ОВЕН-а и я двигались независимо, в одно и то же время, одним и тем же курсом, о чём-то да говорит. Впрочем, аргументы команды ОВЕН-а мне не известны.
Выбор ОС и аппаратной основы объектового устройства (IES).
Выбор операционной системы простой. Есть только две версии линукс, не считая производных от них, достаточно легковесные чтобы их можно было установить на недорогое, надёжное и массовое устройство. Это DD-WRT и OpenWrt. Проект DD-WRT выглядит заброшенным – на сайте комьюнити разработчиков новости появляются примерно одна новость в год :) Соответственно, список устройств для которых можно скачать готовую прошивку невелик. Другие урезанные или специализированные версии линукс, например, pfSence или Alpine уже значительно более требовательные к аппаратным ресурсам.
Выбор аппаратной основы очень простой. На сайте комьюнити разработчиков OpenWrt есть ссылка на таблицу (список) устройств для которых можно скачать любезно подготовленную прошивку. Вот эта ссылка.
Далее всё ещё проще, идём в магазин и смотрим что из представленного там подходит. Выбираем несколько моделей и читаем на них отзывы обращая внимание на надёжность именно аппаратной части, так как программное обеспечение будет полностью заменено. После этого окончательно определяемся с выбором.
На сайте OpenWrt есть раздел с техническим описанием устройств, для которых подготовлены прошивки. Очень полезно ознакомиться и сравнить тактико-технические характеристики, а также сравнить лёгкость процедуры перепрошивки с оригинального программного обеспечения на OpenWrt. В результате “звёзды сошлись” на модели TP-Link WR842nd v3, в начале. Потом появились TP-Link WR842nd v5 и TP-Link WR841nd v13. Оборудование TP-Link является массовым и, вполне обоснованно, считается глюкавым. Но глюкавые, как правило, только бюджетные модели при наполнении ПО которых производитель пытался объять не объятное и впихнуть невпихуемое, в не самое мощное железо, из-за чего и глюки. При перепрошивке альтернативным программным обеспечением оборудование TP-Link работает надёжно, годами в промышленных условиях.
Последнее время набирают популярность устройства типа Raspberry Pi. Мощные, массовые, а значит недорогие. Протестированные с последней версией OpenWRT 24.10.3 модели Orange Pi R1 Plus LTS, Nano Pi R3S, Orange Pi R1 работают стабильно. У модели Orange Pi R1 не работает с последней версией OpenWRT встроенный Wi-Fi, из-за устаревшего драйвера, но для наших задач Wi-Fi и не нужен, поэтому эта модель уже в работе.
А что у других?
Наши поставщики производственных линий используют аналогичный подход для обеспечения доступа к программному обеспечению устройств в составе поставленных производственных линий. Ниже примеры таких устройств.
Наши соседи по промплощадке, предприятие в несколько раз больше, пошли принципиально иным путём. У них была и есть мощная единая сеть передачи данных и отдел информационной инфраструктуры, занимающийся её поддержкой и развитием. Десятки километров оптического кабеля, тысячи сварок, сотни единиц коммутационного оборудования Cisco. Всё это использовалось в том числе и для АСУТП. Однажды, они решили отказаться от всего этого и построить отдельную новую сеть для АСУТП производственных линий и вспомогательного оборудования, без шифрования, разграничение (участков/производственных линий) только средствами коммутации уровней L2 и L3. Это подобно тому, как все жители города Теотиуакан по непонятной причине покинули город. Историки до сих пор не могут прийти к единому мнению почему это произошло. Мистика. Причём у них всего лишь 35 сети АСУТП объектов, у нас и то уже значительно больше. Как можно видеть из прилагаемого ТЗ, ссылка ниже, оно не предусматривает этапы выполнения работ, но денег после нескольких лет масштабного строительства сети у наших соседей не хватило. Поэтому проект в настоящее время остановлен. То, что сделано, названо первым этапом. Не всё оборудование первого этапа в работе, а только некоторые участки локально. Сколько будет продолжаться пауза неизвестно. А ведь они и мы начинали проработку вопроса ИБ примерно в одно и тоже время, 2019-2020 годы. Триггером был приказ №239 ФСТЭК. И они и мы проводили анализ угроз. Мы, проанализировав угрозы, пришли к выводу что man-in-the-middle (MitM) является угрозой, а они сочли что нет. Далее, видимо, сработал “эффект бабочки”.
Перепрошивка TP-Link WR841nd и TP-Link WR842nd.
Как уже было сказано, на сайте OpenWRT есть техническая страничка для каждого из поддерживаемых устройств которая содержит подробнейшую информацию о способах перепрошивки и отката на заводское ПО.
Для WR841nd вот, для WR841nd вот.
На что следует обратить внимание так это на аппаратную версию устройства. Не все аппаратные версии устройств поддерживаются OpenWRT. У TP-Link аппаратная версия устройства указывается на заводской бирке, которая наклеена на коробку. Это удобно, так как чтобы узнать аппаратную версию не нужно вскрывать коробку.
Наиболее удобный и быстрый способ перепрошивки для этих устройств, на мой взгляд, это заливка по TFTP. Если устройство включить в сеть с зажатой кнопкой RESET то через 5…10 секунд устройство будет пытаться зайти на TFTP сервер за новой прошивкой. Устройства выпуска до 2019 года, у нас это TP-Link WR841nd v13 и TP-Link WR842nd v3, пытаются найти TFTP сервер по адресу 192.168.0.66. Устройства выпуска после 2019 года, у нас это все TP-Link WR842nd v5, пытаются найти TFTP сервер по адресу 192.168.0.255. Следовательно, для того чтобы превратить ноутбук в TFTP сервер нужно установить программу Tftpd32.exe или Tftpd64.exe, в зависимости от архитектуры и изменить IP адрес ноутбука на статический 192.168.0.66 или 192.168.0.225, соответственно. Кроме того, надо указать программе TFTP сервера где именно на ноутбуке располагается папка с прошивкой (Current directory). Лучше если этот путь будет максимально короткий, не содержащий пробелов и русских символов. Например “C:\temp”. В эту папку надо поместить файл прошивки. Файл прошивки следует переназвать на “tp_recovery.bin”. Только такое название файла воспринимают все наши TP-Link устройства.
Что касается устройств типа Raspberry Pi все устройства, которые у нас есть, с карманом для SSDкарты. То есть img файл прошивки заливается на SSD карту любым удобным способом. Карта вставляется в устройство и устройство включается.
Выбор версии прошивки и кастомизация.
К скачиванию последней, самой свежей, поддерживаемой OpenWRT версии прошивки можно перейти прямо со страницы таблицы поддерживаемых устройств здесь.
Но можно поступить и по-другому, перейти на страницу скачивания и там выбрать нужную версию OpenWRT и для какого устройства нужна прошивка.
В открывшемся окне выбираем вариант TFTP-RECOVERY для устройства которое собираемся прошивать по TFTP. Для наших устройств самой свежей проверенной версией прошивки является 24.10.3 (сентябрь 2025 года).
Прошивка содержит базовый набор пакетов. Для нашего применения этого недостаточно, ибо у нас это не просто роутер, а полноценный Industrial edge server. Базовых пакетов достаточно только базовых функций, например, маршрутизация трафика, фильтрация трафика, раздача IP и правильного времени. Чтобы устройство поднимало VPN, работало как брокер MQTT, необходимо добавить дополнительные программные пакеты: openvpn-mbedtls, luci-app-openvpn (этот пакет для удобства), mosquito-nossl. Это минимальный наш набор. Чтобы устройство работало как шлюз Modbus TCP – Modbus RTU или как удалённый COM-порт дополнительно нужно установить поддержку порта USB это пакеты kmod-usb-core, kmod-usb-ochi, kmod-usb-echi, kmod-usb-serial и драйверы популярных чипов USB-COM: kmod-usb-serial-ch341, kmod-usb-serial-pl2303, kmod-usb-serial-ftdi. Если интересует функционал удалённого COM-порта то добавляем пакет ser2net, а если шлюза Modbus то mbusd.
Пакеты можно добавить двумя способами:
- Заказать кастомную прошивку. Это делается просто кликнув на ссылку “Изменить перечень устанавливаемых пакетов и/или первый загрузочный скрипт” на странице загрузки и добавив названия необходимых пакетов в открывшееся поле. После чего нажать кнопку “запросить сборку”.
- Добавить необходимые пакеты можно после прошивки через WEB интерфейс устройства System -> Software, ввести имя пакета в поле для поиска, нажать кнопку “Install”. Но для этого нужно чтобы устройство имело выход к Интернет, то есть возможность скачивания пакетов с сайта openwrt.org. Обеспечить возможность скачивания можно подключив устройство WAN интерфейсом к “чистому” интернету или назначить Wi-Fi интерфейс WWAN интерфейсом и временно, для загрузки необходимых пакетов, подключиться к интернету, раздаваемому с сотового телефона. Не забыть вернуть Wi-Fi интернет в режим который был до этого. У нас, как правило, Wi-Fi интерфейс отключен.
При выборе пакетов важно чтобы не было дублированного функционала. Это плохо хотя бы потому что без необходимости “съедает” память, но может и глючить, если зависимые пакеты будут теряться в своём выборе. Например, для прошивок версии 24 нативным пакетом криптозащиты является mbedtls. Заметьте, не openssl и не wolftls, а именно mbedtls. Поэтому установка, например, openvpn-openssl вместо openvpn-mbedtls повлечёт за собою установку всех необходимых по минимуму пакетов криптозащиты openssl, а это место в памяти, которое ограничено. Какая именно криптозащита является нативной для прошивки легко понять из названий пакетов устанавливаемых по умолчанию.
У наших устройств TP-Link, после установки всех необходимых пакетов, остаётся около 1,5 МБ в системном разделе, это нормально.
Восстановление бэкапа.
Бекапы конфигурации наших устройств лежат в надёжном месте, все знаю где. Бэкап можно без проблем восстановить только “версия в версию” OpenWRT. То есть 19 в 19, 23 в 23, 24 в 24. Номер полверсии не имеет значения. Если версия установленной на устройстве OpenWRT не такая как версия бэкапа, то прежде всего надо обновить версию OpenWRT на устройстве до последней проверенной, то есть 24.10.3. А бэкап перенести вручную. Конфигурация нового устройства и перенос конфигурации вручную это практически одно и тоже. Бекап это архив его можно любым архиватором распаковать и найти все интересующие настройки внутри. Кое что проще скопипастить, кое что набрать руками в WEB интерфейсе или в конфигурационном файле непостредственно на устройстве открыв его при помощи WinSCP. Например такой порядке:
восстанавливаем бэкап от устройства того же типа и той же версии OpenWRT что и установлена на подготавливаемом устройстве. При этом много настроек перенесутся сразу и их не нужно будет править вручную.
изменяем имя устройства на такое как надо. Это важно так как сервер VPN проверяет соответствие имени устройства реквизитам. Изменение имени устройства проще сделать через WEB интерфейс. System -> System -> General Setting -> Hostname или имя можно изменить в конфигурационном файле /etc/config/system
(если на правим восстановленный бэкап то этот пункт пропускаем) устанавливаем галки “Enable NTP client” и “Provide NTP server”. Это тоже самое что в конфигурационном файле /etc/config/system настройка config timeserver ‘ntp’ enable_servrer ‘1’
(если на правим восстановленный бэкап то этот пункт пропускаем) прописываем адрес NTP сервера System -> System -> Time Synchronization -> NTP server candidates откуда устройство будет брать время
Изменяем адрес LAN интерфейса устройства. Это лучше делать при помощи WinSCP непосредственно редактируя файл /etc/config/network потому что, если сделать это в WEB интерфейсе, и нажать “Save & Apply” то устройство сразу же применит настройку, а не обнаружив связь с браузером сделает ролбэк. То есть чтобы изменить IP адрес LAN интерфейса, к которому подключен конфигурационный ноутбук, надо в настройках его сетевого интерфейса дополнительно заранее прописать ту сеть, которая будет и браузер подготовить чтобы опросить устройство по новому адресу. Кучеряво. Поэтому проще через WinSCP поменять и просто перезагрузить устройство.
Реквизиты, полученные от отдела информационных технологий и распакованные, или найденные в недрах бэкапа более ранней версии, обязательно в распакованном виде, кладём в папку /etc/openvpn. На устройствах 19-ой версии, может быть, ещё используются реквизиты в запакованном виде. То есть если конфигурация переноситься с 19-ой версии на 24-ю реквизиты возможно потребуется предварительно распаковать реквизиты. При использовании распакованных реквизитов соединение устанавливается быстрее и нет необходимости устанавливать утилиты pkcs, которые занимают немало места. Распакованные реквизиты это файлы auth.cfg, cacert.cer, clientcert.cer, clientcert.key. Запакованные это файл с расширением .pfx в котором под паролем заархивированы файлы cacert.cer, clientcert.cer, clientcert.key и отдельно файл auth.cfg. Как распаковывать реквизиты из .pfx об этом в конце повествования.
(если на правим восстановленный бэкап то этот пункт пропускаем) Конфигурацию openvpn переносим просто копируя файл из бэкапа прошивки аналогичной версии OpenWRT. Путь назначения /etc/config/openvpn. Здесь указано аналогичной потому, что разные версии OhtnWRT используют разные версии клиентов OpenVPN. В виду развития, некоторые настройки могут устаревать насовсем, а некоторые просто заменяться новым синтаксисом. Согласование версий тянет на отдельную статью здесь, поэтому лучше не париться и взять уже проверенное, рабочее. В конфигурационном файле openvpn адрес сервера указан как доменным именем, так и IP адресом. Для пущей безопасности возможно, в будущем доменное имя уберём, чтобы не использовалась технология DNS. Так как каждая технология имеет уязвимости, даже если о них в настоящий момент ничего не известно. Технология DNS, полагаю, не исключение.
(если на правим восстановленный бэкап то этот пункт пропускаем) Конфигурацию mosquitto переносим просто копируя файл из бэкапа прошивки любой версии OpenWRT. Путь назначения /etc/config/mosquito. Кроме того, настройки собственно брокера, которые находятся в папке /etc/mosquito нужно перенести из бэкапа в устройство. Это файлы mosquito.conf и pass.txt, о последнем ниже.
Файл логинов и паролей mosquito, смотри пункт выше, pass.txt не бэкапится, его нет в бэкапе. Его надо перенести с другого, рабочего устройства.
(если на правим восстановленный бэкап то этот пункт пропускаем) Конфигурацию шлюза Modbus или удалённого COM-порта переносим просто копируя файл из бэкапа прошивки любой версии OpenWRT. Путь назначения /etc/config/mbusd или /etc/config/ser2net соответственно. Небольшое замечание. Шлюз Modbus и удалённый COM порт могут работать на одном устройстве, но не одновременно поскольку порт USB только один и мы не устанавливали драйвер USB хаба. Если были установлены оба пакета один из них нужно отключить в WEB интерфейсе System -> Startup.
(если на правим восстановленный бэкап то этот пункт пропускаем) Правим настройки сервера DHCP в WEB интерфейсе проще наверное, Network -> Interface, LAN кнопка Edit, закладка DHCP сервер. Иногда удобно чтобы DHCP сервер был в LAN производственной линии, это если есть необходимость подключаться непосредственно ноутбуком наладчика в LAN производственной линии, то галку Ignore interface не ставим. Устанавливаем начальный адрес количество адресов пула адресов таким образом, чтобы в этот диапазон не попадали имеющиеся IP адреса устройств в LAN линии. Обычно указываю в конце, скажем 30 адресов начиная с 220-го. Но лучше, всё-таки, подключаться через VNP, а галку Ignore interface установить. Так как каждая технология имеет уязвимости, даже если о них в настоящий момент ничего не известно. Технология DHCP, полагаю, не исключение.
(если на правим восстановленный бэкап то этот пункт пропускаем) Правим глобальные настройки DNS. В WEB интерфейсе Network -> DHCP and DNS закладка Filter снять галку “Rebind protection”. Это учёт некой особенности нашей внутренней сети предприятия, если устройство находиться за пределами предприятия, например, подключаться по LTE в VPN то перед установкой на объект эту настройку можно вернуть в состояние по умолчанию.
(если на правим восстановленный бэкап то этот пункт пропускаем) Для конфигурирования интерфейсов и firewall нужно чтобы интерфейс VPN (tun0) поднялся –подключаем устройство WAN интерфейсом к офисной сети. За процессом поднятия VPN удобно следить открыв в WinSCP файл /etc/openvpn /openvpn.log периодически нажимаю кнопку “переоткрыть”. Глубину лога можно устанавливать в настройках openvpn это настройка “option verd ‘x’” где x уровень детализации лога. Обычно уровень детализации 1, этого достаточно. Значение 0 – ведение лога отключено. Чтобы изменение уровня детализации лога воспринялось сервис надо перезапустить. Это удобно сделать через WEB интерфейс System -> Startup, находим openvpn и нажимаем кнопку “Restart”. Если соединение VPN установлено в логе появится запись “Initialization Sequence Completed.”
(если на правим восстановленный бэкап то этот пункт пропускаем) Для удобства диагностики проблем я вывожу индикатор работы VPN на светодиод green.wps. В WEB браузера идём System -> System -> LEDs Configuration. Давим кнопку “Add LED action”, во всплывающем окне вводим имя индикатора, пусть так и будет “VPN”. Выбираем индикатор green.wps, в альтернативной прошивке он не задействован. Это тот индикатор где нарисован замок, самый правый. Выбираем Trigger –> Network device activity. Выбираем устройство tun0. Отмечаем режим триггера всё что есть “Link On”, “Transmit”, “Receive”. У устройств типа Raspberry Pi, как правило, есть два светодиода или больше. По умолчанию зелёный светиться зелёным светом когда устройсто загружается и мигает когда устройство загрузилось. Красный по умолчанию не задействован, его удобно и следует задействовать для отображения состояния VPN интерфейса.
(если на правим восстановленный бэкап то этот пункт пропускаем) Конфигурируем интерфейсы. Сначала удаляем “лишние” интерфейсы, например тот который в OpenWRT присутствует по умолчанию, это WAN6. Чтобы добавить интерфейс VPN давим кнопку “Add new interface”. В открывшемся окне называем его, например “OIT_VPN”, тип протокола выбираем Unmanaged, устройство выбираем tun0. Нажимаем кнопку “Save”. Нажимаем кнопку “Save & Apply”. Снова заходим в настройки интерфейса и присваиваем название зоны firewall, например “VPN”. Нажимаем кнопку “Save”. Нажимаем кнопку “Save & Apply”.
(если на правим восстановленный бэкап то этот пункт пропускаем) В настройках LAN интерфейса отключаем всё что связано с ip v6. То есть зайдя на web интерфейсе в редактирование настроек LAN интерфейса переходим на вкладку “Advance Settings” и выбираем IP6 assigment length значение disabled. Забриджованный физический Wi-Fi c физическим LAN может быть там же, удаляем Wi-Fi из бриджа на этой же вкладке WEB интерфейса. Сам бридж можно не удалять.
(если на правим восстановленный бэкап то этот пункт пропускаем) Настройку firewall, что должно получиться в итоге, лучше один раз увидеть. В “базе”, то есть если производственная линия не содержит каких-либо особенностей, например, отдельного интерфейса с NAT для тех хостов IP которых изменить не удалось, картинка на закладке Network -> Firewall должна выглядеть так:
Трафик WAN интерфейса на нём же и заканчивается. Маскарадинг внутрь LAN потому что у хостов в LAN убрана/непрописана настройка gateway в настройках сетевых интерфейсов. Это сделано намеренно, чтобы хосты в LAN не знали ничего о существовании “внешнего мира” и не создавали ненужный трафик. Этот ход закрывает или дефункционализирует сразу несколько мер указанных в Приказе 239 ФСТЭК. Например, меру про антивирус. Попавший каким-то образом на хост вирус не может распространиться, а если он не может распространиться, то он дефункционализирован и, соответственно мера указанная в упомянутом Приказе удовлетворена.
По умолчанию в настройках firewall содержится много правил. Все они это дыры в безопасности. Удаляем всё на всех закладках. Опять же, это справедливо если речь идёт о “базовой” конфигурации без особенностей.
Не забываем нажимать “Save” и “Save & Apply” если что-то изменяем. Наличие несохранённых изменений показывает чёрный баннер в верху WEB интерфейса.
Реквизиты для подключения ноутбуком к сети производственной линии выдаются по запросу руководителя с указанием к сетям каких производственных линий сотруднику разрешается доступ и на какое время. Сейчас это по максимуму 3 года. Но сертификат может быть отозван и ранее по запросу руководителя. Конфигурация OpenVPN клиента у всех клиентов-ноутбуков одинаковая и отличается для Windows и Linux операционных систем только правилами написания путей к сертификатам и ключу, если версии клиентов одинаковые (Версии 2.5 и 2.6 в основном, но для пенсионера, который упорно не хотел “переезжать” с Windows XP, удалось подружить и более раннюю версию. Всё для людей.)
Проверочная таблица.
На этом о прошивке, конфигурации и восстановлении бэкапа всё. Вся эта информация есть в открытом доступе, всё используемое ПО с открытым исходным кодом или свободно распространяемое. Поэтому, при наличии доступа к интернету, нет проблем изучить какой-то нюанс глубже. Эта инструкция исключительно для того, чтобы была ИНСТРУКЦИЯ, то есть по минимуму, но всё в одном месте.
Не стесняйтесь мечтать, работайте и всё получиться!
Ссылка на первую часть про IES.
Ссылки на ранее написанные инструкции:
Инструкция по разархивированию .pfx
Инструкция по шлюзам Ethernet-to-COM и Modbus TCP - Modbus RTU
Инструкция по конфигурированию брокера MQTT и паблишера MQTT в контроллерах Simatic (S7-1200, S7-1500 в TIA Portal. S7-300, S7-400 в TIA Portal и Step 7 v5.6 как для встроенного в контроллер Ethernet интерфейса, так и для Ethernet интерфейса на коммуникационном процессоре)
Руководство пользователя ПЛК210.
Ссылка на третью, заключительную, часть статьи.