Сравнение версий

Ключ

  • Эта строка добавлена.
  • Эта строка удалена.
  • Изменено форматирование.

Оглавление

Информация
titleДанная статья применима к:
  • Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.8)

Якорь
Введение
Введение
Введение

Первичная диагностика производится на настроенном контроллере

...

домена FreeIPA и предназначена для оценки текущего состояния домена

...

. Порядок установки и настройки контроллера домена см. в

...

...

.

...

Диагностика позволяет своевременно обнаружить

...

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

...

тестов, дополняющих друг друга. Для автоматических тестов будет использован инструмент ipa-healthcheck. Ознакомиться с его функциональными возможностями более подробно можно в статье FreeIPA Health Check. Обзор функциональных возможностей

Термины

ТерминПояснение
Источник (source)

...

Набор тестов для сбора данных (например, ipahealthcheck.ipa.certs). Полный список источников см. Обзор источников и проверок для диагностики и мониторинга FreeIPA

...

...

Тест (check)

...

Конкретный тест (проверка) в

...

составе источника (например, IPADNSSystemRecordsCheck). Полный список

...

...

CLI

...

...

Якорь
DT
DT
DogTag

Сокращенное название проекта Dogtag Certificate System
Встроенный центр сертификации контроллеров FreeIPA (см. FreeIPA: Подключение центра сертификации DogTag в Astra Linux Common Edition).

...

Не входит в состав основного репозитория Astra Linux Special Edition

...

Якорь

...

CA

...

CA

...

CA

Аббревиатура от Certificate

...

Authority.

...

Подсистема, отвечающая за

...

выпуск, подпись и отзыв цифровых сертификатов, а также публикацию списков отозванных сертификатов (CRL) и

...

проверку валидности сертификатов (например, с использованием протокола OCSP)

Якорь

...

DNS

...

DNS

...

Главный файл конфигурации подсистемы DogTag CS.
Создается при инициализации контроллера ЕПП FreeIPA с центром сертификации DogTag (см. FreeIPA: Подключение центра сертификации DogTag в Astra Linux Common Edition).

В DogTag подсистемы запускаются независимо, каждая со своим CS.cfg:

  • /etc/pki/pki-tomcat/ca/CS.cfg настраивает CA,

  • /etc/pki/pki-tomcat/kra/CS.cfg настраивает KRA.

...

Аббревиатура от Domain Name System.
Иерархическая распределённая система, преобразующая доменные имена в IP-адреса и обратно в Интернете.

...

Аббревиатура от Lightweight Directory Access Protocol.
Протокол прикладного уровня для доступа и управления распределённой каталоговой службой, широко используется для хранения и поиска информации об учётных записях, группах и политиках в сетях.

...

Аббревиатура от Network Security Services.
Набор библиотек защитного преобразования, используемых приложениями и сервисами для работы с сертификатами, ключами и безопасными соединениями.

...

Аббревиатура от Directory Server
LDAP-сервер, реализованный на основе проекта 389 Directory Server, обеспечивающий хранение, поиск и модификацию данных каталоговой службы (учётные записи, группы, политики).

...

Аббревиатура от Replica Update Vector.
Набор счётчиков состояния репликации в DS, хранящийся на каждом узле; позволяет определить, какие изменения между всеми участниками топологии уже переданы, а какие ещё нужно синхронизировать.

...

Аббревиатура от Transport Layer Security (TLS) и Secure Sockets Layer (SSL).
Протоколы, обеспечивающие защитное преобразование и аутентификацию сетевых соединений в интернете и приложениях.

...

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

...

Аббревиатура от Fully Qualified Domain Name.
Полное доменное имя узла, включающее все уровни DNS-иерархии (например, host.example.com).

...

Аббревиатура от Key Distribution Center.
Компонент Kerberos, отвечающий за аутентификацию клиентов и выдачу Ticket Granting Tickets и сервисных билетов (TGS)

...

Аббревиатура от Ticket Granting Ticket.
В Kerberos-системе билет, выдаваемый KDC после аутентификации, позволяющий без повторного ввода пароля запрашивать сервисные билеты.

...

Аббревиатура от Distributed Numeric Assignment.
Плагин 389 Directory Server, который автоматически распределяет диапазоны POSIX UID/GID между серверами — выделяет каждому мастеру и реплике поддиапазон из общего пространства идентификаторов, обеспечивая их уникальность и отказоустойчивость при создании новых учётных записей и групп

...

Файл “key table” Kerberos, хранящий длинно-срочные ключи одного или нескольких принципалов. Используется сервисами для автоматической аутентификации без ввода пароля.

...

Схема взаимосвязей и соглашений репликации между IPA-серверами.

...

Аббревиатура от Active Directory.
Cлужба каталогов Microsoft для управления объектами Windows-домена (пользователи, компьютеры, политики). Использует LDAP, Kerberos и DNS для централизованной аутентификации и авторизации.

...

RID (Аббревиатура от Relative Identifier)
Относительный идентификатор, присваиваемый объектам при создании и становящийся частью SID.

SID (Аббревиатура от Security Identifier)
Уникальный идентификатор безопасности в Windows AD, состоящий из доменного S-идентификатора и RID

...

Аббревиатура от Identity, Policy, Audit.
Интегрированное решение для централизованного управления удостоверениями, политиками аутентификации и аудита на Linux/UNIX. Основано на LDAP, Kerberos, Dogtag и BIND.

Первичная диагностика Directory Server, включая репликацию

Предупреждение
titleВажно!

