Главная страница

Manual-DIONIS-DUAL-ARC - КРИПТОМАРШРУТИЗАТОР. Руководство по настройке изделий и управлению их работой ru. Нкбг. 3000903 91 Под


Скачать 7.28 Mb.
НазваниеРуководство по настройке изделий и управлению их работой ru. Нкбг. 3000903 91 Под
Дата22.01.2023
Размер7.28 Mb.
Формат файлаpdf
Имя файлаManual-DIONIS-DUAL-ARC - КРИПТОМАРШРУТИЗАТОР.pdf
ТипРуководство
#898109
страница47 из 48
1   ...   40   41   42   43   44   45   46   47   48
MX-записи для всех машин, способных получать почту. Причем, если машина будет самостоятельно принимать свою почту, то в качестве имени_домена и
имени_машины должно быть указано собственное имя машины так, как оно задано в записи типа A (см. третью строку примера).
Внимание! Правила запрещают использование алиасных имен (определенных записями типа CNAME) в качестве имени_машины в поле данные MX-записей.
Отличия конфигурирования DNS-сервера изделия от конфигурирования BIND
1. DNS-сервер изделия может обслуживать до 8-ми зон.
2. Имена зон должны заканчиваться точкой. Имя зоны, используемой для накачки кэша, должно состоять из одной точки.
Пример. Пусть стандартный файл named.boot BIND имеет вид:
cache
.
named.cache
primary
factor.ru
named.hosts

Приложение Д. Использование DNS-сервиса 247
primary
0.0.127.IN-ADDR.ARPA
named.local
primary
1.168.192.IN-ADDR.ARPA
named.rev
primary
factor.rospac.ru
factor.hosts
primary
36.220.194.IN-ADDR.ARPA
factor.rev
В DNS-сервере изделия для указания аналогичных BIND режимов работы следует создать 5 зон с именами:
.
factor.ru.
1.168.192.IN-ADDR.ARPA.
factor.rospac.ru.
36.220.194.IN-ADDR.ARPA.
Зону с именем 0.0.127.IN-ADDR.ARPA. создавать не нужно.
3. При создании зоны в ее заголовке, кроме имени зоны, должны быть заданы все параметры записи SOA зоны. Внутри зоны записи типа SOA не допускаются.
4. При создании записей зон нужно руководствоваться стандартными правилами. Для загрузки записей зон можно использовать стандартные текстовые файлы системы BIND с учетом следующих ограничений:
 каждая запись должна занимать одну строку; круглые скобки не обрабатываются;
 запись типа SOA должна быть исключена или закомментирована;
 команды $origin и $include не обрабатываются.
5. При загрузке записей зоны в кэш выполняются следующие соглашения.
 Вместо отсутствующего имени записи подставляется имя предыдущей записи.
 Вместо отсутствующего имени первой записи подставляется имя зоны.
 К именам, не имеющим точки в конце, добавляется точка и имя зоны, которое обязательно должно заканчиваться точкой.
 Если значения в поле время нет, подставляется время Minimum из заголовка зоны.
6. Если в процессе работы DNS-сервера изделия администраторзоны вносит какие-либо изменения в файл зоны, то программа управления сразу же выполняет перезагрузку кэша.
7. С целью обеспечения безопасности обслуживания программа управления изделием отказывает в исполнении запросов на пересылку зон, т. е. ни один внешний сервер не может извлечь целиком зону из DNS-сервера изделия.

