Инструкция по сетевым взаимодействиям

1. Матрица портов и протоколов

2. Общая топология

3. Протоколы работы служб

LDAP / LDAPS (389 / 636)

Каталог. Поддержка простого bind (проверка userPassword, bcrypt) и SASL EXTERNAL по клиентскому сертификату на LDAPS (CN сертификата → идентичность). При выдаче объектов секретные атрибуты (unicodePwd, hopeKrbKeys, ключи ЦС и др.) скрываются. Смена пароля через unicodePwd (UTF‑16LE, как от adcli/realm) декодируется в NT‑хэш и AES‑ключи.

Kerberos KDC (88)

Обработка AS‑REQ/TGS‑REQ. Мультиреалм: реалм берётся из запроса, krbtgt и пользователь ищутся в поддереве нужного домена. Типы шифрования: RC4‑HMAC (etype 23) и AES128/256 (etype 17/18); соль по умолчанию — ВЕРХНИЙ_РЕАЛМ + principal, передаётся в padata ETYPE‑INFO2.

UDP (v139). Запрос по UDP 88 обрабатывается тем же кодом, что и по TCP. Ответ, который не помещается в датаграмму (больше DC_KRB_UDP_MAX, по умолчанию 1465 байт — обычно билеты Windows с PAC), не отправляется: клиент получает KRB_ERR_RESPONSE_TOO_BIG и сам повторяет запрос по TCP, как с AD. Белый список IP клиентов (net_ldap.json) действует и для UDP.

Блокировка учёток (v138). Если в Default Domain Policy задан порог блокировки, неверные пароли при получении билета считаются; заблокированная учётка получает KDC_ERR_CLIENT_REVOKED с NTSTATUS STATUS_ACCOUNT_LOCKED_OUT в e‑data (как у AD).

kpasswd (464/TCP, UDP)

Смена своего пароля (по первичному билету kadmin/changepw, полученному паролем) и установка пароля другой учётке её администратором. Служба есть во всех собственных доменах и в доменах, перешедших из AD (после «Принять роль KDC»).

CLDAP netlogon (389/UDP)

Ответчик обнаружения домена: по запросу клиента (SSSD ad‑provider, Windows) возвращает netlogon‑данные нужного домена (выбор по FQDN из запроса).

DNS (53/UDP)

Авторитативные зоны + форвардер. Хранит SRV/A/CNAME‑записи DC‑locator (_ldap._tcp, _kerberos, _gc, _msdcs и т.д.), по которым клиенты находят контроллер. Возможен импорт зон из MS AD и TSIG для динамических обновлений.

DHCP (67/UDP) и SMB (445)

DHCP выдаёт адреса из пулов, ведёт учёт аренд и статических резерваций MAC→IP, при необходимости регистрирует выданные адреса в DNS (A + PTR). Поддержаны сообщения DISCOVER / REQUEST / RELEASE / DECLINE / INFORM.

Выдаваемые опции (RFC 2132): маска (1), шлюз (3), DNS‑серверы (6), доменное имя (15), broadcast (28), срок аренды (51) и времена продления T1/T2 (58/59), server‑id (54). Дополнительно, если заданы в пуле и запрошены клиентом (option 55): NTP‑серверы (42, важно для синхронизации времени под Kerberos — при пустом значении подставляется IP контроллера), Time‑серверы RFC 868 (4), Log‑серверы (7), LPR/print‑серверы (9), WINS/NetBIOS name servers (44) и NetBIOS node type (46), MTU интерфейса (26), Domain Search List (119, кодирование по RFC 3397), Classless Static Routes (121 и MS‑вариант 249, кодирование по RFC 3442), WPAD proxy‑URL (252), а также PXE‑загрузка — TFTP/next‑server (66) и bootfile (67, с заполнением BOOTP‑полей siaddr/file). Опции broadcast и T1/T2 вычисляются автоматически из сети и срока аренды.

Все дополнительные опции настраиваются в отдельном окне «Дополнительные опции DHCP» — в виде компактной таблицы «опция → значение» с поиском по названию/номеру и всплывающим описанием при наведении на имя опции. В каталоге около 35 наиболее востребованных опций, сгруппированных по разделам (сеть и время, аренда, имена и поиск, NetBIOS/WINS, сервисы, маршруты, PXE): смещение времени (2), time/NTP‑серверы (4/42), IP‑TTL (23), ARP‑timeout (35), IP‑forwarding (19), router discovery (31), T1/T2 (58/59), Domain Search (119), NIS/NIS+ (40/41/64/65), WINS/NBDD/node‑type/scope (44/45/46/47), log/LPR/SMTP/POP3/WWW‑серверы (7/9/69/70/72), WPAD (252), classless‑маршруты (121/249) и классовые (33), swap‑сервер (16), TFTP/bootfile/root‑path (66/67/17) и др. Значение задаётся строкой (список IPv4 через запятую, текст, число, домены или маршруты), кодирование в байты выполняет сервер; пустое значение означает «опцию не выдавать».

Пулы можно редактировать после создания: в списке пулов у каждой записи есть действия «Опции» (открывает окно опций сразу) и «Редактировать» (полная правка пула); id пула при этом сохраняется, поэтому действующие аренды и резервации не теряются.

SMB предоставляет доступ к SYSVOL и сетевым ресурсам, участвует в аутентификации (SPNEGO/NTLMSSP).

HTTP Admin API (9444)