Для выполнения диагностических операций обязательно наличие прав суперпользователя и пароля администратора доменной службы LDAP.

Также для большинства диагностических операций требуется наличие билета Kerberos администратора домена. Получить билет Kerberos можно с помощь команды kinit, указав пароль пользователя — владельца билета. Например, для пользователя admin (имя администратора домена по умолчанию):

Command
kinit admin

Проверить наличие билета Kerberos можно с помощью команды klist

Command
klist

Например, для пользователя admin (имя администратора домена по умолчанию), вывод будет выглядеть так:

Блок кода
titleВывод
Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@TESTDOMAIN.TEST

Valid starting       Expires              Service principal
28.05.2025 12:50:01  29.05.2025 12:18:08  HTTP/ipasrv.testdomain.test@TESTDOMAIN.TEST
28.05.2025 12:50:01  29.05.2025 12:18:08  krbtgt/TESTDOMAIN.TEST@TESTDOMAIN.TEST

Ручная диагностика

  • Проверка имени хоста и DNS

    Предупреждение
    titleВажно!

    В случае сбоев при разрешении имени доменного имени сервера или DNS-записей проверьте и скорректируйте их настройки. Подробнее см. Настройка серверов для FreeIPA и Настройка сетевых подключений в Astra Linux.

    • Чтобы проверить корректную настройку полного доменного имени (FQDN) используется команда:

      Command

      hostname -f

      Ожидается, что hostname -f выдаст полное доменное имя сервера, например:

      Блок кода
      titleВывод
      ipasrv.ipadomain.loc
    • Чтобы проверить корректность настроек DNS, потребуется два шага:

      • Сделать прямой запрос (hostname → IP):

        Command

        dig +short A $(hostname -f)

        Раскрыть
        titleСправка
        Информация
        titleСправка

        Команда dig используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы. Предоставляется пакетом dnsutils и входит в базовый репозиторий.
        В примерах используется со следующими параметрами:

        • +short
          выводит только ответ без заголовков и дополнительных сведений,

        • A
          указывает на запрос A-записи (IPv4),

        • -x
          сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,

        • $(hostname -f) 
          командная подстановка, возвращающая FQDN, соответствующий текущему хосту,

        • $(hostname -i) 
          командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста.

        Ожидается, что команда вернет IPv4 адрес сервера, например:

        Блок кода
        titleВывод
        10.192.5.243
      • Сделать обратный PTR-запрос (IP → hostname):

        Command

        dig +short -x $(hostname -i)

        Раскрыть
        titleСправка
        Информация
        titleСправка

        Команда dig используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы. Предоставляется пакетом dnsutils и входит в базовый репозиторий.
        В примерах используется со следующими параметрами:

        • +short
          выводит только ответ без заголовков и дополнительных сведений,

        • A
          указывает на запрос A-записи (IPv4),

        • -x
          сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,

        • $(hostname -f) 
          командная подстановка, возвращающая FQDN, соответствующий текущему хосту,

        • $(hostname -i) 
          командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста.

        Ожидается, что команда вернёт полное доменное имя сервера, например:

        Блок кода
        titleВывод
        ipasrv.ipadomain.loc.

...

Проверка доступности сетевых портов

  • Для диагностики доступности сетевых портов в составе пакета freeipa-server предоставляется инструмент ipa-replica-conncheck. Требуется репликация с минимум двумя узлами: ведущим (master) и ведомым (slave/replica). Для выполнения диагностики:
    • На ведомом узле проверить доступность сетевых портов ведущего узла при помощи команды:
      Command
      sudo ipa-replica-conncheck -m ipasrv.testdomain.test -r TESTDOMAIN.TEST -k ipasrv.testdomain.test -p admin -w 12345678 -a
      Раскрыть
      titleСправка
      Информация
      titleСправка
      Command
      sudo ipa-replica-conncheck -m <HOST> -r <REALM> -k <HOST> -p <PRINCIPAL> -w <PASSWORD> -a

      Эта команда проводит двухфазную проверку сетевого взаимодействия между уже существующими ведущими и ведомыми узлами реплики FreeIPA. Сначала тестируется доступность TCP-портов ведущего узла (389, 636, 88, 464, 80, 443), а затем автоматически по SSH инициирует обратную проверку тех же портов с ведущего на ведомый узел. Ошибки «Failed to bind» при этом свидетельствуют лишь о занятости портов штатными службами, но не об их недоступности.

      Используются следующие параметры:

      • -m <HOST>
        указывает FQDN или IP-адрес ведущего узла, к которому ведомый узел должен подключиться в первой фазе проверки,

      • -r <REALM>
        имя IPA Kerberos области (realm) (обычно домен в верхнем регистре); без него инструмент не сможет получить билет и завершится ошибкой,

      • -k <HOST>
        FQDN или IP-адрес KDC для Kerberos аутентификации (по умолчанию совпадает с ведущим узлом),

      • -p <PRINCIPAL>
        имя Kerberos принципала (например, admin), под которым будет совершена аутентификация перед проверкой,

      • -w <PASSWORD>
        пароль указанного принципала (в кавычках, если содержит спецсимволы); является небезопасным, при отсутствии параметра инструмент запросит его интерактивно,

      • -a
        автоматически запускает на ведомом узле вторую фазу проверки: по SSH заходит на ведущий узел и выполняет ipa-replica-conncheck --replica <REPLICA> для диагностики связи ведущий → ведомый.

      Блок кода
      titleВывод
      Check connection from replica to remote master 'ipasrv.testdomain.test':
         Directory Service: Unsecure port (389): OK
         Directory Service: Secure port (636): OK
         Kerberos KDC: TCP (88): OK
         Kerberos Kpasswd: TCP (464): OK
         HTTP Server: Unsecure port (80): OK
         HTTP Server: Secure port (443): OK
      
      The following list of ports use UDP protocol and would need to be
      checked manually:
         Kerberos KDC: UDP (88): SKIPPED
         Kerberos Kpasswd: UDP (464): SKIPPED
      
      Connection from replica to master is OK.
      Start listening on required ports for remote master check
      389 tcp: Failed to bind
      636 tcp: Failed to bind
      88 tcp: Failed to bind
      88 udp: Failed to bind
      464 tcp: Failed to bind
      464 udp: Failed to bind
      80 tcp: Failed to bind
      443 tcp: Failed to bind
      Get credentials to log in to remote master
      Check RPC connection to remote master
      Retrying using SSH...
      Check SSH connection to remote master
      Execute check on remote master
    • Дополнительно вручную проверить порты 88 и 464 протокола UDP. Сделать это можно при помощи команды, на ведомом узле:
      Command
      nc -vuz ipasrv.testdomain.test 88 464
      Раскрыть
      titleСправка
      Информация
      titleСправка

      Команда сканирует указанные UDP-порты (88 и 464) на хосте ipasrv.testdomain.test, не передавая реальных данных и выводит подробную информацию о статусе каждого порта (открыт/закрыт). Поставляется с пакетом netcat-openbsd.
      Используются следующие параметры:

      • -v
        включает подробный режим,

      • -u
        заставляет использовать UDP вместо TCP при соединении с портами,

      • -z
        включает режим сканирования без передачи данных: netcat лишь пытается установить соединение и сразу его закрывает, что полезно при проверке портов.

      Блок кода
      titleВывод
      Connection to ipasrv.testdomain.test (10.192.5.244) 88 port [udp/kerberos] succeeded!
      Connection to ipasrv.testdomain.test (10.192.5.244) 464 port [udp/kpasswd] succeeded!