Приложение Е. Системные журналы изделия
При работе изделия практически каждое выполненное действие (происходящее событие) фиксируется или может быть зафиксировано (в случае соответствующих настроек средств трассировки изделия) в одном из системных журналов изделия.
Системные журналы изделия представляют собой две группы файлов: группа файлов, в которых фиксируются события, происходящие в блоке внутренней маршрутизации (БВМ), и аналогичная группа файлов с такими же именами, в которых фиксируются события, происходящие в блоке наружной маршрутизации (БНМ).
Все системные журналы маршрутизаторов изделия представляют собой обычные текстовые файлы, имена которых сформированы по общему правилу: первые три символа основной части имени – LOG,
расширениеEMA (системные журналы иначе называются LOG -файлами или файлами протоколирования).
1. Журнал LOG.EMA
Файл LOG.EMA – это основной системный журнал маршрутизатора изделия. Он служит для протоколирования общесистемной информации о работе маршрутизатора изделия. В файл LOG.EMA записывается вся информация, выдаваемая на видеомонитор ЛКУ соответствующего маршрутизатора – БВМ или БНМ.
Работа любого из маршрутизаторов изделия с журналами начинается с открытия файла LOG.EMA.
На Рис. Е.1 приведен фрагмент записываемой в журнал информации о запуске маршрутизатора изделия.
Рис. Е.1 Фрагмент записываемой в журнал информации о запуске маршрутизатора изделия
В протоколе после первой записи об открытии файла следуют записи с техническими характеристиками аппаратных компонентов маршрутизатора изделия и код завершения предыдущего сеанса его работы.
Затем следует информация о контроле целостности общего программного обеспечения маршрутизатора изделия:
TIMEOUT (интервалпроверки в секундах), имя контролируемого файла (dioniswt) с результатом выполненного контроля (OK).
В файл LOG.EMA заносится запись «СТОП» в тех случаях, когда программа управления не допускает абонента к работе с маршрутизатором изделия. Запись содержит информацию о причине недопуска и имеет следующий формат:
N Who СТОП hh:mm:ss dd-mm-yy контроль=kod1 вход=kod2
где:
N – номер порта, через который абонент пытался начать работу с маршрутизатором изделия;
Who – имя абонента, который пытался начать работу с маршрутизатором изделия;
hh:mm:ss dd-mm-yy – время и дата записи в LOG-файл;
kod1,kod2,kod3 – коды завершения операции;
adress
– адрес абонента, который пытался начать работу с маршрутизатором изделия.
Значения кодов завершения операции СТОП:
Kod1 (контроль)
1
Нет абонента с указанным именем
7
Абонент с таким именем уже есть
8
Неверно указан пароль

Приложение Е. Системные журналы изделия 249
Kod2 (вход)
1
Произошло аварийное сворачивание работы ОПО
7
Неправильно указан язык
32 Неправильно указан дополнительный пароль
2. Журнал LOG_USER.EMA
В файле LOG_USER.EMA всегда фиксируется факт запуска и останова маршрутизатора изделия.
В файл LOG_USER.EMA записывается информация о регистрации новых абонентов, об удалении или изменении полномочий ранее зарегистрированных абонентов, а также о начале или окончании работы абонента с маршрутизатором изделия.
Каждое фиксируемое событие представлено в файле LOG_USER.EMA отдельной записью; начинается запись всегда с первой позиции строки и имеет следующий формат:
PP_OO_exit: Who hh:mm:ss dd-mm-yy Add
PP – код процесса;
OO – код операции;
exit – код завершения операции;
Who – имя абонента, при работе которого производится запись в LOG-файл;
hh:mm:ss dd-mm-yy – время и дата записи в LOG -файл;
Add – дополнительная информация (может отсутствовать).
Процессы, фиксируемые в LOG-файле LOG_USER.EMA, имеют следующие коды:
PP
(код)
Процесс
ss
rc
tm работа изделия и работа абонентов удаленное управление служба времени
Операции каждого из процессов представлены в нижеследующих таблицах. Все таблицы имеют одну и ту же структуру, а именно:
Первая графа (ОО) – код операции.
Вторая графа (Операция) – название операции.
Третья графа (exit) – значение кода завершения операции (ОК или ERR). Коды завершения предусмотрены не для всех операций; для некоторых из операций предусмотрен только один код (или при успешном завершении или при аварийном). Если код завершения не предусмотрен, то при записи операции в LOG-файл на месте кода (exit) ставятся два пробела.
Четвертая графа (Add) может содержать различную информацию.
После таблиц в качестве примера приведены фрагменты реального LOG-файла с нашими комментариями.
Процесс «Работа изделия и работа абонентов» (код ss)
ОО
Операция
exit
Add
DO запуск изделия
DC останов изделия
ОК
ER
UA создание абонента или группы абонентов
OK
UD удаление абонента или группы абонентов
OK
li начало работы абонента с изделием
OK
ER
br прекращение сеанса из-за разрыва связи
ab абортирование абонента (по причине неактивности, при срочном останове системы и пр.)
AP неверно введен пароль администратора узла
ER неверно введен пароль администратора группы
ER
Gr:-<имя_группы>
TA изделие переведено в режим "администратор узла"
OK
TO изделие переведено в режим "оператор"
OK
??
изделие переведено в режим "администратор сети"
OK
ОО
(код)
Операция
exit
(код завершения)
Add
(дополнительная информация)