REST‑API веб‑панели; та же точка используется узлами кластера для репликации (эндпоинты /api/replication/*).

4. Подключение клиентов

Windows‑клиент

Ввод в домен и вход как в классическом AD: DNS находит контроллер по SRV‑записям, Kerberos выдаёт билеты, LDAP отдаёт объекты, SMB — SYSVOL с политиками. Групповые политики применяются из SYSVOL (файлы GPT/registry.pol туда помещает агент — см. Документ 3).

Linux‑клиент (SSSD, ad‑provider)

Ввод через realm join / adcli; объект компьютера по умолчанию попадает в контейнер CN=Computers, атрибут operatingSystem заполняется автоматически. SSSD настраивается на ad‑provider (обнаружение — CLDAP, аутентификация — Kerberos, данные — LDAP(S)). Особенности HopeDC: ID‑mapping в двух режимах (POSIX и SID), sudo_provider=ad (правила sudoRole читаются штатно), AES‑ключи Kerberos для входа с отключённым RC4. Политики hopeLinuxPolicy применяет отдельный агент hopedc-agent по расписанию (systemd .timer), аутентифицируясь паролем сервисной учётки или клиентским сертификатом (mTLS / SASL EXTERNAL).

5. Кластер (высокая доступность)

Модель репликации — pull: узел настраивается с идентификатором (node_id), общим секретом и списком пиров (базовые URL их API вида https://10.0.0.2:9444). Фоновый воркер периодически вызывает у каждого пира /api/replication/pull и применяет полученные изменения; при первом подключении выполняется бутстрап снимком через /api/replication/snapshot. Все изменения помечаются node_id источника (origin) для корректного слияния. Обмен идёт по порту API 9444 (порт бэкенда; веб‑панель отдаётся тем же бинарником на 9443) и требует совпадения секрета.

Реплицируются объекты каталога (домены, OU, пользователи, группы, ПК), DNS‑записи, доверительные отношения, доменная политика безопасности и конфигурация DHCP‑пулов (аренды остаются локальными). Конфликты (правка одного объекта на разных узлах) разрешаются по правилу «последняя запись побеждает» (по времени изменения, поэтому требуется синхронизация часов NTP). Для наблюдаемости узел ведёт журнал конфликтов и отчёты о догоне после возврата, а для проверки расхождения обменивается детерминированными дайджестами состояния через /api/replication/digest (также под секретом). Межузловые эндпоинты (все на 9444): /api/replication/pull, /api/replication/snapshot, /api/replication/digest.

6. Связь HopeDC ↔ Microsoft AD

Взаимодействие с существующим доменом Microsoft AD идёт по трём каналам:

1. Зеркалирование (чтение). Фоновый воркер синхронизации подключается к контроллеру‑источнику по LDAP (389) или LDAPS (636), выполняет bind учётной записью синхронизации (hopeSyncUser / hopeSyncPass, IP в hopePdcIp) и зеркалирует объекты каталога. Отдельный воркер импортирует DNS‑зоны.
2. Обратная запись (push). Изменения объектов интегрированного домена (например, gPLink, атрибуты) HopeDC записывает обратно в MS AD тем же LDAP‑bind. Атрибуты, начинающиеся на hope*, в AD не выгружаются (служебные). Домен для записи определяется по DN‑суффиксу целевого объекта.
3. SYSVOL (необязательно, v182). HopeDC подключается к общей папке \\<DC>\SYSVOL по SMB 445 учёткой синхронизации (Kerberos, при недоступности — NTLMv2; подпись SMB всегда) — как консоль GPMC. Так HopeDC копирует файлы групповых политик домена‑зеркала и (в двустороннем режиме) записывает туда правки из своего редактора. На контроллер AD ничего не устанавливается (Документы 3 и 12).
4. Сайты (Configuration NC). Топология сайтов (`CN=Sites,CN=Configuration,…`) читается из MS AD при синхронизации и двусторонне синхронизируется: создание/изменение/удаление сайтов, подсетей и связей пишутся обратно в Configuration NC той же учёткой синхронизации по LDAP (389/636). Раздел «Сайты и службы» веб‑панели.

6a. Лес и поддомены

HopeDC поддерживает иерархию доменов (лес). При создании поддомена (напр. corp.lol.local) автоматически настраивается:

• DNS‑делегирование: в родительской зоне создаются NS‑записи и glue‑A на контроллер потомка, а также зона потомка (SOA/NS/A) — так клиенты находят DC поддомена.
• Двустороннее транзитивное доверие родитель↔потомок (внутри леса) и общий пароль доверия = меж‑реалмовый ключ.
• Кросс‑реалм Kerberos: когда клиент одного реалма (напр. LOL.LOCAL) запрашивает службу в другом (CORP.LOL.LOCAL), KDC на :88 выдаёт реферальный TGT (krbtgt/<TARGET_REALM>), зашифрованный меж‑реалмовым ключом; клиент повторяет запрос уже в целевом реалме — тому же HopeDC (мультиреалм‑KDC).
• Общий Configuration/Schema NC: RootDSE (пустой Base DN на :389/:636) отдаёт configurationNamingContext/schemaNamingContext корня леса; сайты (Configuration NC) общие для всех доменов леса.
• Глобальный каталог (GC): порты 3268/3269 (TLS) отдают форест‑wide поиск по объектам всех доменов из единого хранилища.

7. Сводная матрица межсетевого экрана