Проверка списков реплик и соглашений репликации

...

DNS

Аббревиатура от

...

Аббревиатуры от Directory Server <сокращенное название проверки> Lint Error.
Это специальный тип ошибки, который используется в механизме проверок 389-DS для описания несоответствий конфигурации и ACI (Access Control Instructions) в LDAP-сервере. Он возникает при выполнении команды dsctl <instance> healthcheck, служит для структурированного представления найденных проблем (код ошибки, уровень серьёзности, описание и контекст) для последующего ручного или автоматического их устранения.

Domain Name System.
Иерархическая распределённая система, преобразующая доменные имена в IP-адреса и обратно в Интернете

Якорь
LDAP
LDAP
LDAP

Аббревиатура от Lightweight Directory Access Protocol.
Протокол прикладного уровня для доступа к доменной службе каталогов, использующейся для хранения и поиска информации об учётных записях, группах и политиках в сетях

DN

Аббревиатура от Distinguished Name.
Уникальный идентификатор записи в доменной службе LDAP: строка из последовательности относительных имён в виде атрибут=значение, разделённых запятыми и идущих от конкретного объекта к корневому контексту

LDAP-суффиксы

Записи конфигурации топологии IPA, задающие управляемые DN — области каталогов, которые реплицируются как отдельные сегменты. В FreeIPA выделяются два основных суффикса:

  • domain — DN управляемого суффикса dc=<имя_домена>, dc=<зона>, включает данные учётных записей, групп, политик и параметров аутентификации,

  • ca — DN управляемого суффикса o=ipaca, содержит объекты инфраструктуры сертификатов DogTag CA (присутствует только на серверах с CA)

Якорь
RUV
RUV
RUV

Аббревиатура от Replica Update Vector.
Набор счётчиков состояния репликации в DS, хранящийся на каждом узле; позволяет определить, какие изменения между всеми участниками топологии уже переданы, а какие ещё нужно синхронизировать

Якорь
FQDN
FQDN
FQDN

Аббревиатура от Fully Qualified Domain Name.
Полное доменное имя узла, включающее все уровни DNS-иерархии (например, host.example.com)

Якорь
KDC
KDC
KDC

Аббревиатура от Key Distribution Center.
Компонент Kerberos, отвечающий за аутентификацию клиентов

Якорь
DNA
DNA
DNA

Аббревиатура от Distributed Numeric Assignment.
Подсистема доменной службы каталогов, которая автоматически распределяет диапазоны идентификаторов пользователей и групп (POSIX UID/GID) между контроллерами домена — выделяет каждому контроллеру домена поддиапазон из общего пространства идентификаторов, обеспечивая их уникальность и отказоустойчивость при создании новых учётных записей и групп

Якорь
РЕПЛ
РЕПЛ
Репликация

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

Якорь
ТР
ТР
Топология репликации

Схема взаимосвязей и соглашений репликации между контроллерами домена

Якорь
IPA
IPA
IPA

Аббревиатура от Identity, Policy, Audit.
Интегрированное решение для централизованного управления удостоверениями, политиками аутентификации и аудита на Linux/UNIX. Основано на LDAP, Kerberos, Dogtag и DNS

Первичная диагностика доменной службы LDAP, включая репликацию

Предупреждение
titleВажно!

Для выполнения диагностических операций обязательно наличие прав суперпользователя и пароля администратора доменной службы LDAP.

