Руководство по эксплуатации информационного диода ST Engineering 5282

ST Engineering-логотип

Диод данных ST Engineering 5282

Диод данных ST Engineering 5282 — рис.1

Информация, содержащаяся в данном документе, является собственностью ST Electronics (Info-Security) Pte Ltd и не может быть скопирована, использована или раскрыта полностью или частично любой третьей стороне, кроме как с письменного разрешения ST Electronics (Info-Security) Pte Ltd или , если это было разрешено по контракту.

Глава 1 – Введение ЗБ

Ссылка на ST

  • Название: ST Engineering Data Diode модели 5282 и 5283 Security Target
  • Версия ST: 4.0
  • Дата ST: 10 июня 2022 г.

Ссылка на ОО

Ссылка на TOE: ST Engineering Data Diode, модель 5282, версия 2.2.1055, модель 5283, версия 2.2.1055.

  • имя: Диод инженерных данных СТ
  • Модель: 5282 и 5283
  • Версия: 2.2.1055

ТОЭ болееview
Объект оценки (TOE) — это сетевой шлюз, обеспечивающий одностороннюю передачу данных физического уровня через TOE.
ОО используется для соединения двух независимых сетей, обозначаемых как отправляющая сеть и принимающая сеть. Передающая сеть подключается к TOE через интерфейс InterfaceLAN (отправитель), а принимающая сеть подключается к TOE через интерфейс InterfaceLAN (получатель). На рис. 1 показана конфигурация сети, которая также является оцениваемой конфигурацией ОО.

Диод данных ST Engineering 5282 — рис.2

ОО гарантирует, что данные могут передаваться только из сети-отправителя в сеть-получатель, но не в обратном направлении. Блок-схема TOE показана на рисунке 2.

Диод данных ST Engineering 5282 — рис.3

ОО состоит из двух подсистем, т. е. материнской платы отправителя и материнской платы получателя. Эти две подсистемы физически отделены друг от друга и питаются от независимых источников питания. Свойство односторонней передачи данных достигается за счет пары настраиваемых SFP+ (см. рис. 2), которые реализованы на материнской плате отправителя и материнской плате получателя соответственно. SFP+ (отправитель) на материнской плате отправителя состоит только из оптического передатчика и не имеет внешнего интерфейса для приема оптических сигналов, в то время как SFP+ (приемник) на материнской плате получателя состоит только из оптического датчика и не имеет оптического передатчика; данные могут передаваться только оптическим путем от SFP+ (отправителя) к SFP+ (получателю) в силу физической реализации.
Обратите внимание, что портал управления (web интерфейс для настройки TOE) и File Системные модули как на материнской плате-отправителе, так и на материнской плате-получателе не являются модулями ОО и не считаются частью ОО.

Свойство ОО односторонней передачи данных на физическом уровне может решить две проблемы безопасности:

  • Это предотвращает утечку информации из сети-получателя в сеть-отправитель.
  • Это предотвращает нарушение целостности данных, находящихся в сети-отправителе, процессами, работающими в сети-получателе.

ОО состоит из двух моделей, т.е. 2 и 5282, которые реализуют одинаковую конструкцию и свойство односторонней передачи данных, как показано на рисунке 5283. Различия между моделями более подробно описаны в таблице 2 ниже.

Диод данных ST Engineering 5282 — рис.4 Диод данных ST Engineering 5282 — рис.5 Диод данных ST Engineering 5282 — рис.6

Тип ТОЭ
ОО является однонаправленным сетевым шлюзом физического уровня.

ОО Описание

Физический объем

Аппаратное и программное обеспечение TOE

Аппаратное обеспечение
Как показано на рисунке 2, ОО состоит из двух подсистем, т. е. материнской платы отправителя и материнской платы получателя. Эти две материнские платы физически отделены друг от друга и связаны друг с другом только через пару настроенных SFP+. Ниже приводится краткое описание материнских плат и настроенных SFP+.

  • Материнская плата отправителя;
    Эта материнская плата подключается к сети отправки. Он подключается к материнской плате приемника только через пару настраиваемых SFP+.
  • Материнская плата приемника;
    Эта материнская плата будет подключена к принимающей сети. Он подключается к материнской плате Sender только через пару настраиваемых SFP+.
  • SFP+ (отправитель)
    Это модуль, который является частью материнской платы отправителя. Он состоит из оптического передатчика, но не содержит внешнего интерфейса для приема оптических сигналов; он не может получать оптические сигналы извне.
  • SFP+ (приемник)
    Это модуль, являющийся частью материнской платы приемника. Он состоит только из оптического датчика, но не из оптического передатчика; он не может передавать оптические сигналы.
  • Источник питания (передатчик) и источник питания (приемник)
    Оба модуля являются независимыми источниками питания, которые подают питание на соответствующую материнскую плату отправителя и материнскую плату получателя.

