Ниже представлен пример базовой последовательности шагов по настройке Windows Server в качестве резервного (вторичного) DNS-сервера. Предположим, что:

• SRV1-DT – сервер, на котором будет размещена роль резервного DNS.
• SRV-Primary – основной DNS-сервер.

Если у вас иная инфраструктура (например, вы используете Linux/BIND или другие инструменты автоматизации), можно адаптировать данные шаги под вашу среду.

---

1. Установка роли DNS (если не установлена)

1. Откройте Server Manager на SRV1-DT.

2. Выберите в левой панели «Manage» → «Add Roles and Features».

3. Далее следуйте мастеру установки ролей:

   • Выберите «Role-based or feature-based installation».
   • Выберите нужный сервер (SRV1-DT).
   • В списке ролей установите флажок «DNS Server».
   • Подтвердите установку и дождитесь завершения.

4. Проверьте, что служба DNS установлена и запущена:

   • Зайдите в «Tools» → «DNS» в Server Manager.
   • Либо проверьте состояние служб через «Services (Службы)».

---

2. Настройка резервного (вторичного) DNS

1. Откройте консоль управления DNS на SRV1-DT:

   • «Server Manager» → «Tools» → «DNS».

2. Раскройте дерево «Forward Lookup Zones» (или «Области прямого просмотра имён»), если необходимо настроить вторичный DNS для прямой зоны.
   Аналогично – «Reverse Lookup Zones» для обратной.

3. Создание вторичной зоны:

   1. Кликните правой кнопкой мыши на «Forward Lookup Zones» → «New Zone…».
   2. Запустится «New Zone Wizard»:
      • Zone Type: выберите «Secondary zone» (вторичная зона).
      • Zone Name: укажите имя DNS-зоны, точно совпадающее с тем, что уже настроено на основном DNS-сервере (например, example.local).
      • Master DNS server: введите IP-адрес основного DNS-сервера (SRV-Primary).

        Убедитесь, что ваш основной DNS-сервер настроен на разрешение переноса зоны (zone transfer) к SRV1-DT.

      • Завершите настройку, нажав «Finish».

4. Проверка переноса зоны:

   • После создания вторичной зоны в DNS-консоли вы увидите зону со статусом «Transfer in progress» или «Waiting…».
   • Если всё настроено корректно, содержимое зоны скопируется с основного сервера (SRV-Primary) на SRV1-DT.
   • Для ручной проверки можно кликнуть правой кнопкой мыши по нужной зоне и выбрать «Transfer from Master».

---

3. Разрешение переноса зоны на основном DNS-сервере

Если на основном DNS-сервере уже разрешён перенос зоны всем серверам, или выбран «Any server», то дополнительной настройки может не потребоваться. Если же у вас ограничен список допустимых IP-адресов, убедитесь, что IP SRV1-DT включён в разрешённые источники запросов.

На SRV-Primary (основном сервере) в консоли DNS:

1. Откройте свойства зоны (клик правой кнопкой мыши → «Properties»).
2. На вкладке «Zone Transfers» (или «Перенос зоны»):
   • Поставьте галочку «Allow zone transfers».
   • Выберите «Only to servers listed on the Name Servers tab» либо «Only to the following servers», если хотите жёстко задать IP-адреса.
   • Убедитесь, что SRV1-DT (по IP-адресу) добавлен в список.

---

4. Тестирование работы

1. С SRV1-DT выполните команды проверки DNS (можно через PowerShell или командную строку):

   shell
   nslookup example.local

   Убедитесь, что разрешение имён работает корректно.

2. При необходимости выполните аналогичную проверку на клиенте: пропишите SRV1-DT как DNS-сервер (вторичный) в настройках сети и проверьте разрешение имён.

3. При отключении/недоступности основного DNS-сервера (SRV-Primary) вторичный сервер (SRV1-DT) должен продолжать отвечать на запросы по зонам, данные которых он успел получить в процессе переноса (zone transfer).

---

5. Дополнительные рекомендации