Также для большинства диагностических операций требуется наличие билета Kerberos администратора домена. Получить билет Kerberos можно с помощь команды kinit, указав пароль пользователя — владельца билета. Например, для пользователя admin (имя администратора домена по умолчанию):

Command
kinit admin

Удостовериться в наличии билета Kerberos можно с помощью команды klist:

Command
klist

Например, для пользователя admin (имя администратора домена по умолчанию), вывод будет выглядеть так:

Блок кода
titleВывод
Ticket cache: KEYRING:persistent:1000:1000
Default principal: admin@TESTDOMAIN.TEST

Valid starting       Expires              Service principal
28.05.2025 12:50:01  29.05.2025 12:18:08  HTTP/ipasrv.testdomain.test@TESTDOMAIN.TEST
28.05.2025 12:50:01  29.05.2025 12:18:08  krbtgt/TESTDOMAIN.TEST@TESTDOMAIN.TEST

Ручная диагностика

  • Проверка имени хоста и DNS записей

    Предупреждение
    titleВажно!

    В случае сбоев при разрешении доменного имени сервера или DNS записей скорректируйте их настройки. Подробнее см. Настройка серверов для FreeIPA и Настройка сетевых подключений в Astra Linux.

    • Для диагностики корректности настройки полного доменного имени (FQDN) используется команда:

      Command

      hostname -f

      Ожидается, что hostname -f вернет полное доменное имя сервера, например:

      Блок кода
      titleВывод
      ipasrv.testdomain.test
    • Для диагностики корректности записей DNS в составе пакета dnsutils предоставляется инструмент dig. Для выполнения диагностики:

      Раскрыть
      titleСправка
      Информация
      titleСправка

      Команда используется как инструмент для опроса DNS-серверов и получения ответов на DNS-запросы.
      В примерах используется со следующими параметрами:

      • +short
        выводит только ответ, без заголовков и дополнительных сведений,

      • A
        указывает на запрос A-записи (IPv4),

      • -x
        сокращённый синтаксис для запроса PTR-записи, используемой в обратном разрешении имен,

      • SRV
        указывает на запрос SRV-записи (служебной записи, содержащей приоритет, вес, порт и целевой хост),
      • $(hostname -f) 
        командная подстановка, возвращающая FQDN, соответствующий текущему хосту,

      • $(hostname -i) 
        командная подстановка, возвращающая IP-адрес, соответствующий текущему имени хоста,

      • $(hostname -d)
        командная подстановка, возвращающая домен, соответствующий текущему хосту.
      • Сделать прямой запрос (hostname → IP):

        Command

        dig +short A $(hostname -f)

        Ожидается, что команда вернет IPv4 адрес сервера, например:

        Блок кода
        titleВывод
        10.192.5.243
      • Сделать обратный PTR-запрос (IP → hostname):

        Command

        dig +short -x $(hostname -i)

        Ожидается, что команда вернёт полное доменное имя сервера с точкой на конце, например:

        Блок кода
        titleВывод
        ipasrv.testdomain.test.
      • Сделать SRV-запрос для службы LDAP по протоколу TCP:
        Command

        dig +short SRV _ldap._tcp.$(hostname -d)

        Ожидается, что команда вернет полное доменное имя каждого контроллера вместе с указанием приоритета, веса и порта в формате <приоритет> <вес> <порт> <FQDN>:
        Блок кода
        titleВывод
        10 100 389 ipasrv.testdomain.test.
        0 100 389 ipasrv.testdomain.test.
        0 100 389 ipacln.testdomain.test.
      • Сделать SRV-запросы для службы Kerberos по протоколам TCP и UDP:
        Command

        dig +short SRV _kerberos._udp.$(hostname -d)
        dig +short SRV _kerberos._tcp.$(hostname -d)

        Ожидается, что команда вернет полное доменное имя каждого контроллера вместе с указанием приоритета, веса и порта в формате <приоритет> <вес> <порт> <FQDN>:
        Блок кода
        titleВывод
        0 100 88 ipasrv.testdomain.test.
        0 100 88 ipacln.testdomain.test.
      • Сделать запрос к службе управления сертификатами ipa-ca:
        Command

        dig +short ipa-ca.$(hostname -d)

        Ожидается, что команда вернёт один или несколько IP-адресов тех узлов, которые выполняют функции CA:
        Блок кода
        titleВывод
        10.192.5.243
        10.192.5.244
  • Проверка доступности сетевых портов

    • Для диагностики доступности сетевых портов в составе пакета freeipa-server предоставляется инструмент ipa-replica-conncheck. Для выполнения диагностики достаточно наличия сетевого соединения между узлами; сама репликация может быть настроена позже.
      Информация

      Несмотря на условное использование терминов «ведущий узел» и «ведомый узел» в примерах команд, FreeIPA работает в мультимастерной топологии, где все серверы равноправны. В данном контексте:

      • ведущий узел (master, инициатор диагностики) — узел, с которого запускаются проверочные команды (отправляются тестовые запросы),
      • ведомый узел (slave/replica, приёмник диагностики) — узел, на который направляются эти запросы и который отвечает на них.
      • На ведомом узле протестировать доступность сетевых портов ведущего узла при помощи команды:
        Command
        sudo ipa-replica-conncheck -m ipasrv.testdomain.test -r TESTDOMAIN.TEST -k ipasrv.testdomain.test -p admin -w 12345678 -a
        Раскрыть
        titleСправка
        Информация
        titleСправка
        Command
        sudo ipa-replica-conncheck -m <HOST> -r <REALM> -k <HOST> -p <PRINCIPAL> -w <PASSWORD> -a

        Эта команда проводит двухфазную диагностику сетевого взаимодействия между ведущими и ведомыми узлами FreeIPA. Сначала тестируется доступность TCP-портов ведущего узла (389, 636, 88, 464, 80, 443), а затем автоматически по SSH инициирует обратное тестирование тех же портов с ведущего на ведомый узел. Ошибки «Failed to bind» при этом свидетельствуют лишь о занятости портов штатными службами, но не об их недоступности.

        Используются следующие параметры:

        • -m <HOST>
          указывает FQDN или IP-адрес ведущего узла, к которому ведомый узел должен подключиться в первой фазе тестирования,

        • -r <REALM>
          имя IPA Kerberos области (realm) (обычно домен в верхнем регистре); без него инструмент не сможет получить билет и завершится ошибкой,

        • -k <HOST>
          FQDN или IP-адрес KDC для Kerberos аутентификации (по умолчанию совпадает с ведущим узлом),

        • -p <PRINCIPAL>
          имя Kerberos принципала (например, admin), под которым будет совершена аутентификация перед тестированием,

        • -w <PASSWORD>
          пароль указанного принципала (в кавычках, если содержит спецсимволы); является небезопасным, при отсутствии параметра инструмент запросит его интерактивно,

        • -a
          автоматически запускает на ведомом узле вторую фазу тестирования: по SSH заходит на ведущий узел и выполняет ipa-replica-conncheck --replica <REPLICA> для диагностики связи ведущий → ведомый.

        Блок кода
        titleВывод
        Check connection from replica to remote master 'ipasrv.testdomain.test':
           Directory Service: Unsecure port (389): OK
           Directory Service: Secure port (636): OK
           Kerberos KDC: TCP (88): OK
           Kerberos Kpasswd: TCP (464): OK
           HTTP Server: Unsecure port (80): OK
           HTTP Server: Secure port (443): OK
        
        The following list of ports use UDP protocol and would need to be
        checked manually:
           Kerberos KDC: UDP (88): SKIPPED
           Kerberos Kpasswd: UDP (464): SKIPPED
        
        Connection from replica to master is OK.
        Start listening on required ports for remote master check
        389 tcp: Failed to bind
        636 tcp: Failed to bind
        88 tcp: Failed to bind
        88 udp: Failed to bind
        464 tcp: Failed to bind
        464 udp: Failed to bind
        80 tcp: Failed to bind
        443 tcp: Failed to bind
        Get credentials to log in to remote master
        Check RPC connection to remote master
        Retrying using SSH...
        Check SSH connection to remote master
        Execute check on remote master
      • Дополнительно вручную протестировать порты 88 и 464 протокола UDP. Для этой диагностики достаточно сетевого соединения между узлами; сама репликация не требуется и не влияет на результат. Сделать это можно при помощи команды с любого узла топологии, например:
        Command
        nc -vuz ipasrv.testdomain.test 88 464
        Раскрыть
        titleСправка
        Информация
        titleСправка
        Command
        nc -vuz <HOST> <PORT>

        Команда сканирует указанные UDP-порты (88 и 464) на хосте ipasrv.testdomain.test, не передавая реальных данных и выводит подробную информацию о статусе каждого порта (открыт/закрыт). Поставляется с пакетом netcat-openbsd.
        Используются следующие параметры:

        • -v
          включает подробный режим,

        • -u
          заставляет использовать UDP вместо TCP при соединении с портами,

        • -z
          включает режим сканирования без передачи данных: netcat лишь пытается установить соединение и сразу его закрывает, что полезно при тестировании портов.

        Блок кода
        titleВывод
        Connection to ipasrv.testdomain.test (10.192.5.244) 88 port [udp/kerberos] succeeded!
        Connection to ipasrv.testdomain.test (10.192.5.244) 464 port [udp/kpasswd] succeeded!
  • Проверка списков реплик и соглашений репликации

    • Для диагностики доступности узлов в текущей топологии, а также для диагностики актуальности репликации узлов в составе пакета freeipa-server предоставляется инструмент ipa-replica-manage. Для выполнения диагностики:
      • На любом узле вывести базовый список узлов при помощи команды:
        Command
        sudo ipa-replica-manage list
        Раскрыть
        titleСправка
        Информация
        titleСправка

        Отображает все узлы (ведущие и ведомые) в текущей топологии, удостоверяясь в отсутствии «призрачных» или пропавших узлов. Позволяет убедиться, что каждый сервер имеет корректную роль.

        Блок кода
        titleВывод
        ipasrv.testdomain.test: master
        ipacln.testdomain.test: master
      • На любом узле вывести подробный статус соглашений репликации для конкретного узла, например:
        Command
        sudo ipa-replica-manage list ipasrv.testdomain.test -v
        Раскрыть
        titleСправка
        Информация
        titleСправка
        Command
        ipa-replica-manage list <HOST> -v

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

        Используются следующие параметры:

        • <HOST>
          FQDN узла для которого будет выводиться подробный статус соглашений,
        • -v
          включает подробный режим.

        Пояснение вывода команды:

        • last init status
          код результата последней инициализации реплики (0 = успешно, иначе ошибка),
        • last init ended
          время завершения инициализации,
        • last update status
          код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
        • last update ended
          время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).
        Блок кода
        titleВывод
        ipacln.testdomain.test: replica
          last init status: Error (0) Total update succeeded
          last init ended: 2025-05-28 19:51:44+00:00
          last update status: Error (0) Replica acquired successfully: Incremental update succeeded
          last update ended: 2025-05-28 23:59:09+00:00
      • На любом узле вывести значения счётчиков изменений (RUV) при помощи команды:
        Command
        sudo ipa-replica-manage list-ruv
        Раскрыть
        titleСправка
        Информация
        titleСправка