Программное обеспечение
Материнская плата отправителя и материнская плата получателя работают под управлением операционной системы Linux. Далее описываются программные модули, работающие на соответствующих материнских платах-отправителях и материнских платах-приемниках.

  • Материнская плата отправителя
    • Служба отправителя
      Получает данные из отправляющей сети по стандартным сетевым протоколам, таким как TCP, UDP, SYSLOG, SNMP, SMTP, OPC, MODBUS, Video Streaming, Kafka.
    •  Диодный клиент данных
      • Преобразует стандартный протокол в проприетарный протокол
      • Отправляет данные в модуль SFP+ (Sender).
    • Портал управления
      Предоставляет интерфейс портала управления (web interface) для пользователей, чтобы настроить ожидаемый сетевой протокол в InterfaceLAN (Sender).
    • File Система:
      Сохраняет необходимую конфигурацию и журнал files, которые считываются и генерируются модулем Sender Service.
  • Материнская плата приемника
    o Диодный сервер данных
    ▪ Получает данные от модуля SFP+ (приемник).
  • Преобразует проприетарный протокол в стандартный сетевой протокол.
    • Служба приемника
      • Отправляет данные в приемную сеть с использованием стандартного сетевого протокола.
    • Портал управления
      • Предоставляет интерфейс портала управления (web интерфейс) для пользователей, чтобы настроить ожидаемый сетевой протокол на InterfaceLAN (Receiver).
    • File Система:
      • Сохраняет необходимую конфигурацию и журнал files, которые считываются и генерируются модулем Receiver Service.

Все программное обеспечение материнской платы отправителя и материнской платы получателя не может поставить под угрозу одностороннюю передачу данных физического уровня (уровень 1), поскольку программное обеспечение находится на уровне 2 и выше модели взаимодействия открытых систем (OSI).

Операционная система

  • ОС материнской платы отправителя: Linux
  • ОС материнской платы приемника: Linux

Аппаратное и программное обеспечение, не относящееся к TOE
Никто.

Способ доставки ОО и руководство пользователя
ОО доставляется по адресу клиента персоналом компании для местной доставки или доверенными курьерскими службами для доставки за границу.
Руководства пользователя доступны в следующих документах в формате PDF. Руководства пользователя доставляются пользователям по электронной почте:

  • Технические данные диода ST, модель 5282, версия 2.2. Руководство по установке v2.3. 2
  • Технические данные диода ST, модель 5283, версия 2.2. Руководство по установке v2.3. 2
  • Технические данные ST Диоды модели 328X, 5282 и 5283 Приемочные испытания версии 2.2
  • ST Engineering Data Diode Model 328X, 5282 и 5283 Руководство пользователя портала управления v2.6. Е

Логический объем ОО
ОО позволяет передавать данные из сети-отправителя в сеть-получатель, но не позволяет передавать данные в обратном направлении благодаря физической реализации настроенной пары SFP+ на соответствующих материнских платах-отправителях и материнских платах-получателях; SFP+ (отправитель) не имеет внешнего интерфейса для приема оптического сигнала, а SFP+ (получатель) не имеет оптического передатчика, поэтому передача данных из принимающей сети в отправляющую сеть через ОО физически невозможна.

Диод данных ST Engineering 5282 — рис.7

Следующая последовательность описывает поток данных через ОО:

  1. Отправляющая материнская плата получает данные из отправляющей сети через InterfaceLAN (отправитель).
  2. Затем материнская плата отправителя преобразует пакеты данных из стандартного сетевого протокола в проприетарный. Преобразованные пакеты данных затем пересылаются на материнскую плату приемника через настроенную пару SFP+.
  3. Материнская плата приемника получает собственные пакеты данных от материнской платы отправителя и преобразует их в стандартный сетевой протокол. Затем преобразованные пакеты данных пересылаются в принимающую сеть через InterfaceLAN (получатель).

Глава 2 – Заявления о соответствии