• Регулярный перенос зоны: По умолчанию вторичный DNS периодически запрашивает обновления у основного. При желании можно настроить интервалы обновления (Refresh, Retry) в свойствах зоны на основном сервере.
• Мониторинг: Используйте события в «Event Viewer» и консоль DNS для отслеживания ошибок или предупреждений по переносу зоны.
• Безопасность: Если необходимо ограничить передачу зоны, используйте ограничения в свойствах зоны на основном сервере и настройте необходимые параметры брандмауэра для порта 53 (TCP/UDP).

---

Таким образом, вы настраиваете SRV1-DT как резервный (вторичный) DNS-сервер, который дублирует зоны с основного сервера и обеспечивает отказоустойчивость в вашей DNS-инфраструктуре.

Ниже приведён пример базовой последовательности шагов по настройке вторичного (резервного) DNS-сервера на ALT Linux с использованием BIND. Предположим, что:

• SRV1-DT – сервер на ALT Linux, на котором будет размещён второй (резервный) DNS.
• SRV-Primary – основной DNS-сервер (может работать на любой платформе, главное — корректно настроить зону и разрешить перенос зоны).

Данный пример можно легко адаптировать и под другие RPM-системы (RHEL/CentOS, Fedora, OpenSUSE), а также под Debian/Ubuntu-семейство.

---

1. Установка BIND

На ALT Linux обычно пакет BIND называется bind или bind9. Устанавливаем и проверяем, что служба работает:

bash
sudo apt-get update
sudo apt-get install bind9

(В зависимости от используемого репозитория и среды, вместо apt-get в ALT Linux может использоваться apt-rpm или aptitude install bind9. Либо вы можете установить bind с помощью dnf/rpm – смотря какая у вас версия ALT Linux. При необходимости скорректируйте команду.)

Далее убеждаемся, что служба включена и запущена:

bash
sudo systemctl enable named
sudo systemctl start named

(Уточните точное название сервиса, возможно он называется named.service в ALT Linux.)

---

2. Настройка конфигурационных файлов BIND

По умолчанию основные файлы BIND находятся в каталоге:

text
/etc/named.conf
/etc/named/  (в некоторых случаях /var/named/)
/etc/bind/   (вариант для Debian-семейства)

В ALT Linux чаще всего используется /etc/named.conf как главный файл конфигурации. В нём прописываем «зоны», «options» и т.д.

2.1. Основной файл /etc/named.conf

Простейшая структура (в контексте резервного DNS) может выглядеть так:

bash
options {
    directory "/var/named";          // Корневой каталог для зон, логов и т.д.
    listen-on port 53 { any; };      // Можно ограничить конкретным IP-адресом
    allow-query { any; };            // Разрешить любые запросы или настроить ACL
    recursion yes;                   // Разрешить рекурсивные запросы (по необходимости)
    
    // Рекомендуется ограничить transfer только нужными ACL
    allow-transfer { none; };        // По умолчанию запрещаем перенос зоны
};

//
// Ключевой момент - добавить вторичную (secondary) зону
// Предположим, у нас зона example.local
//
zone "example.local" IN {
    type slave;                       // Тип - вторичная зона (slave)
    masters { 192.168.0.10; };        // IP-адрес вашего основного (master) DNS-сервера (SRV-Primary)
    file "slave/example.local";       // Локальный файл, куда сохраняется копия зоны
    allow-query { any; };            // Разрешаем клиентам запрашивать зону
    // При необходимости можно разрешить следующим серверам копировать от нас
    // allow-transfer { 192.168.0.15; };
};

//
// Аналогично для reverse-зоны (при необходимости)
//
zone "0.168.192.in-addr.arpa" IN {
    type slave;
    masters { 192.168.0.10; };
    file "slave/0.168.192.in-addr.arpa";
    allow-query { any; };
};

Важный момент: Директиву masters { ... }; следует обязательно указать с реальным IP-адресом основного DNS-сервера. На основном сервере должна быть включена опция «разрешить перенос зоны» (allow zone transfers) для данного IP (SRV1-DT).