...

      • Команда позволяет получить значения счётчиков изменений (RUV) для всех реплик как в доменной части, так и (при наличии DogTag) в службе сертификатов. По сравнению с простым выводом топологии она даёт представление о точке синхронизации каждой реплики, что помогает оперативно выявлять узлы, отстающие по приёму изменений. Если счётчик одного узла существенно меньше, чем у остальных, значит он не подтянул последние операции (создание/удаление/изменение записей) из домена или CA.

        Блок кода
        titleВывод без подключенного DogTag
        Replica Update Vectors:
                ipasrv.testdomain.test:389: 

...

      • 4
                ipacln.testdomain.test:389:

...

Command
sudo ipa-replica-manage list ipasrv.testdomain.test -v
Раскрыть
titleСправка
Информация
titleСправка
Command
ipa-replica-manage list <HOST> -v

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

Используются следующие параметры:

  • <HOST>
    FQDN узла для которого будет выводиться подробный статус соглашений,
  • -v
    включает подробный режим.

Пояснение вывода команды:

  • last init status
    код результата последней инициализации реплики (0 = успешно, иначе ошибка),
  • last init ended
    время завершения инициализации,
  • last update status
    код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
  • last update ended
    время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).
Блок кода
titleВывод
ipacln.testdomain.test: replica
  last init status: Error (0) Total update succeeded
  last init ended: 2025-05-28 19:51:44+00:00
  last update status: Error (0) Replica acquired successfully: Incremental update succeeded
  last update ended: 2025-05-28 23:59:09+00:00

