TAK Federation Hub: архітектура, налаштування та коли обирати його замість прямої федерації

TAK Federation Hub — це опціональний брокер, випущений разом із TAK Server. Замість того щоб кожен TAK Server федерувався безпосередньо з кожним, кожен сервер відкриває одне федеративне з'єднання до хаба; хаб автентифікує федератів і пересилає дані згідно з визначеним адміністратором графом політики з груповими фільтрами на кожному ребрі. Застосовуйте його, коли з'єднуєте понад три сервери або кілька адміністративних доменів.

Ця сторінка присвячена архітектурному вибору (хаб чи пряма федерація «сервер–сервер») і тому, що означає експлуатація хаба: версії протоколу і типові порти, модель політики, PKI, розгортання, експлуатація та усунення несправностей. Щоб налаштувати один прямий канал між двома серверами, скористайтеся нашим посібником із налаштування федерації TAK Server.

• Що це: брокер топології «хаб і спиці» для федерації TAK Server (менеджер політики, брокер повідомлень, адміністративний вебінтерфейс).
• Типові порти: 9102/tcp — федерація v2, 9101/tcp — федерація v1, 9100/tcp — адміністративний інтерфейс.
• Залежності: Java 17 і MongoDB; постачається як RPM, DEB і Docker-пакет.
• Зрілість: офіційний посібник із конфігурації TAK Server (версія 5.7, березень 2026) досі позначає інсталятор хаба як «beta».

Навіщо Federation Hub: проблема N² прямої федерації

Пряма федерація — це двостороння домовленість, реалізована програмно. Згідно з посібником із конфігурації TAK Server, два адміністратори обмінюються CA-сертифікатами; кожен сервер зберігає їх у сховищі довіри федерації, відокремленому від сховища для локальних користувачів, тож сервер партнера може під'єднатися, а пристрої ATAK партнера — ні. Один із двох серверів створює вихідне з'єднання, і обидві сторони обирають, які групи можуть виходити з їхнього сервера й надходити до нього. Клієнти не потребують переналаштування.

Це прийнятно для двох-трьох серверів. Повнозв'язна мережа (full mesh) з n серверів потребує n(n−1)/2 каналів: 6 для чотирьох серверів, 45 для десяти. Кожен канал означає обмін CA, відкриття в брандмауері на стороні, що слухає, і налаштування груп на обох кінцях, а кожна зміна політики повторюється для кожного каналу.

Federation Hub замінює mesh «зіркою». Кожен TAK Server федерується один раз — з хабом, який керує з'єднаннями та довірою і брокерує кожне повідомлення вздовж ребер графа політики, фільтруючи за TAK-групами. Змінюються три речі:

• Довіра: кожен TAK Server імпортує один зовнішній CA — CA хаба — замість по одному на кожного партнера. CA партнерів зберігає хаб.
• Досяжність: спиці зазвичай ініціюють з'єднання до хаба самі, тож передовим серверам за NAT або за односторонніми брандмауерами не потрібні вхідні відкриття. Слухає лише хаб.
• Політика: хто що отримує — живе в одному графі замість десятків налаштувань на кожному сервері, при цьому кожен сервер, як і раніше, керує тим, що залишає його межі.

Витрати теж реальні: додатковий брокерський стрибок на кожному повідомленні між серверами, нова високоважлива система, що завершує кожну федеративну сесію й бачить увесь брокований трафік, і єдина точка відмови для обміну між серверами. Коли хаб недоступний, локальна картина на кожному сервері продовжує працювати; зупиняється лише обмін.

Версії федеративного протоколу та типові порти

TAK Server розмовляє двома федеративними протоколами. Федерація v1 — оригінальна: довгоживучий TLS-сокет, що несе федеративні події у кодуванні protobuf. Федерація v2 переносить protobuf-повідомлення через gRPC (HTTP/2) з тим самим взаємним TLS, і саме вона увімкнена в прикладній конфігурації TAK Server, тоді як v1 постачається вимкненою. Протокол обирається для кожного вихідного з'єднання, і попередження посібника актуальне: обирайте версію протоколу, що відповідає порту, до якого ви під'єднуєтеся. Про клієнтську сторону читайте в порівнянні TAK-протоколів: CoT XML проти protobuf.