2.2. Создаём каталог для slave-зон

BIND должен иметь возможность записывать туда файл зоны. В ALT Linux каталог часто создаётся автоматически, но уточним:

bash
sudo mkdir -p /var/named/slave
sudo chown named:named /var/named/slave   // Убедиться, что владелец - пользователь, под которым работает named

(Пользователь и группа могут отличаться, в зависимости от сборки (например, bind:bind или named:named).)

---

3. Разрешение переноса зоны на основном сервере

На SRV-Primary (основном сервере) – будь это BIND, Windows DNS или PowerDNS – нужно разрешить переноса зоны к IP-адресу SRV1-DT.

1. В BIND (пример конфигурации master-зоны):

   bash
   zone "example.local" IN {
       type master;
       file "/var/named/master/example.local";
       allow-transfer { 192.168.0.20; }; // IP SRV1-DT
       also-notify { 192.168.0.20; };    // Уведомлять вторичный сервер об изменениях
   };

   Здесь 192.168.0.20 – это IP-адрес вашего резервного DNS (SRV1-DT).
   Параметр also-notify не обязателен, но ускоряет синхронизацию.

2. В Windows DNS:

   • Откройте свойства зоны → «Zone Transfers»
   • Включите «Allow zone transfers» → «Only to the following servers»
   • Добавьте IP SRV1-DT.

---

4. Проверка конфигурации

1. Проверка синтаксиса BIND:

   bash
   sudo named-checkconf /etc/named.conf

   Убедитесь, что нет ошибок синтаксиса.

2. Перезапускаем BIND, чтобы применить изменения:

   bash
   sudo systemctl restart named

   Проверьте журнал (например, journalctl -u named -f), нет ли там ошибок при старте.

3. Проверяем, подтягивается ли зона:

   • В логах named должно быть упоминание о получении зоны от мастер-сервера.
   • Можно дополнительно посмотреть, что в каталоге /var/named/slave/ появился файл example.local (или иное имя), соответствующий вторичной зоне.

4. Тестируем nslookup/dig:

   bash
   dig @192.168.0.20 example.local SOA

   или

   bash
   dig @192.168.0.20 www.example.local

   Должны прийти корректные ответы, а в поле AUTHORITY SECTION вы увидите, что ответ идёт с вторичного сервера.

---

5. Настройка автозапуска (если не включён)

Убедитесь, что служба named стартует автоматически при загрузке. Обычно достаточно:

bash
sudo systemctl enable named

(Повторяем, иногда название юнита может отличаться – смотрите в systemctl list-unit-files | grep named.)

---

6. Рекомендации по безопасности и оптимизации

1. Ограничение zone transfer. Убедитесь, что перенос зоны разрешён только нужным хостам. Настройте allow-transfer и also-notify на мастер-сервере.
2. DNSSEC. При необходимости настройте DNSSEC или хотя бы включите валидацию для внешних запросов (опционально).
3. ACL (Access Control Lists). В BIND можно использовать ACL для гибкого управления списками разрешённых IP или сетей.
4. Просмотр логов. Настройте логирование в /var/log/messages или отдельный лог, чтобы оперативно видеть проблемы с zone transfer.
5. Рекурсия. Если сервер предназначен только для обслуживания зоны, и нет необходимости раздавать рекурсивные ответы внутренним клиентам, можно отключить рекурсию (recursion no;).

---

Итог

Чтобы настроить SRV1-DT на ALT Linux как резервный DNS:

1. Установите BIND:

   bash
   sudo apt-get install bind9

2. Отредактируйте /etc/named.conf, добавив вторичную (slave) зону:

   bash
   zone "example.local" IN {
       type slave;
       masters { 192.168.0.10; };
       file "slave/example.local";
   };

3. Разрешите передачу зоны (zone transfer) на SRV-Primary.
4. Перезапустите службу named и проверьте логи.
5. Убедитесь, что команда dig @<IP SRV1-DT> example.local даёт корректный ответ.