...

Command
sudo ipa-replica-manage list-ruv
Раскрыть
titleСправка
Информация
titleСправка

Команда позволяет получить значения счётчиков изменений (RUV) для всех реплик как в доменной части, так и (при наличии DogTag) в службе сертификатов. По сравнению с простым выводом топологии она даёт представление о точке синхронизации каждой реплики, что помогает оперативно выявлять узлы, отстающие по приёму изменений. Если счётчик одного узла существенно меньше, чем у остальных, значит он не подтянул последние операции (создание/удаление/изменение записей) из домена или CA.

Блок кода
titleВывод без подключенного DogTag
Replica Update Vectors:
        ipasrv.testdomain.test:389: 4
        ipacln.testdomain.test:389: 3
Certificate Server Replica Update Vectors:
        No CS-RUVs found.
Блок кода
titleВывод c подключенным DogTag
Replica Update Vectors:
        ipasrv.testdomain.test:389: 4
        ipacln.testdomain.test:389: 3
Certificate Server Replica Update Vectors:
        ipasrv.testdomain.test:389: 6

...

Command
sudo ipa-replica-manage dnarange-show
Раскрыть
titleСправка
Информация
titleСправка

Команда выводит назначенные UID/GID-диапазоны (DNA) для каждого сервера; для реплик без созданных пользователей выводит «No range set». Помогает убедиться, что новые реплики получили корректный диапазон при создании первой записи; отсутствие диапазона у «визуально активной» реплики указывает, что на ней ещё не создавались пользователи или группы.

Блок кода
titleВывод
ipasrv.testdomain.test: 1188400002-1188500499
ipacln.testdomain.test: 1188500504-1188599999

...

  • На любом узле вывести базовый список узлов участвующих в репликации сертификатов DogTag CA при помощи команды:
    Command
    sudo ipa-csreplica-manage list
    Раскрыть
    titleСправка
    Информация
    titleСправка

    Отображает все узлы в текущей топологии, участвующие в репликации сертификатов DogTag CA, проверяя отсутствие «призрачных» или пропавших узлов. Позволяет убедиться, что каждый сервер имеет корректную роль.

    Блок кода
    titleВывод
    ipasrv.testdomain.test: master
    ipacln.testdomain.test: master
  • На любом узле вывести подробный статус соглашений репликации сертификатов DogTag CA для конкретного узла, например:
    Command
    sudo ipa-csreplica-manage list ipasrv.testdomain.test -v
    Раскрыть
    titleСправка
    Информация
    titleСправка
    Command
    ipa-careplica-manage list <HOST> -v

    Команда выводит детальную информацию о всех соглашениях репликации сертификатов DogTag CA для указанного узла: статус и метки времени последних инициализаций и обновлений реплик.

    Используются следующие параметры:

    • <HOST>
      FQDN узла для которого будет выводиться подробный статус соглашений сертификатов DogTag CA,
    • -v
      включает подробный режим.

    Пояснение вывода команды:

    • last init status
      код результата последней инициализации реплики (0 = успешно, иначе ошибка),
    • last init ended
      время завершения инициализации,
    • last update status
      код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
    • last update ended
      время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).
    Блок кода
    titleВывод
    ipacln.testdomain.test
      last init status: Error (0) Total update succeeded
      last init ended: 2025-05-28 10:22:34+00:00
      last update status: Error (0) Replica acquired successfully: Incremental update succeeded
      last update ended: 2025-05-28 21:32:10+00:00

Проверка суффиксов репликации

...

Command
sudo ipa topologysuffix-find --all
Раскрыть
titleСправка
Информация
titleСправка