Заявления о соответствии
ОО и ЗБ соответствуют Общему критерию (CC) версии 3.1, редакции 5 от апреля 2017 г. ОО и ЗБ соответствуют части 2 ОК и части 3 ОК. ЗБ является пакетом, соответствующим пакету гарантий CC EAL4+ AVA_VAN.5.

Обоснование соответствия
Никто.

Глава 3 – Определение проблемы безопасности

В этом ОО рассматривается утечка данных из сети-получателя в сеть-отправитель.

Угрозы
В этом разделе описываются угрозы, которые устраняются ОО:
T.RCVDATALEAK: Пользователь или процесс в сети-получателе, который случайно или преднамеренно нарушает конфиденциальность данных путем передачи данных через ОО в сеть-отправитель.

Политики организационной безопасности
Не существует политик организационной безопасности, которым должен соответствовать ОО.

Предположения
Предположения, сделанные в отношении предполагаемой среды ОО, следующие:

  • A.PHYSICAL: ОО должен быть установлен и работать в среде, исключающей несанкционированный физический доступ.
  • A.USER: пользователям доверяют; пользователи не должны злонамеренно ставить под угрозу функциональные возможности безопасности ОО. Пользователи хорошо обучены; пользователь должен соблюдать рабочие процедуры, указанные в руководстве пользователя.
  • A.NETWORK: информационный поток между отправляющей сетью и принимающей сетью должен проходить через ОО, и между отправляющей сетью и принимающей сетью не должно быть никакого другого сетевого соединения.

Глава 4 Цели безопасности

Цели безопасности для ОО
O.ОДНОСТОРОННИЙ: ОО должен разрешать поток данных из передающей сети в принимающую сеть, но не в обратном направлении, т. е. из принимающей сети в передающую сеть.

Цели безопасности для операционной среды

  • Следующие цели безопасности необходимы для помощи ОО в правильном выполнении его функции безопасности односторонней передачи данных.
  • Эти цели достигаются путем применения процедурных или административных мер.
    OE.PHYSICAL: ОО должен быть установлен и эксплуатироваться в физически безопасной среде, которая предотвращает несанкционированный физический доступ.
  • OE.USER: пользователям доверяют; пользователи не должны злонамеренно ставить под угрозу функциональные возможности безопасности ОО. Пользователи хорошо обучены; пользователь должен соблюдать рабочие процедуры, указанные в руководстве пользователя.
  • OE.NETWORK: информационный поток между Передающей сетью и Принимающей сетью должен проходить через ОО, и между Передающей сетью и Принимающей сетью не должно быть никакого другого сетевого соединения.

Цели безопасности Обоснование

В таблице 2 цели безопасности сопоставлены с угрозами и предположениями, описанными в главе 3. В таблице показано, что каждой угрозе противостоит по крайней мере одна цель безопасности, что каждое предположение поддерживается по крайней мере одной целью безопасности и что каждая цель противостоит по крайней мере одной угрозе. или поддерживает хотя бы одно предположение.

Затем следует пояснительный текст, предоставляющий обоснование для каждой определенной угрозы, что если все цели безопасности, которые восходят к угрозе, достигнуты, угроза устранена, в достаточной степени уменьшена или что последствия угрозы в достаточной степени смягчены. Кроме того, показано, что каждое определенное допущение подтверждается, если достигнуты все цели безопасности для операционной среды, восходящие к допущению.

Диод данных ST Engineering 5282 — рис.8

Т. RCVDATALEAK

  • T.RCVDATALEAK: Пользователь или процесс в сети-получателе, который случайно или преднамеренно нарушает конфиденциальность данных путем передачи данных через ОО в сеть-отправитель.
  • O.ONEWAY гарантирует, что данные могут передаваться только из сети-отправителя в сеть-получатель, но не в обратном направлении.
  • OE.PHYSICAL обеспечивает развертывание ОО в физически безопасной среде, т. е. только авторизованным пользователям разрешен физический доступ к ОО. Это предотвращает изменение реализации и конфигурации ОО.amped, тем самым обходя или модифицируя одностороннюю передачу данных SFP
  • OE.USER гарантирует, что пользователям доверяют; пользователи не будут злонамеренно обходить или тampфункциональные возможности безопасности ОО. Это также гарантирует, что пользователь хорошо обучен; пользователи не будут неосознанно неправильно настраивать ОО, что может привести к нарушению функциональности безопасности ОО.
  • OE.NETWORK гарантирует, что все сетевые соединения между отправляющей сетью и принимающей сетью проходят через ОО, чтобы сохранить ПФБ односторонней передачи данных.