Це типові значення; перевіряйте їх у власних файлах. Прикладна конфігурація TAK Server:

<federation>
  <federation-server port="9000" v1enabled="false" v2port="9001" v2enabled="true">
    <tls context="TLSv1.2" keymanager="SunX509"
         keystore="JKS" keystoreFile="certs/files/takserver.jks" keystorePass="atakatak"
         truststore="JKS" truststoreFile="certs/files/fed-truststore.jks" truststorePass="atakatak"/>
  </federation-server>
</federation>

І конфігурація брокера хаба, /opt/tak/federation-hub/configs/federation-hub-broker.yml (фрагмент):

v1Enabled: true
v1Port: 9101
v2Enabled: true
v2Port: 9102
dbPort: 27017

Практичне правило: стандартизуйте всі з'єднання на v2, спрямуйте вихідні з'єднання TAK Server на порт 9102 хаба і вимкніть v1 на хабі, якщо вона ще потрібна застарілому партнерові. Від цього залежить і фільтрація груп: з'єднання v1 не передають хабу інформацію про TAK-групи, тож будь-яке ребро з фільтром за групою відкидає трафік v1.

Як Federation Hub маршрутизує трафік: граф політики та групові фільтри

Хаб працює як сукупність кооперуючих Java-служб під одним системним сервісом federation-hub: менеджер політики, брокер повідомлень і адміністративний вебінтерфейс (новітні пакети додають менеджер плагінів). Маршрутизація походить із графа політики, який ви малюєте в інтерфейсі. Його вузли:

• Групи CA: кожен федерат, чий сертифікат походить ланцюжком від завантаженого CA, потрапляє до групи цього CA. Більшість політик пишуться проти груп CA, що на практиці означає — проти організацій.
• Федерати: окремі TAK Server — для випадків, коли одному серверу потрібне інше поводження, ніж решті його організації.
• Вихідні з'єднання: з'єднання, які сам хаб відкриває до TAK Server або іншого хаба; так будуються багатострибкові топології «хаб–хаб».
• Токен-групи: федерати, що автентифікуються токенами замість взаємного TLS.

Ребра спрямовані. Ребро від A до B дозволяє трафіку A досягати B, але не навпаки, тож двосторонній обмін потребує двох ребер, а односторонні потоки (партнер отримує вашу картину синіх сил, але нічого не надсилає) — повноцінно підтримуваний шаблон. Кожне ребро несе груповий фільтр: усі групи, дозволені групи, заборонені групи або дозволені й заборонені. Групи — це групи TAK Server, прикріплені до кожного повідомлення, які користувачі ATAK бачать як канали. Повідомлення проходить ребро зі списком дозволених, якщо принаймні одна з його груп у списку, і не проходить ребро зі списком заборонених, якщо будь-яка з його груп у списку; повідомлення без груп проходить лише ребро «усі групи».

Групи CA мають також прапорець Interconnected: учасники такої групи обмінюються всім між собою — без ребер і без фільтрації. Це зручно в межах однієї організації й небезпечно в коаліції, тож перевіряйте його на кожній групі, яку додаєте. Редактор також розділяє збереження політики та її активацію; збережена, але неактивована політика нічого не змінює.

Мінімізація даних: три стадії фільтрації

1. Вихідний TAK Server: вихідні групи, задані для федерата хаба, визначають, що взагалі залишає ваш сервер. У коаліції це єдина стадія, якою ви повністю керуєте.
2. Ребра хаба: визначають, які адресати отримують які групи.
3. Цільовий TAK Server: вхідні групи й відображення федеративних груп визначають, які локальні користувачі бачать вхідний трафік.

Файли потребують окремих правил. Блокувальник Data Package і Mission File у TAK Server блокує федеративні файли за розширенням (типово pref, щоб конфігураційні файли не могли переконфігурувати пристрої партнерів), а федерація місій — це окреме від обміну CoT рішення; див. пакети даних і місійні пакети TAK. Посібник також прямо формулює обмеження: кожен домен керує тим, що він поширює, а не тим, що інший домен робить із цим. Клієнти поза всім цим: ATAK, WinTAK і браузерні клієнти на кшталт CloudTAK далі спілкуються зі власним сервером.

Модель довіри сертифікатів: CA, ідентичності федератів і відкликання

Довіра федерації будується на CA та взаємному TLS. У топології з хабом:

