Версия документа
4.4.7 от 17.12.2025
Содержание
3. Основные требования
3.1 Список совместимых ОС
4. Структура и функционирование программного обеспечения
4.1 ScanSendService
4.2 RecvMultiPorts
4.3 Особенности применения СПО
5 Настройка и параметры программного обеспечения
5.1 Настройка ScanSendService
5.1.1 Параметры конфигурационного файла scansend_cfg
5.1.2 Структура файла списка сканирования
5.2 Настройка RecvMultiPorts
5.2.1 Параметры конфигурационного файла recvmultiports_cfg
5.2.2 Структура файла сканирования портов
6. Пример. Установка и настройка СПО (linux, deb пакеты)
6.2 Выбор состава аппаратных компонент и программных платформ
6.3 Настройки аппаратуры и СПО
6.3.1 Адреса сетевых адаптеров хостов и однонаправленного шлюза
6.3.2 Режим работы и файл конфигурации однонаправленного шлюза
6.3.3 Проверка взаимодействия с однонаправленным шлюзом.
6.3.4 Установка и настройка ScanSendService
6.3.5 Работа ScanSendService в консольном режиме
6.3.6 Установка и настройка RecvMultiPorts
6.3.7 Работа RecvMultiPorts в консольном режиме
6.4 Особенности настройки СПО в ОС Astra Linux 1.6
6.4.1 RecvMultiPorts
6.4.2 ScanSendService
6.5 Расположение файлов СПО и файлов конфигурации в файловой системе ОС
6.5.1 ScanSendService
6.5.2 RecvMultiports
1. Введение
Использование традиционных файловых протоколов (SMB, FTP, rsync, SSH и др.) при передаче через однонаправленный шлюз невозможно, потому что во всех используется обратное квитирование для подтверждения успешности обмена. Поэтому для обмена файлами между сегментами передающей и принимающей локальных сетей через однонаправленные шлюзы необходимо использование прокси хостов, которые бы осуществляли однонаправленный обмен информацией без использования квитирования. Соответственно на данных хостах должно использоваться специальное программное обеспечение, обеспечивающее данный функционал.
СПО sft_multi – это комплект утилит, предназначенных для передачи файлов через однонаправленные шлюзы семейства «Стром».
СПО sft_multi осуществляет постоянное циклическое сканирование содержимого, заданных в конфигурационном файле, «корневых» директорий-источников на компьютере(хосте) передающей сети и при обнаружении там файловой информации, осуществляет однонаправленную передачу на хост приемной сети. Приемная часть СПО осуществляет размещение принятой файловой информации в директории-приемники, заданные в конфигурационном файле и соответствующие конфигурации передающей части СПО.
Передача осуществляется с помощью однонаправленного транспортного протокола на базе UDPv4 протокола, обеспечивающего отсутствие квитирования, проверку целостности доставленной информации и избыточность передачи для компенсации возможных потерь при приемо-передаче.
СПО sft_multi платформа-независимое, список поддерживаемых операционных систем будет приведен далее по тексту. Допускается использование на хосте приема и передачи разных операционных систем.
Настройка СПО sft_multi для работы с различными однонаправленными шлюзами семейства «Стром»: Стром-1000, Стром-1000 МО, Стром-1000 В, Стром-100, Стром-10G сводится к изменению параметра ограничивающего скорость передачи. Краткие примеры настройки конфигураций самих шлюзов будут приведены далее по тексту.
В данном документе описана сертифицированная версия СПО sft_multi. Сертификат МО РФ №5354 от 09.07.2021.
2. Список литературы и ссылки
- АППАРАТНАЯ КОМПОНЕНТА ОДНОНАПРАВЛЕННОЙ ПЕРЕДАЧИ «СТРОМ-1000». Руководство по эксплуатации. ЛВТМ.465254.012 РЭ. 2020
- АППАРАТНАЯ КОМПОНЕНТА ОДНОНАПРАВЛЕННОЙ ПЕРЕДАЧИ «СТРОМ-1000». Руководство по эксплуатации. ЕАРМ.465254.012 01 РЭ. 2021
- АППАРАТНАЯ КОМПОНЕНТА ОДНОНАПРАВЛЕННОЙ ПЕРЕДАЧИ «СТРОМ-100». Руководство по эксплуатации. ЛВТМ.465254.008 РЭ.
- АППАРАТНАЯ КОМПОНЕНТА ОДНОНАПРАВЛЕННОЙ ПЕРЕДАЧИ «СТРОМ-10G». Руководство по эксплуатации. ЛВТМ.465254.002 РЭ.
- Сайт производителя. Сетевые однонаправленные шлюзы — https://www.cryptoex.ru/gateway/
- Сайт производителя. Программное обеспечение — https://www.cryptoex.ru/software/
- Сайт производителя. База знаний — https://www.cryptoex.ru/wiki/
3. Основные требования
Для однонаправленной файловой приемо-передачи между изолированными сегментами ЛВС через однонаправленные шлюзы семейства «Стром» требуются прокси хосты, на которые установлено СПО sft_multi. Один хост является передатчиком, другой приемником.
Типовая и простейшая схема, используемая для демонстрации работы показана на Рис. 1. Передатчиком на данной схеме является PC_ext, приемником соответственно PC_int. СПО sft_multi может функционировать как непосредственно на операционной системе хостов, так и на виртуальных машинах.
В дальнейшем при описании считается, что операционные системы установлены непосредственно на хостах (Рис.1). Сетевое взаимодействие, для обмена файлами, прокси хостов с сегментами ЛВС осуществляется с помощью общепринятых сетевых служб и протоколов и не рассматривается в данном документе.
Рис.1. Структура сети для однонаправленной передачи файлов между сегментами ЛВС.
Основным требованием к оборудованию хостов является обеспечение физического сетевого соединения Ethernet от передающего хоста к однонаправленному шлюзу и от шлюза к приёмному хосту. Технические характеристики интерфейсов для однонаправленных шлюзов указаны в [1], [2], [3], [4], [5].
Допускается соединение передающего хоста с однонаправленным шлюзом (в зависимости от модели) как по оптической, так и по медной среде передачи, напрямую или через порты коммутатора. Допускается соединение принимающего хоста с однонаправленным шлюзом через оптическую сетевую карту, через преобразователь интерфейсов, через коммутатор обеспечивающий преобразование оптики в медь.
Требования по производительности хостов не рассматривается в данном документе. Однако напомним следующие моменты важные для шлюзов с пропускной способностью интерфейсов 10 Гигабит/сек и 1 Гигабит/сек. Так как шлюзы обеспечивают работу на скорости канала (при любых конфигурациях) и фактически ведут себя как однонаправленный сетевой кабель в плане пропускания сетевых пакетов, то снижение итоговой пропускной способности при передаче файлов ниже теоретических максимумов (при исправном шлюзе) определяется только оборудованием и настройкой платформы (ОС) прокси хостов.
Максимальная пропускная способность L4 (UDP) на скорости 10Гбит/сек для ethernet пакета 1518 байт — 9571 Мбит/сек. Эту цифру (реально чуть ниже за вычетом накладных расходов транспортного протокола) следует считать максимальной пропускной способностью для файловой передачи. Однако из-за низкой эффективности работы стека ОС данную цифру скорее всего получить не удастся. При файловом обмене следует ориентироваться на значения 5000 — 6000 Мбит/сек.
Максимальная пропускная способность L4 (UDP) на скорости 1Гбит/сек для ethernet пакета 1518 байт — 957 Мбит/сек. Эту цифру (реально чуть ниже за вычетом накладных расходов транспортного протокола) следует считать максимальной достижимой пропускной способностью для файловой передачи.
При выборе аппаратной платформы хостов следует руководствоваться тем, что передатчик всегда менее загружен чем приемник. У передатчика самыми затратными операциями являются чтение файловой информации и ее передача, а у приемника прием и одновременная высокоскоростная запись на файловый носитель.
Для передатчика самым важным является проверка, сможет ли он на максимальной скорости передавать UDP трафик в сетевой интерфейс. Самая большая нагрузка — передача маленьких пакетов. Проверка возможностей передатчика осуществляется с помощью известной сетевой утилиты iperf (только версия 2).
Самым нагруженным в работе комплекса показанного на Рис. 1 является хост приемник. Для максимального использования полосы пропускания однонаправленного шлюза следует при выборе аппаратуры и настройки операционной системы руководствоваться подходами к высоко-нагруженным потоковым медиа серверам.
Основные рекомендации для выбора аппаратуры приемника для достижения максимальной производительности файловой передачи:
- Использование не столько большого количества ядер CPU, сколько их высокая тактовая частота (рекомендуется 4ГГц и выше);
- Использование быстрой памяти — DDR5;
- Использование производительных сетевых адаптеров, желательно серверного класса;
- Использование быстрых подсистем хранения — рекомендуются ssd, nvme, варианты raid 0 для классических жестких дисков;
- Использование современных производительных файловых систем — для linux рекомендуется xfs.
- Тонкая настройка операционной системы для выделения максимальных ресурсов СПО приема — выделение максимального приоритета утилите приема, оптимизация прерываний сетевого адаптера на выделенное процессорное ядро и.т.п
В случае наличия ошибок в приеме файлов на предельной скорости ( слабой аппаратной платформы) следует снижать в СПО скорость приемо-передачи для достижения безошибочного функционирования.
3.1 Список совместимых ОС
Функционирование СПО проверялось на следующих операционных системах:
- Linux Debian 32/64 bit;
- Linux Ubuntu LTS 20.04 64 bit, LTS 22.04 64 bit;
- Astra Linux: v1.4, v1.5, v1.6, v1.7(.3,5,6);
- Windows 32/64 bit;
- Заря 1.1;
- МСВС 5.0;
- МСВС 3.0 (ВИ 12, ВИ 13, ВИ 14, ВИ 16).
4. Структура и функционирование программного обеспечения
Для приемо-передачи СПО использует транспортный протокол на основе UDP, сетевого стека протоколов IPv4. СПО пользуется стандартными api функциями ОС (сокетами) для приема и передачи ip трафика.
Это важно для понимания работы и диагностики неисправностей. Часто пользователи сетуют на неработоспособность СПО, при этом у них не настроена или неправильно администрирована сетевая часть и любое ПО, использующее ip стек, не будет работать.»
В состав СПО однонаправленной передачи файлов входят две утилиты, устанавливаемые на соответствующих хостах.
4.1 ScanSendService
Утилита передачи файлов, устанавливается на хосте передатчике.
При запуске ScanSendService сканирует «корневые» директории, указанные в конфигурационном файле и при появлении там файлов, поблочно передает их с помощью своего транспортного протокола, базирующегося на UDP по указанному IP адресу и порту. В зависимости от настройки, передача файла последовательно повторяется заданное количество раз (избыточность). После окончания передачи файл стирается из корневой папки, либо (зависит от настройки) помещается в корзину (специально заданную папку).
4.2 RecvMultiPorts
Утилита приема файлов, устанавливается на хосте приемнике.
При запуске утилита постоянно принимает сетевые пакеты на указанный в конфигурации порт(ы), ip адрес источника не важен. В случае приема заголовка транспортного протокола, означающего начало передаваемого файла, утилита начинает прием поступивших блоков файла. Контроль потерянных блоков ведется по возрастающей нумерации блоков. Целостность данных обеспечивается за счет проверки целостности ethernet кадров аппаратурой хостов и однонаправленного шлюза. Успешно принятые блоки сохраняются во временный файл на дисковую подсистему. В случае пропуска блока в файле остается пустое место. Номера пропущенных блоков запоминаются утилитой приема. При повторной избыточной передаче, приемное СПО дописывает недостающие блоки во временный файл и как только весь файл принят, он переименовывается из временного и помещается в соответствующую «корневую» директорию с именем, которое было на передающем хосте. Если по результатам нескольких повторных передач приемнику не удалось собрать файл, временный файл уничтожается, а в логе фиксируется факт неудачного приема.
4.3 Особенности применения СПО
- ScanSendService не передает пустые папки.
- При запуске утилит поиск файла конфигурации производится следующем порядке: рабочая папка, папка с запускаемым файлом, /etc (в Linux системах).
- Пример консольного запуска утилиты передатчика в linux системе с параметрами:
$./ScanSendService -m:1 -t:1400 -s:960
5 Настройка и параметры программного обеспечения
5.1 Настройка ScanSendService
После первого запуска утилиты ScanSendService без параметров в рабочей папке создается конфигурационный файл scansend_cfg и файл списка сканирования scan_folder.lst с настройками по умолчанию. При каждом следующем запуске программа будет считывать параметры из файлов scansend_cfg и scan_folder.lst. Если ScanSendService запускается с ключом, который так же указан в файле scansend_cfg, то ключ в файле конфигурации scansend_cfg игнорируется.
5.1.1 Параметры конфигурационного файла scansend_cfg
m: Режим запуска
m:0 — один проход.
Утилита производит сканирование всех «корневых» директорий один раз, отправляет находящиеся там файлы и заканчивает работу.
m:1 — консольный (отладочный) режим.
Утилита работает бесконечно, вывод мониторинговой информации осуществляется в консоль. Во время работы постоянно осуществляется сканирование корневых директорий на предмет появления новых файлов и их передача.
m:2 — режим демона(сервиса, бесконсольный).
Утилита работает аналогично предыдущему режиму. Вывод мониторинговой информации осуществляется только в лог файл.
m:3 — останов программы.
Запуск утилиты с данным параметром используется для останова уже работающего экземпляра утилиты в режима демона.
v: Вывод на консоль
v:0 — вывод в консоль выключен.
v:1 — вывод в консоль включен.
v:2-включен расширенный вывод в консоль(режим отладки).
l: Вывод в лог
l:1 — вывод в лог включен.
l:0-вывод в лог выключен.
g: Имя и расположение лог файла.
Если параметр не задан, то лог-файл будет находиться в папке запуска утилиты.
Пример:
g:/var/log/sender.log
!!! Обязательно надо указывать путь к лог-файлу, если утилита запускается в daemon mode.
f: Путь к «корневой» директории-источнику.
Пример:
f:scan_folder
!!! Если задан файл списка сканирования, параметр игнорируется.
i: IP адрес назначения.
Адрес, на который отправляются пакеты транспортного протокола для передачи файлов.
Пример:
i:192.168.1.5
!!! Если задан файл списка сканирования, параметр игнорируется.
p: Порт назначения.
Порт, на который отправляются пакеты транспортного протокола для передачи файлов.
Значение по умолчанию: 55001
!!! Если задан файл списка сканирования, параметр игнорируется.
u: Количество копий заголовка файла в транспортном протоколе.
Перед передачей данных файла по транспортному протоколу, посылаются пакеты заголовка содержащие информацию о файле. При получении заголовков, утилита приема ставит файл в очередь приема и ожидает пакетов данных. Для повышения надежности используется избыточность (посылка нескольких копий).
Значение по умолчанию: 5
d: Количество передач данных.
d:1 — данные файла передаются один раз. Используется при отсутствии потерь на приеме.
d:2 — данные файла передаются два раза. Передача следующего файла начнется только после окончания второй передачи даже если пропадания пакетов на приёме не происходило.
Значение по умолчанию: 2
Для повышения надежности приема (в случае потери пакетов) используется избыточность передачи.Файл,включая копии заголовка,последовательно передаётся заданное параметром количество раз.
s: Скорость передачи данных (L4 уровень) в Мбит/с.
В передатчике реализован программный шейпер, ограничивающий поток данных передачи.
Для пропускной способности физической линии 10 Гбит/сек максимальное значение — 9600, рекомендуемое 5000.
Для пропускной способности физической линии 1 Гбит/с максимальное и рекомендуемое значение — 960.
Для пропускной способности физической линии 100 Мбит/с максимальное и рекомендуемое значение-96.
t: Максимальный размер блока данных протокола в байтах.
Возможные значения параметра: от 1400 до 65507 байт.
Передатчик «разрезает» файл на блоки данных, добавляет заголовок, и поблочно отправляет их с помощью socket api операционной системы. В ip v4 протоколе ограничение длины данных согласно RFC 791 составляет 65535.
!!! Данная утилита не имеет понятия об MTU линии. Блоки с длинной большей чем MTU фрагментируются стеком операционной системы автоматически.
Плюсы использования большого блока данных:
- В подавляющем случае современных сетевых адаптеров используется автоматический механизм фрагментации на уровне сетевого адаптера, включенный по умолчанию.
- Фрагменты пакета не содержат заголовка транспортного протокола.
- Доступ к памяти осуществляется страницами 4K
Рекомендуемое значение t = 4102415=60*1024=61440
Если производительность аппаратного обеспечения прокси хостов высокая или фрагментация пакетов нежелательна или невозможна следует учитывать MTU — размер блока задавать меньше MTU c запасом на заголовок транспортного протокола.
Значение 1400 подходит в случае сетевых адаптеров по умолчанию в линукс хостах.
Пример:
t:61440
j: Имя и расположение файла списка сканирования.
Пример:
j:/home/unidir/scan_folder.lst
c: Время ожидания перед следующим сканированием папок в секундах.
b: Маска-префикс исключения из передачи файлов.
Пример, исключение из передачи файлов начинающихся с ‘.’
b:.
e: Исключение из передачи файлов с заданным расширением.
z: Исключение из передачи файлов нулевой длины.
z:1 — файлы нулевой длины передаваться не будут.
z:0 — (по умолчанию) файлы нулевой длины передаваться будут.
x: Задержка в секундах отправки файла от момента его записи сторонним приложением в папку-источник.
x:0 — значение по умолчанию
Опция используется для задания таймаута, по истечении которого с момента окончания копирования файла в папку-источник сторонним приложением, начинается отправка файла. ПО таким образом следит за приходящими файлами. Опция введена на основе опыта использования вместе со службами FTP.
a: Значение локали (язык, кодировка, страна)
Используется только в Linux системах. Если утилита не может определить значение текущей локали (особенно в daemon режиме), то возможно искажение имен файлов содержащих русские символы.
Принудительное включение UTF-8 локали:
a:UTF-8
k: Включение работы «корзины» для переданных файлов.
k:1 — корзина включена.
k:0 — корзина выключена (по умолчанию).
y: Директорий расположения «корзины».
Используется при k:1.
o: Имя конфигурационного файла
По умолчанию используется scansend_cfg
h: Помощь.
Краткое описание ключей.
5.1.2 Структура файла списка сканирования
В основном конфигурационном файле можно задать только одну директорию источник и одно направление передачи ( IP назначения, порт).
Если требуется задать несколько директорий источников со своими направлениями передачи, используется дополнительный конфигурационный файл, называемый «файл списка сканирования». В основном файле в данном случае необходимо указать его имя и расположение.
Файл представляет собой набор строк вида:
<IP_dst>:<Port_dst> <path_to_scan_folder> [user_name]
<IP_dst> задает IP-адрес назначения, на который будет отправляться файл.
<Port_dst> задает порт назначения.
<path_to_scan_folder> задает имя «корневой» директории источника.
<user_name> указывать не обязательно. Если <user_name> задан, на приемной стороне в «корневой» директории приемнике, будет создана вложенная директория с заданным именем.
Пример файла списка сканирования:
192.168.10.1:55001 /home/usr1
192.168.10.1:55002 /home/usr2
192.168.10.1:55003 /home/usr3
5.2 Настройка RecvMultiPorts
После первого запуска утилиты RecvMultiPorts без параметров, в рабочей папке создается конфигурационный файл recvmultiports_cfg (с параметрами по умолчанию), файл сканируемых портов scan_ports.lst (с параметрами по умолчанию) и папка для временных файлов tmp. При каждом следующем запуске, RecvMultiPorts будет считывать параметры из recvmultiports_cfg и scan_ports.lst. Если утилита запускается с ключом, который так же указан в файле recvmultiports_cfg, то ключ в файле конфигурации recvmultiports_cfg игнорируется.
5.2.1 Параметры конфигурационного файла recvmultiports_cfg
m: Режим запуска
m:1 — консольный (отладочный) режим.
Утилита работает бесконечно, вывод мониторинговой информации осуществляется в консоль.
m:2 — режим демона(сервиса, бесконсольный).
Утилита работает аналогично предыдущему режиму. Вывод мониторинговой информации осуществляется только в лог файл.
m:3 — останов программы.
Запуск утилиты с данным параметром используется для останова уже работающего экземпляра утилиты в режима демона.
v: Вывод на консоль
v:0 — вывод в консоль выключен.
v:1 — вывод в консоль включен.
v:2-включен расширенный вывод в консоль(режим отладки).
l: Вывод в лог
l:1 — вывод в лог включен.
l:0 — вывод в лог выключен.
g: Имя и расположение лог файла.
Если параметр не задан, то лог-файл будет находиться в папке запуска утилиты.
Пример:
g:/var/log/receiver.log
t: Имя и расположение директории для временных файлов.
Пример:
t:/var/tmp
Если параметр не указан, временные файлы будут создаваться в директории приемнике.
!!! Директория временных файлов и целевые директории сохранения файлов должны находиться на одном носителе, в одном и том же разделе диска (одна файловая система), в противном случае файлы не будут сохранены при приеме.
p: Входящий порт транспортного протокола.
IP порт, на котором утилита приема ожидает данные транспортного протокола. Параметр работает, если не указан файл сканируемых портов, значение по умолчанию 55001.
!!! Если задан файл сканируемых портов, параметр игнорируется.
d: Имя и расположение директории для принятых файлов.
Пример:
d:/media/sft_rx/data
!!! Если задан файл сканируемых портов, параметр игнорируется.
с: Таймаут неудачи по получению файла (в мс).
Значение по умолчанию: 15000
Если для конкретного файла в течение таймаута не пришло больше ни одного блока, файл считается не принятым.
r: Таймаут удаления из очереди полученного файла (в мс).
Значение по умолчанию: 5000.
Удаление из очереди не принятого файла происходит по прошествии данного таймаута.
j: Имя и расположение файла сканирования портов.
Пример:
j:/home/unidir/recvmultiports
n: Режим проверки транспорта.
n:1 — режим включен.
n:0 — режим выключен (по умолчанию).
В этом режиме происходит приём файлов, но не производится их сохранение на диск. Таким образом утилита работает без затрат ресурсов на дисковую подсистему. Это позволяет оценить производительность системы по приёму данных из сети, исключая дисковую подсистему.
s: Режим синхронной записи полученной информации на диск.
s:1 — включен.
Выполнение команды sync (запись информации из кэша на диск) для дисковой подсистемы производится при получении каждого блока данных.
s:0 — выключен (по умолчанию).
Выполнение команды sync для дисковой подсистемы производится при успешном приёме всего файла целиком.
На современных системах включать данный режим не имеет смысла. Использовался для систем с невысокой производительностью.
a: Значение локали (язык, кодировка, страна)
Используется только в Linux системах. Если утилита не может определить значение текущей локали (особенно в daemon режиме), то возможно искажение имен файлов содержащих русские символы.
Принудительное включение UTF-8 локали:
a:UTF-8
o: Имя конфигурационного файла.
Значение по умолчанию — recvmultiports_cfg
h: Помощь.
Краткое описание ключей.
5.2.2 Структура файла сканирования портов
В основном конфигурационном файле можно задать только одну директорию приемник и один приемный порт на котором ожидаются данные транспортного протокола.
Если требуется задать несколько директорий приемников со своими значениями приемных портов, используется дополнительный конфигурационный файл, называемый «файл сканирования портов». В основном файле, в данном случае, необходимо указать его имя и расположение.
Файл представляет собой строки следующей структуры:
<Port_dst1> <path_to_destination_folder2>
….
<Port_dstN> <path_to_destination_folderN>
<Port_dst(X)> используется для задания порта на котором утилита приема будет ожидать данные транспортного протокола.
<path_to_destination_folder(X)> задает директорию назначения.
Файлы принятые через транспортный протокол с указанным портом назначения, будут складываться в указанный директорий.
Пример файла сканирования портов:
55001 /home/usr1
55002 /home/usr2
55003 /home/usr3
6. Пример. Установка и настройка СПО (linux, deb пакеты)
6.1 Постановка задачи
Необходимо реализовать однонаправленную передачу файлов между двумя сегментами сети на двух серверах. Хост внешней (передающей) сети имеет IP-адрес сетевого интерфейса для однонаправленной передачи — 10.8.0.5. Хост внутренней (принимающей) сети имеет в IP-адрес сетевого адаптера для приема однонаправленного трафика — 10.8.1.2. Передача и прием файлов должны осуществляться из трёх симметричных файловых директорий расположенных на внутренних дисках хостов см. Рис.2.
Рис.2. Постановка задачи. Структура.
6.2 Выбор состава аппаратных компонент и программных платформ
Для решения данной задачи выбраны следующий аппаратный состав и программные платформы:
- Однонаправленный шлюз СТРОМ-1000;
- Передающий сервер (ТТХ в Таблице 1);
- Принимающий сервер ( ТТХ в Таблице 2).
| CPU | Intel Corei7-4710HQ, 2.5 GHz |
| ОЗУ | DDR3 1600 MHz, 8 Gb |
| Диск хранения файлов | ST1000LM024 HN-M |
| eth0 | Intel I210 Gigabit |
| eth1 | RTL8111 Express Gigabit |
| ОС | AstraLinux 1.6.4 |
Таблица 1. Технические характеристики передающего сервера (хоста)
| CPU | Intel Corei7-4790K, 4.0 GHz |
| ОЗУ | DDR3 1333 MHz, 8 Gb |
| Диск хранения файлов | WD10EZEX-60W |
| eth0 | Intel I210 Gigabit |
| eth1 | NetXtreme BCM5718 Gigabit Ethernet |
| ОС | Debian 10.8.0 |
Таблица 2. Технические характеристики приемного сервера (хоста)
6.3 Настройки аппаратуры и СПО
Рис.3. Схема аппаратного стенда для реализации однонаправленной передачи файлов.
6.3.1 Адреса сетевых адаптеров хостов и однонаправленного шлюза
MAC адреса используемые в работе и при настройке стенда приведены на Рис.3.
MAC адрес сетевого адаптера передающего хоста для настройки нам не важен.
MAC адрес сетевого адаптера принимающего хоста используется при настройке однонаправленного шлюза. Определяем его следующей командой в консоли:
$ifconfig eth0
Входящий сетевой интерфейс однонаправленного шлюза имеет настройку MAC адреса в режиме фильтрации трафика (в котором функционирует аппаратная ARP машина). Зададим произвольный не широковещательный адрес — 00:11:22:33:44:55.
IPv4 адреса сетевых интерфейсов eth0 однонаправленного канала (соединяются с однонаправленным шлюзом) настраиваются средствами ОС в соответствии с Рис.3.
Настройка адресов интерфейсов eth1 для связи с сегментами ЛВС не рассматриваем.
6.3.2 Режим работы и файл конфигурации однонаправленного шлюза
По условиям задачи, ip адреса сетевых интерфейсов хостов передачи и приема находятся в разных подсетях. Поэтому будем использовать однонаправленный шлюз Стром-1000 в режиме фильтрации трафика [1] (режим по умолчанию).
Примечание: в однонаправленных шлюзах Стром-100, Стром-1000 МО это единственно возможный режим работы.
В текстовом редакторе создадим текстовый конфигурационный файл с именем s1000.cfg
Примечания:
- Особенности конфигурирования Cтром1000 МО, Стром-100 описаны в [2], [3];
- Для однонаправленного шлюза Стром1000 МО, текстовый конфигурационный файл необходимо создать с именем s1000.txt, затем скомпилировать ./zc s1000.txt s1000.cfg
Содержимое конфигурационного файла:
# mac адрес шлюза
wan mac 00:11:22:33:44:55
# разрешенный исходящий адрес сетевого интерфейса PC_ext
ip permit 10.8.0.5
# маршрут в приемную сеть, 10.8.0.6 - адрес назначения
# в передающей сети
route 10.8.0.6 10.8.1.2 00:23:F2:AB:23:33
Полученный файл s1000.cfg сохраняем на SD-карту и загружаем в однонаправленный шлюз.
6.3.3 Проверка взаимодействия с однонаправленным шлюзом.
Проверить работоспособность однонаправленного сетевого канала через шлюз можно различными методами. Для режима фильтрации одним из примитивных, но быстрых и действенных является следующий:
- В консоли передающего хоста запустить пинг на адрес назначения, указанный в маршруте однонаправленного шлюза:
$ping 10.8.0.6
Сетевой стек хоста активизирует механизм ARP. Однонаправленный шлюз не будет отвечать на ICMPv4 запросы, однако обменяется с хостом ARP пакетами, а ICMPv4 пакеты с передающего хоста будут поступать в шлюз.
- Корректность работы ARP механизма на передающем хосте проверяем командой консоли :
$arp -e
10.8.0.6 —— 00:11:22:33:44:55
IP адресу сетевого интерфейса должен соответствовать МАС-адрес однонаправленного шлюза.
- Счетчик пакетов на дисплее однонаправленного шлюза должен увеличиваться во время работы утилиты ping. Это означает, что шлюз пропускает пакеты на свой исходящий сетевой интерфейс.
- Должен увеличиваться счетчик принятых пакетов на интерфейсе eth0 принимающего хоста (команда ifconfig eth0, поле RX packet в ответе на команду).
Если вышеуказанные действия выполняются, это означает что однонаправленный канал настроен верно.
6.3.4 Установка и настройка ScanSendService
Установку ScanSendService на передающем хосте будем производить с помощью установочного deb пакета доступного на нашем ресурсе: https://www.cryptoex.ru/download/sft_multi-вер-мо-5354-09-07-2021/
Примечание: действия производятся с правами (в консоли) root
Установим deb пакет ScanSendService:
$dpkg –i ScanSendService.deb
Создадим корневые директории источники одним из двух методов:
Вариант 1 (по умолчанию).
Вводим в консоль 1 — Default и нажимаем Enter.
Скрипт попросит указать для каждой корневой директории поочередно ip адрес назначения передачи. Всего по умолчанию предлагается три направления передачи. Вводим 10.8.0.6
Скрипт установки создаст в директории /media три поддиректории: sft_out1, sft_out2, sft_out3
Вариант 2.
Вводим в консоль 2 — Manual и нажимаем Enter.
Вводим полный путь в котором будут создаваться корневые директории источники: /media
Указываем количество директорий источников: 3
Указываем для каждого директория источника его имя и ip адрес назначения: 10.8.0.6
Прописываем автозапуск сервиса и стартуем его:
$ systemctl enable unidirect_snd.service
$ systemctl start unidirect_snd.service
Проверяем статус сервиса :
$ systemctl status unidirect_snd.service
Вывод при правильной работе сервиса:
$ systemctl status unidirect_snd.service
● unidirect_snd.service - Unidirect_snd
Loaded: loaded (/etc/systemd/system/unidirect_snd.service; enabled;
vendor preset: enabled)
Active: active (running) since Tue 2024-06-25 15:11:56 MSK; 5s ago
Process: 18396 ExecStart=/etc/sft_multi/unidirect_snd_systemd start
(code=exited, status=0/SUCCESS)
Main PID: 18398 (ScanSendService)
Tasks: 1 (limit: 6948)
Memory: 452.0K
CPU: 12ms
CGroup: /system.slice/unidirect_snd.service
└─18398 /usr/sbin/ScanSendService
июн 25 15:11:56 sf-sndbx systemd\[1\]: Starting Unidirect_snd...
июн 25 15:11:56 sf-sndbx systemd\[1\]: Started Unidirect_snd.
Для быстрой проверки установки и настройки скопируем в папку источник файл:
$ cp ScanSendService /media/sft_out1
Признаки успешной передачи:
- Из директории источника исчезает скопированный файл
- Счетчик пакетов на дисплее шлюза увеличивается
- В логе ScanSendService появляется запись об успешной передаче файла:
$ cat /var/log/sender.log
25/06/2024 15:20:56 \> Sent file /media/sft_out1/ScanSendService.deb (1)
Folder /media/sft_out1 is empty now.
1 files was transfered.
- Счетчик принятых пакетов на сетевом интерфейсе eth0 хоста приемника увеличивается (ifconfig eth0, rx поле)
Если какой-то из вышеуказанных признаков не соответствует описанному выше, то это, в подавляющем количестве случаев, указывает на ошибку в настройках. Если есть уверенность, что всё настроено правильно, но работоспособность отсутствует, можно обратиться за консультацией https://www.cryptoex.ru/support/
6.3.5 Работа ScanSendService в консольном режиме
Примечание: действия производятся с правами (в консоли) root
В диагностических или каких-либо других целях можно настроить работу сервиса в консольном (отладочном) режиме. Для этого произведем следующие действия.
Остановим сервис и уберем автоматический запуск:
$ systemctl stop unidirect_snd.service
$ systemctl disable unidirect_snd.service
Отредактируем конфигурационный файл /etc/scansend_cfg:
m:1
v:2 #Опционально
Запустим утилиту:
$ cd / & ScanSendService
Для возврата в режим сервиса (daemon) произведем следующие действия.
Останавливаем утилиту:
$ killall ScanSendService
Отредактируем конфигурационный файл /etc/scansend_cfg:
m:2
v:0 #Опционально
Настроим автоматический запуск сервиса и запустим сервис:
$ systemctl enable unidirect_snd.service
$ systemctl start unidirect_snd.service
Проверим статус работы:
$ systemctl status unidirect_snd.service
6.3.6 Установка и настройка RecvMultiPorts
Установку RecvMultiPorts на приемном хосте будем производить с помощью установочного deb пакета доступного на нашем ресурсе: https://www.cryptoex.ru/download/sft_multi-вер-мо-5354-09-07-2021/
Примечание: действия производятся с правами (в консоли) root
Установим deb пакет RecvMultiPorts:
$ dpkg –i RecvMultiPorts.deb
Создадим корневые директории источники одним из двух методов:
Вариант 1 (по умолчанию).
Вводим в консоль 1 — Default и нажимаем Enter.
Скрипт установки создаст в директории /media три поддиректории: sft_in1, sft_in2, sft_in3
Вариант 2.
Вводим в консоль 2 — Manual и нажимаем Enter.
Вводим полный путь в котором будут создаваться корневые директории источники: /media
Указываем количество директорий назначения: 3
Указываем для каждой директории назначения её имя.
Прописываем автозапуск сервиса и стартуем его:
$ systemctl enable unidirect_rcv.service
$ systemctl start unidirect_rcv.service
Проверяем статус сервиса :
$ systemctl status unidirect_rcv.service
Вывод при правильной работе сервиса:
$systemctl status unidirect_rcv.service
● unidirect_rcv.service - Unidirect_rcv
Loaded: loaded (/etc/systemd/system/unidirect_rcv.service; enabled;
vendor preset: enabled)
Active: active (running) since Tue 2024-06-25 15:11:56 MSK; 5s ago
Process: 786 ExecStart=/etc/sft_multi/unidirect_rcv_systemd start
(code=exited, status=0/SUCCESS)
Main PID: 805 (RecvMultiPorts)
Tasks: 5 (limit: 6948)
Memory: 1.9M
CPU: 1.094s
CGroup: /system.slice/unidirect_rcv.service
└─805 /usr/sbin/RecvMultiPorts
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: Version:
1.0.0.0 Builds: 1
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: my pid 791
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: 55000
/media/sft_in1
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: 55001
/media/sft_in2
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: 55002
/media/sft_in3
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: Scan ports list
size: 3
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: Start
RecvService 27/06/2024 15:14:14
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[791\]: start daemon
июн 27 15:14:14 sf-sndbx unidirect_rcv_systemd\[786\]: + exit 0
июн 27 15:14:14 sf-sndbx systemd\[1\]: Started Unidirect_rcv.
Для проверки установки и настройки скопируем в папку источник (на передающем хосте) файл:
$ cp ScanSendService /media/sft_out1
Признаки успешной передачи и приема:
- Из директории источника исчезает скопированный файл
- Счетчик пакетов на дисплее шлюза увеличивается
- В директории приемнике sft_in1 появится принятый файл
- В логе RecvMultiPorts появляется запись об успешном приеме файла:
$cat /var/log/receiver.log
27/06/2024 15:26:50 \> file ScanSendService.deb received (1)
time from start: 0.054 sec 0.61793 (MByte/sec),4.9434 (MBit/sec)
Если какой-то из вышеуказанных признаков не соответствует описанному выше, то это, в подавляющем количестве случаев, указывает на ошибку в настройках. Если есть уверенность, что всё настроено правильно, но работоспособность отсутствует, можно обратиться за консультацией https://www.cryptoex.ru/support/
6.3.7 Работа RecvMultiPorts в консольном режиме
Примечание: действия производятся с правами (в консоли) root
В диагностических или каких-либо других целях можно настроить работу сервиса в консольном (отладочном) режиме. Для этого произведем следующие действия.
Остановим сервис и уберем автоматический запуск:
$ systemctl stop unidirect_rcv.service
$ systemctl disable unidirect_rcv.service
Отредактируем конфигурационный файл /etc/recvmultiports_cfg:
m:1
v:2 #Опционально
Запустим утилиту:
$ cd / & RecvMultiPorts
Для возврата в режим сервиса (daemon) произведем следующие действия.
Останавливаем утилиту:
$ killall RecvMultiPorts
Отредактируем конфигурационный файл /etc/recvmultiports_cfg:
m:2
v:0 #Опционально
Настроим автоматический запуск сервиса и запустим сервис:
$ systemctl enable unidirect_rcv.service
$ systemctl start unidirect_rcv.service
Проверим статус работы:
$ systemctl status unidirect_rcv.service
6.4 Особенности настройки СПО в ОС Astra Linux 1.6
6.4.1 RecvMultiPorts
Утилита приема обнаруживает файл scan_ports.lst только в корневой директории. Для корректной работы, при использовании данного файла, следует сделать символическую ссылку в корневой директории системы, указывающую на реальное расположение файла scan_ports.lst, а в файле конфигурации recvmultiports_cfg указать имя файла без пути.
Пример расположения файла — etc/sft_multi/scan_ports.lst
Примечание: действия производятся с правами (в консоли) root.
Создаем символическую ссылку:
$ cd /; ln -s /etc/sft_multi/scan_port.lst scan_ports.lst
В файле конфигурации указываем файл портов:
j: scan_ports.lst
6.4.2 ScanSendService
Для запуска в консольном режиме (m:1) используйте команду sudo:
$ sudo ./ScanSendService
6.5 Расположение файлов СПО и файлов конфигурации в файловой системе ОС
6.5.1 ScanSendService
/etc
└─/sft_multi
│ └─/scan_folder.lst - файл списка сканирования
│ /unidirect_snd_systemd - shell cкрипт запуска/останова утилиты передачи
└─/systemd
│ └─/system
│ └─/unidirect_snd.service – конфигурационный файл systemd для сервиса
└─/scansend_cfg - конфигурационный файл утилиты передачи
/usr/sbin/ScanSendService – утилита передачи
6.5.2 RecvMultiports
/etc
└─/sft_multi
│ └─/scan_ports.lst - файл сканирования портов
│ /unidirect_rcv_systemd - shell cкрипт запуска/останова утилиты приема
└─/systemd
│ └─/system
│ └─/unidirect_rcv.service – конфигурационный файл systemd для сервиса
└─/recvmultiports_cfg - конфигурационный файл утилиты приема
/usr/sbin/RecvMultiPorts – утилита приема