250
Приложение Е. Системные журналы изделия
Пример: фрагмент файла LOG_USER.EMA
Запуск
КМ
ss_DO_ : DIONIS 16:56:02 28-09-15
Создание группы абонентов USERS
ss_UA_OK: -USERS 17:03:28 28-09-15 Gr:6 Id:6
Создание абонента uu1
ss_UA_OK: uu1 17:15:13 28-09-15 Gr:6 Id:12090
вход uu1 в
КМ
ss_li_ : uu1 17:56:15 28-09-15
прекращение сеанса из-за разрыва связи
ss_br_ : uu1 18:07:22 28-09-15
Удаление абонента из системы
ss_UD_OK: uu1 18:58:15 28-09-15
Неверно введен пароль администратора узла
ss_AP_ER: admin 19:00:04 28-09-15
Узел переведен в режим "администратор узла"
ss_ТA_OK: admin 19:03:15 28-09-15
узел переведен в режим "оператор" из режима "администратор узла"
ss_TO_OK: admin 19:10:04 28-09-15
Останов
КМ
ss_DC_OK: DIONIS 19:50:31 28-09-15
Процесс «Удаленное управление» (код rc)
ОО
Операция
exit
Add
au автоматическое разрешение на удаленное управление
ОК
Md:<режим_
управл.>
er отказано в разрешении на удаленное управление
Er:#
В графе Add:
<режим_управл.>: возможные значения: Look, Control и Grasp (уровень полномочий –
Захват).
Er:#
–символ # означает число; возможные значения:
1 – не хватает ресурсов, чтобы разрешить удаленное управление;
5 – ошибочное имя или дополнительный пароль.
Процесс «Служба времени» (код tm)
ОО
Операция
exit
Add
A+ включение автоматич. перехода на летнее/зимнее время
ОК
A-
отключение автоматич. перехода на летнее/зимнее время
ОК
S+
включение SNTP-протокола
OK
S-
отключение SNTP-протокола
OK
S?
проблемы при работе с SNTP-сервером
ER
Er:#
TS
автоматический переход на летнее время
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#
TW
автоматический переход на зимнее время
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#
S=
изменение системного времени SNTP-сервером
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#
ST
установка времени администратором
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#
SD установка даты администратором
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#
TZ установка переменной TZ администратором
OK
ER
Ov:ДВ Nv:ДВ
Ov:ДВ Nv:ДВ Er:#