• Кожен TAK Server імпортує CA хаба до свого сховища довіри федерації (інтерфейс хаба вміє завантажувати власний CA) і подає свій серверний сертифікат під час з'єднання.
• Хаб імпортує CA кожної організації; завантаження створює групу CA, на яку посилається політика.
• Ідентичність федерата — це його сертифікат, і ланцюжок видачі визначає його групи CA. Сервер, чиї ланцюжок охоплює проміжний CA, може потрапити до кількох груп CA — тоді ребра всіх них мають дозволяти трафік.

Звідси чотири правила проєктування:

• Використовуйте виділений федеративний CA на кожну організацію. Посібник із конфігурації описує цей альтернативний варіант — окремий CA і серверний сертифікат, що використовуються лише для федерації, — щоб партнери ніколи не бачили CA, яким підписані ваші клієнтські сертифікати, а вилучення одного CA з хаба відключає рівно одну організацію.
• Сплануйте відкликання до того, як воно знадобиться. Ребра, написані проти групи CA, застосовуються до кожного сервера з цього CA. Щоб відключити один скомпрометований сервер, не чіпаючи його організацію, давайте високоризикованим партнерам окремі ребра на федерата або покладайтеся на перевірку відкликання (брокер хаба має опцію OCSP, типово вимкнену). Відокремлені мережі без OCSP-відповідача спираються на короткі строки дії сертифікатів і відпрацьовану процедуру видалення CA.
• Оберігайте ключ хаба як ключ CA і змінюйте типові паролі сховищ ключів (atakatak у постачених прикладах): хто тримає ключ хаба, може видавати себе за нього перед кожною спицею.
• Трактуйте токен-автентифікацію як виняток. TAK Server і хаб можуть автентифікувати федерацію токенами там, де TLS-інспектуючі проксі («break and inspect») роблять взаємний TLS неможливим; сам посібник зазначає, що токени менш безпечні за mTLS.

Про проєктування PKI між країнами-партнерами читайте в матеріалі про керування ідентифікацією в коаліції.

Налаштування Federation Hub і варіанти розгортання

Хаб поширюється на tak.gov окремим пакетом поруч із TAK Server: takserver-fed-hub як RPM (RHEL, Rocky) або DEB (Ubuntu, Debian), плюс Docker-пакет, що поєднує образ хаба з окремим образом MongoDB. Він потребує Java 17 і MongoDB, де брокер зберігає федеративні події та метадані, і працює як із суміщеним TAK Server, так і без нього. Виділіть хабу театру дій чи коаліції окремий хост: це якір довіри для кожного партнера, і він не повинен ділити домен відмови чи команду адміністрування з жодною спицею.

1. PKI. Створіть CA хаба і серверний сертифікат тими самими скриптами й процедурою, що й для TAK Server (додаток B посібника з конфігурації); сховище ключів і сховище довіри лежать у /opt/tak/federation-hub/certs/files/.
2. Встановлення. Встановіть Java 17, пакет хаба і MongoDB; задайте облікові дані бази даних у federation-hub-broker.yml і запустіть скрипт налаштування бази даних хаба.
3. Запуск і авторизація. Запустіть сервіс, авторизуйте адміністративний сертифікат і увійдіть з ним в інтерфейс на порті 9100 (команди нижче).
4. Обмін CA. Завантажте федеративний CA кожного партнера в інтерфейсі хаба й надішліть кожному партнерові CA хаба.
5. Намалюйте політику. Додайте групи CA (і окремих федератів, де потрібно), з'єднайте їх спрямованими ребрами, задайте груповий фільтр кожного ребра, вирішіть щодо Interconnected для кожної групи, потім збережіть і активуйте.
6. Під'єднайте кожен TAK Server. Увімкніть федерацію v2, завантажте CA хаба в Federate Certificate Authorities, створіть вихідне з'єднання до хаба на 9102 із протоколом v2, потім задайте вихідні та вхідні групи федерата хаба.
7. Перевірте обидва напрямки. Надішліть відомий тестовий трек у групі, що має проходити, і один у групі, що має блокуватися (наші приклади CoT-повідомлень з поясненнями — зручні фікстури), а потім переконайтеся, що подання Active Connections хаба показує очікувану версію протоколу й групові ідентичності.