Показывает топологические суффиксы LDAP domain и ca (только при наличии центра сертификации DogTag), которые участвуют в репликации, вместе с полным набором их атрибутов и метаданных. Помогает понять, почему нужные данные не реплицируются между серверами. Также сразу видно отсутствие или некорректность суффиксов в топологии, что указывает на проблемы конфигурации репликации.

Пояснение вывода команды:

  • dn
    полный DN записи в LDAP, 

  • Имя суффикса 
    значение атрибута cn, задающее понятное имя суффикса,

  • DN управляемого суффикса LDAP
    показывает базовый DN LDAP-суффикса,

  • nsDS5ReplicaStripAttrs
    список атрибутов, исключаемых из репликации,

  • nsDS5ReplicatedAttributeList
    список атрибутов, которые будут реплицироваться, за исключением тех, что перечислены после ключевого слова EXCLUDE,

  • nsDS5ReplicatedAttributeListTotal
    список всех атрибутов, которые будут реплицированы полностью, за исключением тех, что перечислены после ключевого слова EXCLUDE,

  • objectClass
    указывает, к каким объектным классам относится запись.

...

titleВывод без подключенного DogTag
      •  3
        Certificate Server Replica Update Vectors:
                No CS-RUVs found.
        Блок кода
        titleВывод c подключенным DogTag
        Replica Update Vectors:
                ipasrv.testdomain.test:389: 4
                ipacln.testdomain.test:389: 3
        Certificate Server Replica Update Vectors:
                ipasrv.testdomain.test:389: 6
      • На любом узле вывести назначенные UID/GID-диапазоны (DNA-ranges) при помощи команды:
        Command
        sudo ipa-replica-manage dnarange-show
        Раскрыть
        titleСправка
        Информация
        titleСправка

        Команда выводит назначенные UID/GID-диапазоны (DNA) для каждого сервера; для реплик без созданных пользователей выводит «No range set». Помогает убедиться, что новые реплики получили корректный диапазон при создании первой записи; отсутствие диапазона у «визуально активной» реплики указывает, что на ней ещё не создавались пользователи или группы.

        Блок кода
        titleВывод
        ipasrv.testdomain.test: 1188400002-1188500499
        ipacln.testdomain.test: 1188500504-1188599999
    • Для диагностики доступности узлов, участвующих в репликации сертификатов DogTag CA в составе пакета freeipa-server предоставляется инструмент ipa-careplica-manage. Для выполнения диагностики:
      • На любом узле вывести базовый список узлов участвующих в репликации сертификатов DogTag CA при помощи команды:
        Command
        sudo ipa-csreplica-manage list
        Раскрыть
        titleСправка
        Информация
        titleСправка

        Отображает все узлы в текущей топологии, участвующие в репликации сертификатов DogTag CA, удостоверяясь в отсутствии «призрачных» или пропавших узлов. Позволяет убедиться, что каждый сервер имеет корректную роль.

        Блок кода
        titleВывод
        ipasrv.testdomain.test: master
        ipacln.testdomain.test: master
      • На любом узле вывести подробный статус соглашений репликации сертификатов DogTag CA для конкретного узла, например:
        Command
        sudo ipa-csreplica-manage list ipasrv.testdomain.test -v
        Раскрыть
        titleСправка
        Информация
        titleСправка
        Command
        ipa-careplica-manage list <HOST> -v

        Команда выводит детальную информацию о всех соглашениях репликации сертификатов DogTag CA для указанного узла: статус и метки времени последних инициализаций и обновлений реплик.

        Используются следующие параметры:

        • <HOST>
          FQDN узла для которого будет выводиться подробный статус соглашений сертификатов DogTag CA,
        • -v
          включает подробный режим.

        Пояснение вывода команды:

        • last init status
          код результата последней инициализации реплики (0 = успешно, иначе ошибка),
        • last init ended
          время завершения инициализации,
        • last update status
          код результата последнего инкрементального обновления (0 = успешно, иначе ошибка),
        • last update ended
          время завершения обновления (если никогда не выполнялось успешно после инициализации → 1970-01-01 00:00:00+00:00).
        Блок кода
        titleВывод
        ipacln.testdomain.test
          last init status: Error (0) Total update succeeded
          last init ended: 2025-05-28 10:22:34+00:00
          last update status: Error (0) Replica acquired successfully: Incremental update succeeded
          last update ended: 2025-05-28 21:32:10+00:00
  • Проверка суффиксов репликации

    • Для диагностики наличия и корректности LDAP-суффиксов репликации в составе пакета freeipa-server предоставляется инструмент ipa с командами topologysuffix-find и ipa topologysuffix-verify. Для выполнения диагностики:
      • На любом узле выполнить обзор суффиксов при помощи команды:
        Command
        sudo ipa topologysuffix-find --all
        Раскрыть
        titleСправка
        Информация
        titleСправка

        Показывает топологические суффиксы LDAP domain и ca (только при наличии центра сертификации DogTag), которые участвуют в репликации, вместе с полным набором их атрибутов и метаданных. Помогает понять, почему нужные данные не реплицируются между серверами. Также сразу видно отсутствие или некорректность суффиксов в топологии, что указывает на проблемы конфигурации репликации.

        Пояснение вывода команды:

        • dn
          полный DN записи в LDAP, 

        • Имя суффикса 
          значение атрибута cn, задающее понятное имя суффикса,

        • DN управляемого суффикса LDAP
          показывает базовый DN LDAP-суффикса,

        • nsDS5ReplicaStripAttrs
          список атрибутов, исключаемых из репликации,

        • nsDS5ReplicatedAttributeList
          список атрибутов, которые будут реплицироваться, за исключением тех, что перечислены после ключевого слова EXCLUDE,

        • nsDS5ReplicatedAttributeListTotal
          список всех атрибутов, которые будут реплицированы полностью, за исключением тех, что перечислены после ключевого слова EXCLUDE,

        • objectClass
          указывает, к каким объектным классам относится запись.

        Блок кода
        titleВывод без подключенного DogTag
        ---------------------------------------------
        установлено соответствие 1 суффикса топологии
        ---------------------------------------------
          dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
          Имя суффикса: domain
          DN управляемого суффикса LDAP: dc=testdomain,dc=test
          nsds5replicastripattrs: modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp
          nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
          nsds5replicatedattributelisttotal: (objectclass=*) $ EXCLUDE entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
          objectclass: top, iparepltopoconf
        ---------------------------------
        Количество возвращённых записей 1
        ---------------------------------
        Блок кода
        titleВывод с подключенным DogTag
        ----------------------------------------------
        установлено соответствие 