Таким образом, SRV1-DT получает актуальные записи DNS от основного сервера (SRV-Primary) и продолжает обслуживать запросы даже при недоступности мастер-сервера.

Ниже приведены обобщённые рекомендации по установке EcoRouter в виртуальную машину VMware (Workstation, Player или ESXi). Порядок действий может незначительно отличаться в зависимости от используемой версии VMware и самой сборки EcoRouter, но общие принципы будут схожими.

---

1. Подготовка образа

1. Скачайте ISO-образ EcoRouter (или другой образ/дистрибутив, на базе которого сделан EcoRouter) с официального сайта или из доверенного источника.
2. Убедитесь, что файл ISO цел (желательно сравнить контрольную сумму, если она предоставляется).

---

2. Создание виртуальной машины в VMware

Дальнейшие действия описаны для VMware Workstation/Player как наиболее частого варианта использования на рабочей станции. Если у вас ESXi, логика та же, но интерфейс немного отличается.

1. Запустите VMware Workstation (или Player).

2. Создайте новую виртуальную машину:

   • Нажмите «Create a New Virtual Machine» (или «Файл» → «New Virtual Machine»).
   • В «New Virtual Machine Wizard» выберите «Typical (recommended)» или «Custom».
   • Укажите ISO-образ EcoRouter в поле «Installer disc image file (iso)» (если мастер распознаёт дистрибутив автоматически).

     Если VMware не распознаёт дистрибутив автоматически, вам может понадобиться выбрать гостевую ОС вручную (например, Linux → Other Linux 2.6.x kernel or later).

3. Настройте параметры:

   • Имя виртуальной машины (Name): укажите понятное имя, например «EcoRouter-VM».
   • Расположение (Location): выберите папку на диске, где будут храниться файлы виртуальной машины.
   • Тип ОС: выберите Linux (если EcoRouter основан на Linux). В некоторых случаях может потребоваться выбрать «Other Linux 64-bit».
   • Аппаратные ресурсы (Hardware):
     • Процессор: 1–2 vCPU (по рекомендации, но зависит от ваших нужд).
     • Оперативная память: минимум 512 МБ или 1 ГБ (лучше уточнить требования EcoRouter).
     • Жёсткий диск: 4–8 ГБ (или более, по необходимости).
     • Сетевые адаптеры: обычно EcoRouter требует минимум 2 сетевых адаптера (WAN/LAN). При желании можно добавить несколько адаптеров.
       • Адаптеры можно сконфигурировать как «bridged» (прямой доступ к физической сети) или «NAT», в зависимости от вашей топологии.
   • Тип виртуального диска: выберите «SCSI» или «SATA» (по умолчанию). Размер выделите согласно рекомендациям (4–8 ГБ минимум, в зависимости от плана использования EcoRouter).

4. Завершите создание виртуальной машины.

---

3. Установка EcoRouter

1. Запустите виртуальную машину (нажмите «Power on this virtual machine»).
2. При загрузке с ISO-образа вы увидите меню установки EcoRouter (либо аналогичное меню, если EcoRouter базируется на типовом дистрибутиве Linux).
3. Следуйте инструкциям установщика:
   • Выберите язык установки (если предоставляется выбор).
   • Укажите настройки сетевых карт, если мастер установки EcoRouter запрашивает это на раннем этапе.
   • Укажите параметры дисковой разметки (обычно автоматическая разметка подойдёт для виртуальной машины).
4. Дождитесь завершения копирования файлов и конфигурации.

В некоторых сборках EcoRouter может быть предустановленная система, которая загружается сразу в Live-режим (без отдельного шага «установки»). Тогда вам нужно будет либо вручную сконфигурировать (если есть консоль/веб-интерфейс), либо запустить программу «Install», чтобы перенести её на диск виртуальной машины.

5. Перезагрузите систему после окончания установки. Убедитесь, что в настройках виртуальной машины ISO-образ снят с привода, чтобы VM не загружалась повторно с ISO.

---

4. Первичная конфигурация