sudo systemctl restart federation-hub
sudo systemctl enable federation-hub

# authorize an administrator certificate (written to authorized_users.yml)
sudo su tak
java -jar /opt/tak/federation-hub/jars/federation-hub-manager.jar /path/to/admin.pem
exit

# then open https://hub.example.org:9100/ and log in with that certificate

Відновлюваність Federation Hub і моніторинг

Публічна документація Federation Hub не описує кластеризований хаб у режимі active-active, тож плануйте швидкий теплий резерв, а не нульовий час простою:

• Резервуйте стан хаба: сертифікати й сховища ключів, файли політики, authorized_users.yml, каталог configs і базу даних MongoDB. Нотатки щодо оновлення хаба радять насамперед зберегти файл політики та авторизованих користувачів.
• Тримайте резерв з ідентичними сертифікатами й політикою за DNS-ім'ям або віртуальним IP, який можна перенести. TAK Server повторно з'єднуються самі — через інтервал повторного з'єднання, заданий на кожному вихідному з'єднанні.
• Зробіть спиці стійкими: збій хаба зупиняє обмін, а не локальні операції, тож більша частина роботи над доступністю належить кожному серверу; див. висока доступність і кластеризація TAK Server.
• Підбір розміру — з вимірювань: окремого опублікованого сайзингу хаба немає. Виходьте з базової лінії TAK Server із посібника (4 ядра, 8 ГБ RAM, 40 ГБ диска), далі спостерігайте за heap та інтенсивністю повідомлень під навантаженням навчань; серверні важелі — у налаштуванні продуктивності TAK Server.

Моніторте на трьох рівнях. В інтерфейсі хаба панель метрик показує загальну кількість з'єднань, читання й запис за секунду, байти за секунду, CPU та heap, а таблиця Active Connections перелічує для кожного федерата віддалену адресу, версію протоколу й групові ідентичності. На хостах збирайте /opt/tak/federation-hub/logs і стежте за федеративним статусом кожного TAK Server. Зовні зондуйте 9102 і 9100, тривожте на закінчення строку дії сертифікатів — кожного CA федерата і кожного серверного сертифіката, — відстежуйте зсув NTP і подавайте тривогу, коли кількість під'єднаних федератів падає нижче очікуваної.

Операційні шаблони: хаби театру дій, коаліційні, навчальні та доменні

Хаб театру дій

Підпорядковані підрозділи ведуть власні TAK Server і федеруються вгору — до хаба у вищому штабі. Підрозділи зберігають локальну картину, коли магістральний канал (backhaul) відмовляє, хаб вирішує, який ешелон які групи бачить, а спиці з ініціативою з'єднання зручні передовим серверам за NAT або за супутниковими терміналами.

Коаліційний хаб

Кожна держава тримає власний TAK Server, CA і адміністраторів; хаб під керівництвом держави-лідера або взаємно довіреної сторони несе спільну картину, а спрямовані ребра й списки дозволених кодують рішення про розповсюдження. Національні вихідні групи залишаються першою лінією контролю. Якщо коаліція використовує й формати NATO, шлюз на національній межі виконує переклад; див. поєднання CoT і стандартів NATO та впровадження афіліата FMN.

Навчальний хаб

Хаб із власним CA навчань, короткоживучими сертифікатами і сценарною політикою дозволяє учасникам приєднуватися й від'єднуватися, не чіпаючи сервери одне одного. Після завершення ви вилучаєте один CA і списуєте політику; під час події таблиця з'єднань хаба подвійно слугує табло присутності й стану.

Окремий хаб на домен класифікації

Хаб фільтрує за групами; це не міжрівневий шлюз. Він не перевіряє вміст проти правил розповсюдження й не акредитований переносити дані між рівнями класифікації. Запускайте окремий хаб на кожен домен безпеки й з'єднуйте домени лише через акредитований розв'язок міжмережевого обміну (CDS) — окремий продукт із власною акредитацією; див. архітектуру рішення міжмережевого обміну.

Хаби можуть також відкривати вихідні з'єднання до інших хабів, тож національний хаб може бути спарований із коаліційним. Тримайте такі ланцюжки короткими: кожен стрибок додає затримку й ще одну політику, яку треба тримати узгодженою.

Усунення несправностей з'єднань Federation Hub