Приложение Е. Системные журналы изделия 251
В графе Add:
ДВ – дата и время в стандартном формате (hh:mm:ss dd-mm-yy);
Ov – старые дата и время;
Nv – новые дата и время;
Er:#
–символ # означает код; возможные значения:
101
– не дождались ответа от сервера;
102
– проблемы с чтением файла sntp_tcp.ema;
103
– в конфигурации изделия не задано ни одного SNTP-сервера;
1
– не хватает оперативной памяти;
2
– ошибка при изменении значения переменной TZ;
22
– ошибка при изменении даты/времени;
100
– SNTP-сервер дал коррекцию времени вне заданного интервала.
3. Журнал LOG_TCP.EMA
В файле LOG_TCP.EMA дублируется информация файла LOG.EMA, относящаяся к работе подсистемы
Параметры [Компонент TCP/IP]. Кроме того, в файл LOG_TCP.EMA заносятся записи, в которых фиксируется прохождение через маршрутизатор изделия тех IP-датаграмм, для которых в правилах IP- фильтрации установлен режим фиксации IP-датаграмм (см. раздел 3.2.1.9, с. 108).
Формат записей фиксации проходящих через маршрутизатор изделия датаграмм
На каждую датаграмму, подлежащую фиксации, в файле LOG_TCP.EMA формируется до 4 строк информации.
В начале каждой строки ставится префикс 1f:, 2f:, 3f: или 0f:.
Специальный формат префиксов позволяет быстро отобрать из всего многообразия записей файла
LOG_TCP.EMA только записи фиксации датаграмм (по контексту "f: "). Кроме того, префикс определяет назначение (и формат) записи информации о фиксируемой датаграмме.
1f: – информация об элементе фильтра (о правиле), вызвавшем запись в LOG-файл;
2f: – расшифровка полей IP-заголовка датаграммы;
3f: – расшифровка заголовков протоколов, вложенных в IP;
0f: – строка-разделитель.
Записи с префиксами 1f:, 2f:, и 0f: формируются для всех датаграмм. Запись с префиксом 3f: формируется только для датаграмм, обеспечивающих транспортировку пакетов протоколов TCP, UDP и ICMP.
Первая строка (данные элемента фильтра):
1f: hh:mm:ss dd:mm:yy name fname[N]status prot flag L-M ADR_from/bit->ADR_to/bit LOG
hh:mm:ss dd-mm-yy – время и дата записи в LOG-файл;
name – имя интерфейса, через который передается датаграмма;
fname – имя фильтра;
N – порядковый номер сработавшего правила (элемента фильтра).
Далее следует в текстовом формате содержание сработавшего элемента фильтра:
status – значение параметра Режим (возможные значения: разрешить, запретить, сбросить);
prot
– значение параметра Протокол (возможные значения: ALL, ICMP, TCP, UDP);
flag
– значение flagow TCP (возможные значения: _ (пробел), SYN, ACK);
L-M – диапазон номеров портов;
ADR_from/bit – адрес отправителя и количество значащих бит в адресе отправителя;
ADR_to/bit – адрес получателя и количество значащих бит в адресе получателя;
LOG - признак записи в LOG-файл (параметр элемента фильтра Фиксировать имеет значение Да).
Вторая строка (расшифровка полей IP-заголовка датаграммы):
2f: IP: ADR_from->ADR_to len XX ihl XX ttl XX prot XX tos XX id XX offs XX DF MF

252
Приложение Е. Системные журналы изделия
ADR_from
– адрес отправителя;
ADR_to – адрес получателя;
len XX
– длина датаграммы в байтах (заголовок + данные);
ihl XX – длина IP-заголовка в байтах;
ttl XX – значение поля TTL;
prot XX
– значение поля Protocol;
tos XX
– значение поля ToS, если оно не равно нулю;
id XX offs XX
– идентификатор датаграммы и смещение данных
(только для фрагментированных датаграмм: установлен флаг MF или offset!=0);
DF MF
– флаги DF и MF, если они установлены.
Третья строка (расшифровка заголовков протоколов, вложенных в IP). Наличие третьей строки определяется значением поля Protocol
в IP-заголовке датаграммы (значение prot xx во второй строке):
prot 6 – соответствует протоколу TCP;
prot 17 – соответствует протоколу UDP;
prot 1 – соответствует протоколу ICMP.
Заголовки остальных протоколов не расшифровываются, третья строка с префиксом 3f: для них не формируется.
Расшифровка заголовка протокола TCP, вложенного в IP:
3f: TCP: Port_from->Port_to seq xXXXX [Ack xXXXX] flag Wnd XX [UP xXXXX] MSS XXXX
Port_from – порт отправителя;
Port_toпорт получателя;
seq xXXXX – значение поля Sequence Number;
Ack xXXXX – значение поля Acknowledgment Number (поле присутствует, если установлен флаг ACK);
Flag
– установленный флаг (возможные значения: FIN, SYN, RST, PSH, ACK, URG);
Wnd XX
– размер окна;
UP xXXXX
– значение поля Urgent Pointer (поле присутствует, если установлен флаг URG);
MSS XXXX – значение опции Maximum Segment Size (если она присутствует в заголовке).
Расшифровка заголовка протокола UDP, вложенного в IP:
3f: UDP: Port_from->Port_to len XX
Port_from – порт отправителя;
Port_to – порт получателя;
len XX
– длина UDP-пакета в байтах .
Расшифровка заголовка протокола ICMP, вложенного в IP:
3f: ICMP: type code XX
type – тип (для типов меньше 16 выводится словесная интерпретация типа);
1   ...   40   41   42   43   44   45   46   47   48


написать администратору сайта