После первой загрузки установленного EcoRouter:

1. Убедитесь, что сетевые адаптеры (WAN/LAN) распознаны:
   • Если EcoRouter предоставляет веб-интерфейс, постарайтесь получить к нему доступ (например, через http://192.168.1.1 — адрес может отличаться).
   • Если доступ только по консоли, настройте/проверьте сетевые интерфейсы (например, в /etc/network/interfaces или через утилиты, которые EcoRouter предоставляет).
2. Задайте логин/пароль администратора (если требуется) и произведите базовые настройки (WAN-подключение, локальная сеть, маршруты и т. п.).
3. Проверьте соединение с внешней сетью (пинг в Интернет или к соседним хостам).
4. Настройте необходимый функционал (DHCP, firewall и другие сервисы, если EcoRouter их поддерживает).

---

5. Рекомендации и тонкости

1. VMware Tools (или open-vm-tools)
   Если EcoRouter базируется на Linux-системе с поддержкой пакетов, возможно, есть смысл установить open-vm-tools для корректной работы с VMware (корректное отображение статуса, время, сетевые настройки и пр.). Но не все специализированные дистрибутивы это поддерживают «из коробки».
2. Тип виртуального адаптера
   В настройках VMware для сетевой карты можно выбрать «e1000», «VMXNET3» и т. д. Если EcoRouter поддерживает VMXNET3, это даст лучшую производительность.
3. Автозапуск
   Если вы размещаете EcoRouter на VMware ESXi в качестве маршрутизатора/файрвола для части инфраструктуры, не забудьте настроить «Autostart» виртуальной машины, чтобы она автоматически запускалась при перезагрузке гипервизора.
4. Безопасность
   • Если EcoRouter отвечает за маршрутизацию или безопасность (файрвол), проверьте, что VMware-сеть корректно распределена по виртуальным свитчам (vSwitch) или сетевым сегментам.
   • Закройте неиспользуемые порты и убедитесь в правильных правилах NAT/Firewall.
5. Резервные копии (Backups)
   Регулярно делайте снапшоты виртуальной машины или используйте механизмы бэкапа VMware, чтобы сохранить конфигурацию EcoRouter на случай сбоев.

---

Итог

1. Загрузите ISO EcoRouter и подготовьте к установке.
2. Создайте VM в VMware, указав в качестве установочного диска — ISO-образ.
3. Установите EcoRouter, следуя шагам установщика.
4. Сконфигурируйте сетевые адаптеры (WAN/LAN), убедитесь в доступности веб-интерфейса (если он имеется) или консоли для дальнейшего управления.
5. Проверьте маршрутизацию, интернет-подключение и дополнительные сервисы (DHCP, Firewall и т. п.).

После этого EcoRouter будет работать в качестве программного маршрутизатора/файрвола в среде VMware.

Ниже приведены обобщённые шаги для настройки NTP-синхронизации в вашей сети с учётом следующих условий:

1. Сервером NTP выступает SRV1-HQ, имеющий стратум 5.
2. Источник внешней синхронизации (вышестоящий сервер) — ntp2.vniiftri.ru.
3. Все сетевые устройства (клиенты) должны получать время от SRV1-HQ.
4. Там, где возможно, используется chrony (предпочтительнее, чем классический ntpd).
5. На всех устройствах установлен московский часовой пояс (UTC+3).

Примечание: В зависимости от используемых ОС (Linux/Windows/другие) конкретная реализация может отличаться, однако основные принципы будут схожими.

---

1. Настройка сервера NTP (SRV1-HQ)

1.1. Установка и настройка chrony

1.1.1. Установка chrony (на Linux)

В дистрибутивах RHEL/CentOS/AlmaLinux/RockyLinux:

bash
sudo yum install chrony

В Debian/Ubuntu:

bash
sudo apt-get update
sudo apt-get install chrony

В ALT Linux:

bash
sudo apt-get install chrony

(Либо используйте dnf, aptitude и т.п. в зависимости от версии.)

1.1.2. Основные параметры в /etc/chrony.conf

Ниже пример базового содержимого /etc/chrony.conf на SRV1-HQ:

conf
# Указываем вышестоящий NTP-сервер (ntp2.vniiftri.ru)
server ntp2.vniiftri.ru iburst

# Указываем локальный стратум - 5
# Это нужно, чтобы при отсутствии связи с внешним NTP,
# SRV1-HQ продолжал раздавать время, объявляя себя 5-м уровнем.
local stratum 5

# Разрешаем клиентам в локальной сети получать от нас время.
# Если сервер расположен в сети 192.168.0.0/24, то:
allow 192.168.0.0/24

# Файл для записи информации о дрейфе часов
driftfile /var/lib/chrony/drift

# Сколько позволять "скачкам" времени при запуске
makestep 1.0 3

Обратите внимание на директиву local stratum 5:

• local говорит chrony, что при отсутствии доступных внешних серверов он может «становиться» локальным референсом.
• stratum 5 указывает требуемый уровень.

При необходимости расширьте/измените сеть в директиве allow — в зависимости от того, кто будет брать время с SRV1-HQ.

1.1.3. Запуск и автозапуск chrony

bash
sudo systemctl enable chronyd
sudo systemctl start chronyd

Проверяем статус:

bash
systemctl status chronyd

1.1.4. Проверка синхронизации

1. Команда:

   bash
   chronyc sources -v

   Покажет список источников и их состояние (reach, задержка, offset и т.д.).
2. Команда:

   bash
   chronyc tracking

   Покажет, к кому сервер сейчас привязан (System time / Reference ID / Stratum / Ref time и прочее).

Если всё корректно, вы увидите, что SRV1-HQ получает время от ntp2.vniiftri.ru (stratum 4 или ниже), а сам при этом объявляет себя stratum 5 для внутренних клиентов (когда внешняя связь недоступна).

---

1.2. Альтернативный вариант: ntpd

Если по каким-то причинам нужно использовать ntpd (например, в старых системах):

1. Установка:

   bash
   sudo yum install ntp
   # или
   sudo apt-get install ntp

2. Файл /etc/ntp.conf (аналогичные параметры):

   conf
   # Источник внешнего времени
   server ntp2.vniiftri.ru iburst
   
   # Задаём стратум 5 при отсутствии внешних источников
   fudge 127.127.1.0 stratum 5
   
   # Указываем "локальный" драйвер
   server 127.127.1.0
   
   # Разрешаем клиентам в локальной сети
   restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap
   
   # Driftfile
   driftfile /var/lib/ntp/ntp.drift

3. Запуск:

   bash
   sudo systemctl enable ntpd
   sudo systemctl start ntpd

4. Проверка:

   bash
   ntpq -p

Однако, при прочих равных, chrony считается более современной и гибкой реализацией.

---

1.3. Установка московского часового пояса

На Linux:

bash
sudo timedatectl set-timezone Europe/Moscow

Проверяем:

bash
timedatectl

В поле Time zone должно стоять Europe/Moscow (MSK, +0300).

---

2. Настройка клиентских устройств

Все остальные устройства (серверы, рабочие станции, маршрутизаторы, коммутаторы и т.п.) должны быть сконфигурированы так, чтобы они получали время от SRV1-HQ. Ниже — общая логика.

2.1. Клиенты на Linux (chrony)

1. Устанавливаем chrony (по аналогии с сервером).
2. В /etc/chrony.conf основные строки будут:

   conf
   # В качестве источника времени используем SRV1-HQ (предположим 192.168.0.10)
   server 192.168.0.10 iburst
   
   # Разрешаем "большие скачки" при запуске
   makestep 1.0 3
   
   driftfile /var/lib/chrony/drift

3. Включаем и запускаем:

   bash
   sudo systemctl enable chronyd
   sudo systemctl start chronyd

4. Проверяем, что клиент синхронизируется:

   bash
   chronyc sources -v
   chronyc tracking

5. Ставим московский часовой пояс (если ещё не установлен):

   bash
   sudo timedatectl set-timezone Europe/Moscow

2.2. Клиенты на Linux (ntpd)

Если используется ntpd, то в /etc/ntp.conf указываем:

conf
server 192.168.0.10 iburst
driftfile /var/lib/ntp/ntp.drift

Аналогично прописываем таймзону:

bash
sudo timedatectl set-timezone Europe/Moscow

И запускаем службу:

bash
sudo systemctl enable ntpd
sudo systemctl start ntpd

---

2.3. Клиенты на Windows

Если в сети есть Windows-серверы/станции, которые должны брать время у SRV1-HQ:

1. Запускаем командную строку (cmd) или PowerShell от имени администратора.
2. Останавливаем встроенную службу W32Time и конфигурируем её:

   powershell
   net stop w32time
   w32tm /config /syncfromflags:manual /manualpeerlist:"192.168.0.10"
   w32tm /config /reliable:yes
   w32tm /config /update
   net start w32time

3. Проверяем статус:

   powershell
   w32tm /query /status
   w32tm /query /peers

4. Часовой пояс (в Windows) задаём в «Панель управления» → «Дата и время» → «Часовые пояса», выбираем «(UTC+3:00) Москва, Санкт-Петербург».

Важно: Если это контроллер домена AD, там своя логика синхронизации через Forest Root PDC, но суть та же — можно указать внешний NTP (SRV1-HQ).

---

2.4. Сетевые устройства (маршрутизаторы, коммутаторы)

Для роутеров (Cisco, MikroTik, Juniper и т.п.) обычно достаточно указать IP-адрес SRV1-HQ в качестве NTP-сервера. Примеры:

Cisco IOS:

text
conf t
  ntp server 192.168.0.10
  clock timezone MSK 3
end

MikroTik:

text
/system ntp client
set enabled=yes primary-ntp=192.168.0.10
/system clock
set time-zone-name=Europe/Moscow

Juniper (JunOS):

text
set system ntp server 192.168.0.10
set system time-zone Europe/Moscow

(Синтаксис может меняться в зависимости от конкретной модели и версии прошивки.)

---

3. Проверка и верификация

1. На SRV1-HQ:

   • Убедитесь, что chrony/ntpd подтянуло корректное время от ntp2.vniiftri.ru.
   • chronyc sources -v или ntpq -p покажет статус.
   • При отсутствии связи с интернетом SRV1-HQ будет раздавать время как stratum 5 (за счёт local stratum 5 / fudge 127.127.1.0 stratum 5).

2. На клиентах:

   • Убедитесь, что в качестве опорного сервера указан SRV1-HQ (IP 192.168.0.10 или любой, который вы назначили).
   • Проверьте drift/offset — должны быть разумные значения (обычно <10–20 мс внутри локальной сети).

3. Часовой пояс:

   • У всех устройств, где вы выставили Europe/Moscow, локальное время должно совпадать с московским.
   • Если нужна точность, обязательно учитывайте, что NTP синхронизирует UTC-время, а локальный «часовой пояс» лишь отображает его в нужном часовом поясе.

---

Итоговая схема

1. SRV1-HQ (Linux + chrony) получает время от ntp2.vniiftri.ru (стратум 4 или ниже) и при этом объявляет себя stratum 5, раздавая время во внутреннюю сеть.
2. Все остальные машины (Linux, Windows, маршрутизаторы) указывают SRV1-HQ как NTP-сервер.
3. На всех устройствах выставлен часовой пояс Europe/Moscow.
4. При пропадании связи с внешним сервером ntp2.vniiftri.ru, время во внутренней сети остаётся согласованным, так как SRV1-HQ продолжает работать как локальный сервер NTP.

Таким образом, достигается:

• Единое время во всей сети.
• Заданная иерархия (SRV1-HQ — центральный сервер, все остальные — клиенты).
• Использование современного демона chrony там, где это доступно.
• Московский часовой пояс на всех устройствах для локального отображения времени.