А. ФИЗИЧЕСКИЙ
А. ФИЗИЧЕСКИЙ: ОО будет установлен и будет работать в среде, исключающей несанкционированный физический доступ. OE.PHYSICAL напрямую поддерживает A.PHYSICAL.

ПОЛЬЗОВАТЕЛЬ
A.USER: пользователям доверяют; пользователи не должны злонамеренно ставить под угрозу функциональные возможности безопасности ОО. Пользователь хорошо обучен; пользователь должен соблюдать операционные процедуры, указанные в руководстве пользователя. OE.USER напрямую поддерживает A.USER.

СЕТЬ
A.NETWORK: информационный поток между отправляющей сетью и принимающей сетью должен проходить через ОО, и не будет никакого другого сетевого соединения между отправляющей сетью и принимающей сетью. OE.NETWORK напрямую поддерживает A.NETWORK.

Глава 5 Требования безопасности

  • Функциональные требования безопасности
    В ОО используются два субъекта: передающая сеть и принимающая сеть. Эти субъекты подключаются к ОО через InterfaceLAN (отправитель) и InterfaceLAN (получатель) соответственно. Эти предметы не имеют атрибутов.
    В этом заявлении ФТБ не определяются другие субъекты, объекты, операции, атрибуты безопасности или внешние сущности.
  • Полное управление информационными потоками (FDP_IFC.2)
    • FDP_IFC.2 Полное управление потоком информации
    • Иерархический для: FDP_IFC.1 Подмножество управления информационными потоками
    • Зависимости: FDP_IFF.1 Простые атрибуты безопасности
    • FDP_IFC.2.1 ФБО должны обеспечивать одностороннюю передачу данных в ПФБ физического уровня для всей информации от Передающей сети к Принимающей сети через ОО и для всех операций, которые вызывают поток этой информации к субъектам, охватываемым ПФБ, и от них.
    • FDP_IFC.2.2 ФБО должны гарантировать, что все операции, которые вызывают поток любой информации в ОО к любому субъекту в ОО и от него, охвачены ПФБ управления информационными потоками.
  • Простые атрибуты безопасности (FDP_IFF.1)
    • FDP_IFF.1 Простые атрибуты безопасности
    • Иерархический для: Нет других компонентов.
    • Зависимости: FDP_IFC.1 Подмножество управления информационными потоками FMT_MSA.3 Инициализация статических атрибутов1 FDP_IFF.1.1 ФБО должны обеспечивать одностороннюю передачу данных в ПФБ физического уровня на основе следующих типов атрибутов субъекта и информационной безопасности:
  • Тема: Отправляющая сеть, Принимающая сеть.
  • Атрибут информационной безопасности: Идентификация субъекта2
    FDP-IFF.1.2 ФБО должны разрешать информационный поток между контролируемым субъектом и контролируемой информацией посредством контролируемой операции, если выполняются следующие правила:
  • ФБО должны разрешить поток данных из Передающей сети в Принимающую сеть.
    • FMT_MSA.3 неприменим, так как нет атрибутов безопасности для инициализации.
    • Идентификатор субъекта определяется как отправляющая сеть и принимающая сеть.
  • ФБО должны запретить передачу данных из принимающей сети в передающую сеть.
    FDP_IFF.1.3 ФБО должны обеспечивать выполнение параметра None
    FDP_IFF.1.4 ФБО должны явно авторизовать информационный поток на основе следующих правил: Нет.
    FDP_IFF.1.5 ФБО должны явно отклонить информационный поток на основании следующих правил: Нет
  • Определение расширенных компонентов
    В этом ЗБ не определены расширенные компоненты.
  • Обоснование требований безопасности
  • Отслеживание между ФТБ и целями безопасности для ОО
    В следующей таблице показано соответствие между требованиями безопасности и целями безопасности ОО.Диод данных ST Engineering 5282 — рис.9
  • Обоснование достаточности
    Цель безопасности ОО:
    • O.ОДНОСТОРОННИЙ: ОО должен разрешать поток данных из передающей сети в принимающую сеть, но не в обратном направлении, т. е. из принимающей сети в передающую сеть.
    • FDP_IFF.1 требует, чтобы вся информация, проходящая через ОО, охватывалась односторонней передачей данных в ПФБ физического уровня. Это гарантирует, что никакие информационные потоки, будь то явные или скрытые, не освобождаются от односторонней передачи данных в SFP физического уровня.
    • FDP_IFC.2 требует, чтобы данные могли передаваться только из сети-отправителя в сеть-получатель, а не в обратном направлении, т. е. из сети-получателя в сеть-отправитель.
  • Требования к обеспечению безопасности
    Требованиями обеспечения безопасности для ОО является Уровень обеспечения оценки 4+ AVA_VAN.5.
    Класс гарантии Компонент гарантии
    Реклама: разработка ADV_ARC.1 Описание архитектуры безопасности
    ADV_FSP.4 Полная функциональная спецификация
    ADV_IMP.1 Представление реализации ФБО
    ADV_TDS.3 Базовая модульная конструкция
    АГД: Руководящие документы AGD_OPE.1 Оперативное руководство пользователя
    AGD_PRE.1 Подготовительные процедуры
    ALC: поддержка жизненного цикла ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизация
    ALC_CMS.4 Проблема отслеживания охвата CM
    ALC_DEL.1 Процедуры доставки
    ALC_DVS.1 Идентификация измерений безопасности
    ALC_LCD.1 Модель жизненного цикла, определяемая разработчиком
    ALC_TAT.1 Четко определенные инструменты разработки
    ASE: оценка цели безопасности ASE_CCL.1 Заявления о соответствии
    ASE_ECD.1 Расширенное определение компонентов
    ASE_INT.1 Введение ЗБ
    ASE_OBJ.2 Цели безопасности
    ASE_REQ.2 Производные требования безопасности
    ASE_SPD.1 Определение проблемы безопасности
    ASE_TSS.1 Краткая спецификация ОО
    АТЕ: Тесты ATE_COV.2 Анализ покрытия
    ATE_DPT.1 Тестирование: базовый проект
    ATE_FUN.1 Функциональное тестирование
    ATE_IND.2 Независимое тестирование – сample
    АВА: уязвимость

    оценка

    AVA_VAN.5 Расширенный методический анализ уязвимостей

     

  • Обоснование требований обеспечения безопасности
    Пакет обеспечения оценки, выбранный для оценки ОО, соответствует уровню EAL4+.
    Пакет гарантий AVA_VAN.5. Пакет гарантии EAL4+ AVA_VAN.5 был выбран для обеспечения устойчивости к атакам с высоким потенциалом, который соответствует коммерческим продуктам для приложений в правительстве. Выбранный уровень доверия соответствует угрозам, определенным для среды (физическая защита со стороны среды, ограниченный интерфейс и доступ к ОО).
  • Таблица зависимостей требований безопасности
    В таблице 5 показано соответствие всем зависимостям требований безопасности. Для каждого требования безопасности, включенного в ЗБ, зависимости CC идентифицируются в столбце «Зависимость от CC», а удовлетворенные зависимости идентифицируются в столбце «Зависимость от ЗБ».
    СТ СФР Зависимость от ST Зависимость CC Оправдание
    FDP_IFC.2 FDP_IFF.1 FDP_IFF.1
    FDP_IFF.1 FDP_IFC.2 FDP_IFC.1 FMT_MSA.3 FMT_MSA.3 неприменим, поскольку

    нет атрибутов безопасности для инициализации.

     

  • Сводная спецификация ОО
    ОО отвечает двум функциональным требованиям безопасности: FDP_IFC.2 и FDP_IFF.1. Они работают вместе, чтобы удовлетворить цель безопасности для TOE. Далее приводится описание общих технических механизмов, которые ОО использует для удовлетворения каждой определенной ФТБ. Он включает описание функциональных возможностей безопасности, приведенное в каждом ПТБ в виде ссылки, и предоставляет высокоуровневую view их реализации в ОО
    • FDP_IFC.2:
      ОО состоит из двух подсистем, т. е. материнской платы отправителя и материнской платы получателя. Материнская плата-отправитель и материнская плата-приемник полностью независимы, каждая из них имеет свои собственные независимые интерфейсы питания и сети, каждая из которых заключена в корпус, который не пропускает электрические или оптические сигналы через какие-либо другие интерфейсы, кроме описанных. Согласно руководству пользователя (изложенному в разделе 1.4.1.3), материнская плата-отправитель подключена только к сети-отправителю и не подключена к сети-получателю. И наоборот, материнская плата приемника подключена только к принимающей сети.
      Материнская плата отправителя и материнская плата получателя соединены только одним оптоволоконным кабелем. Этот оптоволоконный кабель подключается к каждой материнской плате-отправителю и материнской плате-получателю через соответствующие настраиваемые SFP+, то есть SFP+ (отправитель) и SFP+ (получатель). Это гарантирует, что все данные, проходящие через ОО, должны проходить по оптоволоконному кабелю и, таким образом, покрываться односторонней ПФБ передачи данных.
    • FDP_IFF.1:
      Модуль SFP+ (отправитель) преобразует входящие электрические сигналы в оптические, а модуль SFP+ (приемник) преобразует входящие оптические сигналы в электрические. Модуль SFP+ (Sender) содержит оптический передатчик, а не оптический датчик, который может принимать оптические сигналы извне. И наоборот, модуль SFP+ (приемник) содержит только оптический датчик, а не оптический передатчик. Следовательно, SFP+ (отправитель) и SFP+ (получатель) вместе физически позволяют передавать данные только из сети-отправителя в сеть-получатель, но не в обратном направлении.