...

      • 2 

...

      • суффиксов топологии
        -------------------------------

...

      • ---------------
          dn: cn=ca,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
          Имя суффикса: ca
          DN управляемого суффикса LDAP: o=ipaca
          objectclass: top, iparepltopoconf
        
          dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=testdomain,dc=test
          Имя суффикса: domain
          DN управляемого суффикса LDAP: dc=testdomain,dc=test
          nsds5replicastripattrs: modifiersName modifyTimestamp internalModifiersName internalModifyTimestamp
          nsds5replicatedattributelist: (objectclass=*) $ EXCLUDE memberof idnssoaserial entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
          nsds5replicatedattributelisttotal: (objectclass=*) $ EXCLUDE entryusn

...

titleВывод с подключенным DogTag

...

      •  krblastsuccessfulauth krblastfailedauth krbloginfailedcount passwordgraceusertime
          objectclass: top, iparepltopoconf
        ---------------------------------

...

      • 
        

...

      • Количество возвращённых 

...

      • записей 2

...

      • 
        ---------------------------------
      • На любом узле выполнить верификацию нужного суффикса, например domain, при помощи команды:
        Command
        sudo ipa topologysuffix-

...

Command
sudo ipa topologysuffix-verify domain
Раскрыть
titleСправка
Информация
titleСправка
Command
ipa topologysuffix-verify <SUFFIX>

Команда выполняет проверку репликационной топологии для указанного LDAP-суффикса, анализируя объекты «topology suffix» и связанные с ними «topology segment» и убеждаясь, что между всеми серверами настроены двунаправленные соглашения репликации. Если обнаруживается хоть один сегмент с односторонней связью или разрыв репликации, команда выводит сообщение об ошибке, что позволяет быстро выявить и устранить сбои в репликации. При отсутствии каких-либо проблем команда завершится без ошибок, подтверждая целостность конфигурации.

Используется следующий параметр:

  • <SUFFIX>
    Имя суффикса репликации. Например domain или ca.

...

titleВывод

...

      • verify domain
        Раскрыть
        titleСправка
        Информация
        titleСправка
        Command
        ipa topologysuffix-verify <SUFFIX>

        Команда выполняет тестирование репликационной топологии для указанного LDAP-суффикса, анализируя объекты «topology suffix» и связанные с ними «topology segment» и убеждаясь, что между всеми серверами настроены двунаправленные соглашения репликации. Если обнаруживается хоть один сегмент с односторонней связью или разрыв репликации, команда выводит сообщение об ошибке, что позволяет быстро выявить и устранить сбои в репликации. При отсутствии каких-либо проблем команда завершится без ошибок, подтверждая целостность конфигурации.

        Используется следующий параметр:

        • <SUFFIX>
          Имя суффикса репликации. Например domain или ca.
        Блок кода
        titleВывод
        =================================================================
        Топология репликации суффикса "domain" соответствует требованиям.
        =================================================================

Автоматическая диагностика

  • Работа с инструментом ipa-healthcheck

    • Для автоматической диагностики в составе пакета freeipa-healthcheck предоставляется инструмент ipa-healthcheck.
      Рекомендуется запускать инструмент на всех узлах, со всеми возможными источниками и проверками:
      Command
      sudo ipa-healthcheck --output-type human
      При отсутствии сбоев в окружении узла ожидается вывод:
      Блок кода
      titleВывод
      No issues found.
      Ряд источников, которые могут быть полезны при точечном диагностировании сбоев Directory Server, включая репликацию:
      • все источники начинающиеся на ipahealthcheck.ds: ipahealthcheck.ds.backends, ipahealthcheck.ds.config, ipahealthcheck.ds.disk_space, ipahealthcheck.ds.dse, ipahealthcheck.ds.encryption, ipahealthcheck.ds.fs_checks, ipahealthcheck.ds.nss_ssl, ipahealthcheck.ds.ds_plugins, ipahealthcheck.ds.replication, ipahealthcheck.ds.ruv,
      • источник ipahealthcheck.ipa.topology,
      • источник ipahealthcheck.meta.services,
      • источник ipahealthcheck.ipa.host,
      • источник ipahealthcheck.ipa.dna,
      • источник ipahealthcheck.ipa.idns.
    • Источники указываются через аргумент командной строки --source, например:
      Command
      sudo ipa-healthcheck --output-type human --source ipahealthcheck.ipa.dna
      Ознакомиться с функциональными возможностями инструмента более подробно можно в статье FreeIPA Health Check. Обзор функциональных возможностей.

...