• TLS-рукостискання не проходить або канал постійно перепід'єднується. Зазвичай справа в ланцюжку: спиця має довіряти CA хаба (не лише його серверному сертифікату), хаб має тримати CA, що видав спицю, разом із проміжними, ніхто не міг підмінити клієнтський сертифікат, і нічого не минулося за строком.
• З'єднано, але нічого не тече. Політика, а не мережа: чи група CA спиці є в активній політиці, чи існує ребро в очікуваному напрямку, чи вихідний сервер задав вихідні групи для федерата хаба, чи ціль задала вхідні групи?
• Частина груп тече, частина — ні. Імена груп мають збігатися точно, повідомлення без груп проходить лише ребра «усі групи», а з'єднання v1 груп не несуть. На TAK Server, що приймає, відображення федеративних груп відкочується до налаштувань груп федерата, коли жодне відображення не збігається.
• Тече занадто багато. Шукайте насамперед групу CA з Interconnected або ребро «усі групи».
• Розбіжність годинників. Перевірка сертифікатів, а також часові мітки й ознака застарілості CoT залежать від годинника; запускайте NTP зі спільного джерела на хабі й кожній спиці.
• Брандмауер, NAT і проксі. Хаб має приймати 9102/tcp (а 9100/tcp — лише з адміністративних мереж); stateful-брандмауери з короткими тайм-аутами простою обривають тихі з'єднання; TLS-інспектуючі проксі ламають взаємний TLS — виведіть федеративний шлях з-під інспекції або використайте токен-автентифікацію.
• Невідповідність версій. Вихідне з'єднання, налаштоване на v2, але спрямоване на порт v1 — або навпаки — ніколи не підніметься.
• Клоновані сервери. TAK Server записує випадковий ідентифікатор сервера в CoreConfig.xml при першому запуску й прошиває його як мітку потоку в оброблені повідомлення, відкидаючи все, що вже несе його власну мітку, щоб запобігти циклам маршрутизації. Федерати, створені з клонованого вже ініціалізованого сервера, ділять той самий ID; дайте кожному власний.

# Which certificate chain does the hub present on the v2 port?
openssl s_client -connect hub.example.org:9102 -showcerts </dev/null

# Which CAs does this TAK Server trust for federation?
keytool -list -keystore /opt/tak/certs/files/fed-truststore.jks

# Is this host's clock synchronised?
timedatectl status

Пряма федерація чи Federation Hub чи один спільний TAK Server

Практичне правило: для двох-трьох стабільних партнерів федеруйтеся напряму. Для чотирьох і більше серверів, кількох адміністративних доменів або списку партнерів, що змінюється кожні навчання, використовуйте хаб. Для однієї організації з одною командою адміністрування один кластеризований TAK Server із групами простіший за будь-яку федерацію.

Контрольний список планування федерації

1. Складіть реєстр кожного федерата: власник, версія TAK Server, досяжність і протокол (v2).
2. Оберіть топологію за таблицею вище; назвіть оператора хаба і тих, хто затверджує його конфігурацію.
3. Спроєктуйте PKI: федеративний CA на організацію, строки дії сертифікатів, дати поновлення і процедуру відкликання; змініть типові паролі сховищ ключів.
4. Узгодьте каталог груп між партнерами: точні імена груп, що кожен сервер надсилає (вихідні) і приймає (вхідні).
5. Намалюйте граф політики спершу на папері: спрямовані ребра, тип фільтра на кожному ребрі та явне рішення Interconnected для кожної групи CA.
6. Вирішіть федерацію файлів і місій окремо від CoT і не вимикайте блокувальник файлів pref.
7. Відкрийте брандмауер: 9102/tcp вхідним до хаба, 9100/tcp лише з адміністративних мереж, для спиць — лише вихідні; перевірте тайм-аути простою NAT і TLS-інспекцію.
8. Синхронізуйте час на кожному хості.
9. Напишіть тестову матрицю з одним обов'язково прохідним і одним обов'язково блокованим випадком на кожне ребро і перезапускайте її після кожної зміни політики.
10. Налаштуйте моніторинг, резервні копії й відпрацьований перехід на резервний хаб.
11. Тримайте один хаб на домен безпеки; усе, що перетинає домени, йде через акредитований розв'язок міжмережевого обміну.