Ссылки

  1. Общие критерии оценки безопасности информационных технологий, часть 1: введение и общая модель, апрель 2017 г., версия 3.1, редакция 5
  2. Общие критерии оценки безопасности информационных технологий, часть 2: функциональные компоненты безопасности, апрель 2017 г., версия 3.1, редакция 5
  3. Общие критерии оценки безопасности информационных технологий, часть 3: компоненты обеспечения безопасности, апрель 2017 г., версия 3.1, редакция 5
  4. Общие критерии оценки безопасности информационных технологий, методология оценки, апрель 2017 г., версия 3.1, редакция 5.

AFFgiations

  • Общие критерии CC
  • Уровень гарантии оценки EAL
  • Требования обеспечения безопасности SAR
  • Функциональные требования безопасности SFR
  • Функциональная политика безопасности SFP
  • Модуль диода данных SFP+
  • ОО Цель оценки
  • Функция безопасности ОО ФБО
  • Цель безопасности ST

Документы/Ресурсы

миниатюра PDF5282 Диод данных
Instruction Manual · 5282, 5283, 5282 Data Diode, 5282, Data Diode, Diode

Вопросы и ответы

Helpful product questions tied to this manual. Each item links to the full Q&A page.

Вопросы и ответы

Use this section to ask about setup, compatibility, troubleshooting, or anything missing from this manual.

  1. Hi, my name is Ami and I’m Radiflow QA engineer, I would like you please to send me the installation guide for: ST Engineering Data Diode Model 5282 version 2.2 Setup Guide v2.3. 2
    I have the device here and want to figure out basic installation.

    Спасибо

    Ami Golan asks Hi, my name is Ami and I'm Radiflow QA engineer, I would like you please to send me the installation guide for: ST Engineering Data Diode Model 5282 version 2.2 Setup Guide v2.3. 2
    I have the device here and want to figure out basic installation.

    Спасибо

    Manuals+ clarified question
    Вопрос

    Where can I find the installation and setup guide for the ST Engineering Data Diode Model 5282 version 2.2?

    Отвечать

    According to the ST Engineering Data Diode Model 5282 and 5283 Security Target documentation, the specific manual you are looking for, ST Engineering Data Diode Model 5282 version 2.2 Setup Guide v2.3.2, is not hosted publicly for direct download on this page.

    The documentation specifies that user guides are delivered to customers via электронная почта or provided during the delivery of the physical unit. For basic installation of the Model 5282, the following hardware details are available:

    • Physical Units: The 5282 consists of one physical unit containing a Sender Motherboard and a Receiver Motherboard.
    • Интерфейсы: Both the Sender and Receiver motherboards include 1 x Console port and 1 x USB port.
    • Связь: The Sending Network must connect to the InterfaceLAN (Sender), and the Receiving Network must connect to the InterfaceLAN (Receiver).
    • Конфигурация: A Management Portal (web interface) is used to configure the networking protocols on both the Sender and Receiver sides.

    If you do not have the PDF guide, we recommend contacting ST Engineering support or checking the email associated with the product's procurement, as these guides are typically restricted to authorized users.

Задать вопрос

Ask about setup, compatibility, troubleshooting, or anything missing from this manual. Name and email are optional.