Федерація TAK Server: підключення кількох TAK-мереж між підрозділами та командуваннями

Автор: Інженерна команда Corvus Intelligence · Про команду →

29 травня 2026 13 хв читання

Постійна проблема у спільних і коаліційних операціях — ізольований TAK-острів: підрозділ «Альфа» має власний TAK Server у передовому районі, підрозділ «Браво» — окремий сервер двома ешелонами вище, і жоден не бачить треків іншого на карті. Федерація TAK Server — це протокол, розроблений для вирішення цієї проблеми: він з'єднує два або більше незалежних екземплярів TAK Server так, що потоки CoT-подій рухаються в обох напрямках через межу, надаючи кожному оператору єдину загальну оперативну картину (COP) без об'єднання окремих серверів у єдину точку відмови. Цей посібник охоплює повний шлях федерації: архітектурні рішення, налаштування REST API CloudTAK, налаштування XML для застарілого TAK Server, групові фільтри та фільтри типів CoT, безпеку взаємного TLS і систематичну процедуру тестування для перевірки правильного розповсюдження треків.

Що таке федерація TAK Server і чому вона важлива

Федерація — це протокол між серверами, що працює через TCP-порт 9000 із взаємним TLS. Коли два TAK-сервери об'єднані у федерацію, кожен встановлює вихідне TCP/TLS-з'єднання до федеративного порту іншого та починає пересилати вибрані CoT-події, отримані від власних клієнтів. В результаті солдат з ATAK, підключеним до Сервера А, бачить у майже реальному часі треки підрозділів, клієнти ATAK яких підключені до Сервера Б — і навпаки. Зміна конфігурації на стороні клієнта не потрібна: федерація є виключно адміністративною функцією сервера.

Оперативні випадки, що вимагають федерації замість єдиного уніфікованого сервера, включають:

Розгортання з кількох ешелонів — передовий сервер роти та тиловий сервер батальйону потребують спільної обізнаності без передачі всього трафіку роти до тилу.
Коаліційні операції — партнерські сили працюють на окремих серверах під окремими адміністративними органами; федерація ділиться вибраними треками без надання повного адміністративного доступу до сервера будь-якої сторони.
Стійкість за задумом — два незалежні сервери кожен обслуговує підмножину клієнтів; якщо один виходить з ладу, інший продовжує роботу для своїх клієнтів, а федерація відновлюється автоматично при відновленні зв'язку.
Управління пропускною здатністю — фільтри на каналі федерації дозволяють передавати через межу лише оперативно необхідні типи CoT, зменшуючи трафік на обмежених тактичних каналах.

Архітектура федерації: «рівний до рівного» проти «зірки»

Перш ніж налаштовувати окремий канал, сплануйте топологію федерації. Вибір між «рівним до рівного» та «зіркою» має суттєві оперативні та технічні наслідки.

Федерація «рівний до рівного»

У топології «рівний до рівного» кожен TAK-сервер підтримує прямий федеративний канал з кожним іншим сервером у мережі. З двома серверами це тривіально один канал. З п'ятьма серверами — це десять каналів (n × (n−1) / 2), кожен з яких вимагає обміну сертифікатами, правилами брандмауера та незалежного моніторингу. Перевага полягає в тому, що трек проходить один федеративний стрибок від джерела до призначення: затримка мінімальна, а втрата будь-якого одного сервера впливає лише на клієнтів, безпосередньо підключених до нього. Недоліком є адміністративна складність — додавання шостого сервера вимагає налаштування п'яти нових каналів, обміну сертифікатами з п'ятьма існуючими адміністраторами та оновлення п'яти наборів правил брандмауера.

Федерація «зірка»

У топології «зірка» центральний вузловий сервер підтримує федеративні канали до всіх периферійних серверів; периферійні сервери підключаються лише до вузла. Трек, що виникає на периферійному сервері А, переходить до вузла, який пересилає його на периферійний сервер Б. Це додає один федеративний стрибок і тому збільшує наскрізну затримку (зазвичай 50–150 мс для добре підключеного вузла), але значно зменшує навантаження на конфігурацію. Додавання сьомого периферійного сервера вимагає лише одного нового каналу, одного обміну сертифікатами та одного правила брандмауера — все на вузлі. Вузол стає єдиною точкою відмови федерації: якщо він відключається, весь міжпериферійний обмін треками припиняється. Усуньте це резервною парою вузлів або прийміть ризик, якщо вузол знаходиться у захищеному місці з високою доступністю.

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

Налаштування федерації CloudTAK

CloudTAK повністю розкриває управління федерацією через свій REST API. Файл XML для редагування відсутній — всі федеративні канали зберігаються у базі даних CloudTAK та управляються через автентифіковані виклики API. Адміністративний інтерфейс CloudTAK також надає панель управління федерацією, але API є кращим для автоматизації та відтворюваних розгортань інфраструктури як коду.

Налаштування вихідного федеративного каналу

Спочатку розмістіть CA-сертифікат віддаленого сервера на вашому хості CloudTAK за шляхом, доступним контейнеру (наприклад, /opt/cloudtak/ssl/remote-ca.pem). Потім зареєструйте федеративний канал:

# Спочатку отримайте токен адміністратора
export ADMIN_TOKEN=$(curl -s -X POST https://tak.yourdomain.com:8443/api/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"YOUR_ADMIN_PASSWORD"}' | jq -r '.token')

# Зареєструйте федеративний канал
curl -s -X POST https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "BN-TAK-Server",
    "address": "tak.battalion.mil",
    "port": 9000,
    "protocol": "tls",
    "ca_cert": "/ssl/remote-ca.pem",
    "bidirectional": true,
    "enabled": true
  }'

Перевірте статус каналу через кілька секунд:

curl -s https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.[].status'
# Очікується: "connected"

Використання federation.json для інфраструктури як коду

CloudTAK також підтримує файл federation.json, підключений до контейнера, який декларативно визначає федеративні канали. Це корисно для розгортань під управлінням Terraform або Ansible, де токен API недоступний під час підготовки:

{
  "version": 1,
  "peers": [
    {
      "name": "BN-TAK-Server",
      "address": "tak.battalion.mil",
      "port": 9000,
      "ca_cert": "/ssl/remote-ca.pem",
      "bidirectional": true,
      "filters": {
        "cot_types": ["a-f-", "a-n-", "t-x-m-c"],
        "groups": ["Blue Force", "Command"]
      }
    }
  ]
}

Підключіть файл до контейнера, додавши запис тому до визначення служби Docker Compose: ./federation.json:/app/config/federation.json:ro. CloudTAK зчитує цей файл під час запуску та створює налаштовані канали, якщо вони ще не існують у базі даних.

Налаштування федерації застарілого TAK Server

Застарілий TAK Server (офіційний дистрибутив TAK.gov на Java) налаштовує федерацію через два XML-файли: CoreConfig.xml і federation-server.xml, обидва розташовані в /opt/tak/.

Увімкнення федеративного сервера в CoreConfig.xml

Знайдіть розділ <network> та увімкніть слухач федерації:

<!-- CoreConfig.xml: увімкнути слухач федерації -->
<network>
  ...
  <federation port="9000" v1Enabled="true" v2Enabled="true"
              useV1="false" useV2="true"
              allowMissionPackageUpload="false"
              missionPackageSizeLimit="157286400"
              missionPackageStartPort="8444"
              missionPackageStopPort="8448"/>
</network>

Параметри v2Enabled="true" і useV2="true" вмикають протокол Federation v2, який необхідний для взаємодії з CloudTAK. Federation v1 є застарілим і має бути вимкнений у нових розгортаннях.

Налаштування партнерів федерації у federation-server.xml

<?xml version="1.0" encoding="UTF-8"?>
<FederationServer>
  <Federation>
    <!-- Вихідне з'єднання до CloudTAK або іншого TAK Server -->
    <FederationOutgoing
      id="company-cloudtak"
      host="tak.company.mil"
      port="9000"
      reconnectInterval="5"
      maxRetries="10"
      fallback="false"
      enabled="true">
      <filtergroup direction="in" groupFilterName="BlueForce"/>
      <filtergroup direction="out" groupFilterName="BlueForce"/>
    </FederationOutgoing>
  </Federation>
</FederationServer>

Реєстрація сертифікатів для федерації застарілого TAK Server

Застарілий TAK Server використовує Java KeyStore (JKS) для якорів довіри федерації. Імпортуйте CA-сертифікат віддаленого сервера перед спробою підключення:

# Імпортуйте CA віддаленого сервера у сховище довіри федерації TAK Server
keytool -import \
  -trustcacerts \
  -alias cloudtak-ca \
  -file /opt/tak/ssl/cloudtak-ca.pem \
  -keystore /opt/tak/certs/files/fed-truststore.jks \
  -storepass atakatak

# Перезапустіть TAK Server для застосування змін
systemctl restart takserver

Пароль сховища ключів TAK Server за замовчуванням — atakatak — змініть його у будь-якому оперативному розгортанні, оновивши значення keystorePass у CoreConfig.xml і повторно імпортувавши всі сертифікати у нове сховище.

Фільтрація: контроль над тим, що перетинає межу федерації

За замовчуванням усі CoT-події, отримані TAK-сервером від своїх клієнтів, можуть бути переслані партнерам федерації. У більшості оперативних розгортань це занадто дозвільно. Фільтри дозволяють адміністраторам пропускати через межу федерації лише певні типи CoT, групи або шаблони позивних, зменшуючи споживання пропускної здатності на обмежених тактичних каналах і запобігаючи ненавмисному обміну інформацією.

Фільтри типів CoT

Типи CoT мають ієрархічну схему з крапковою нотацією. Поширені оперативні типи для дозволу через федерацію:

Префікс типу CoT	Опис	Типове використання у федерації
`a-f-`	Дружній атом	Завжди дозволяти — треки дружніх сил
`a-n-`	Нейтральний атом	Дозволяти, якщо спільна COP включає нейтральні треки
`a-h-`	Ворожий атом	Дозволяти лише якщо класифікація дозволяє обмін
`t-x-m-c`	Повідомлення чату	Дозволяти для чату ATAK між підрозділами
`b-`	Біти (потоки сенсорів/даних)	Блокувати за замовчуванням — великий обсяг, часто чутливі

Групові фільтри

Клієнти ATAK призначаються до груп (команд) у межах TAK Server — синя, червона, зелена, каштанова, жовта тощо. Групові фільтри на каналі федерації контролюють, події яких груп пересилаються. Для CloudTAK вкажіть дозволені групи у виклику API федерації:

curl -s -X PATCH https://tak.yourdomain.com:8443/api/federation/BN-TAK-Server \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "cot_types": ["a-f-", "a-n-", "t-x-m-c"],
      "groups": ["Blue", "Command", "Medevac"],
      "direction": "both"
    }
  }'

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

Безпека: взаємний TLS, закріплення сертифікатів і відкликання

Федеративні канали передають тактичні дані про треки через ворожі мережі. Модель безпеки повинна запобігати як пасивному перехопленню, так і активному підроблянню федеративного вузла.

Базовий рівень безпеки: кожен оперативний федеративний канал повинен використовувати взаємний TLS. Однобічне TLS-з'єднання (сервер автентифікується до клієнта, але не навпаки) дозволяє будь-якому хосту, що може дістатися порту 9000, впровадити CoT-події у вашу тактичну картину, видаючи себе за федеративний вузол. Ніколи не розгортайте федерацію з самопідписаними сертифікатами, якщо мережевий шлях не є фізично ізольованим.

Взаємний TLS між федеративними вузлами

Взаємний TLS (mTLS) вимагає, щоб як підключений сервер, так і приймаючий сервер представляли сертифікати під час TLS-рукостискання, і щоб кожен довіряв центру сертифікації іншого. Кроки налаштування відрізняються між CloudTAK і застарілим TAK Server:

Для CloudTAK взаємний TLS на федеративному порту вмикається за замовчуванням при зазначенні ca_cert у виклику API федерації. CloudTAK представляє власний серверний сертифікат (той самий, що використовується для клієнтських з'єднань) і перевіряє сертифікат віддаленого сервера відносно зазначеного CA. Додаткові прапорці конфігурації не потрібні.

Для застарілого TAK Server взаємний TLS на порту 9000 контролюється атрибутом clientAuth у CoreConfig.xml. Встановіть clientAuth="need" на федеративному конекторі, щоб вимагати представлення клієнтського сертифіката. Сертифікат підключеного сервера повинен бути підписаний CA, наявним у сховищі довіри федерації.

Закріплення сертифікатів

Закріплення сертифікатів виходить за рамки стандартної перевірки mTLS, обмежуючи прийнятий сертифікат конкретним відбитком сертифіката або CA, а не будь-яким сертифікатом, підписаним довіреним CA. Для федеративних каналів між відомими фіксованими вузлами закріпіть відбиток CA віддаленого сервера у конфігурації федерації. У CloudTAK це робиться шляхом зазначення "ca_pin": "SHA256:<відбиток>" у визначенні партнера федерації. Обчисліть відбиток за допомогою:

openssl x509 -in remote-ca.pem -noout -fingerprint -sha256 \
  | sed 's/://g' | awk -F= '{print $2}'

Відкликання сертифікатів

Коли сертифікат федеративного вузла необхідно відкликати — через компрометацію сервера, виведення з експлуатації або ротацію CA — процес відрізняється залежно від реалізації. Для CloudTAK видаліть партнера федерації через DELETE /api/federation/{name} і видаліть віддалений CA з файлової системи; канал негайно закриється і не може бути відновлений. Для застарілого TAK Server видаліть CA зі сховища довіри федерації за допомогою keytool -delete і перезапустіть службу. Якщо CA, що видає, підтримує точки розповсюдження CRL або OCSP, налаштуйте їх у політиці безпеки Java для онлайн-перевірки відкликання — хоча це є нездійсненним у відключених середовищах.

Тестування федерації: впровадження CoT, розповсюдження треків і затримка

Ніколи не припускайте, що федеративний канал працює, оскільки кінцева точка статусу повідомляє connected. Статус підключення означає, що TCP/TLS-сесія встановлена — це не означає, що події фактично надходять і з'являються на клієнтських картах. Єдиним надійним тестом є наскрізне впровадження треку та його перевірка.

Впровадження тестової CoT-події

Використовуйте скрипт впровадження CoT або утиліту tak-inject для надсилання синтетичного треку дружнього наземного підрозділу на Сервер А:

<?xml version="1.0" standalone="yes"?>
<event version="2.0"
  uid="FED-TEST-$(date +%s)"
  type="a-f-G-U-C"
  time="2026-05-29T12:00:00Z"
  start="2026-05-29T12:00:00Z"
  stale="2026-05-29T12:10:00Z"
  how="h-g-i-g-o">
  <point lat="48.1234" lon="24.5678" hae="200.0" ce="10.0" le="999999.0"/>
  <detail>
    <contact callsign="FED-TEST-ALPHA"/>
    <group name="Blue" role="Team Member"/>
  </detail>
</event>

Впровадьте цей CoT XML на Сервер А через TCP-порт 8089 (або через REST API CloudTAK за адресою POST /api/events). Потім підтвердьте, що позивний FED-TEST-ALPHA з'являється на клієнті ATAK, підключеному до Сервера Б, протягом 2–3 секунд.

Перевірка розповсюдження треків через адміністративний API

Перевірте лічильники подій федеративного каналу на Сервері А для підтвердження пересилання подій:

curl -s https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.[] | {name, status, events_forwarded, events_received}'

Справний двонаправлений канал повинен показувати ненульові значення як у events_forwarded (події, надіслані партнеру), так і в events_received (події, отримані від партнера) після тестового впровадження.

Вимірювання затримки

Затримка федерації — це час від надходження CoT-події на сервер-джерело до появи події на клієнті, підключеному до сервера-призначення. Вимірюйте її, зазначаючи часову мітку впровадження та фіксуючи момент появи треку за допомогою автоматизованого слухача WebSocket ATAK або WebSocket подій CloudTAK за адресою wss://tak.battalion.mil:8443/api/events. Очікуваний розподіл затримок:

Надходження та запис у БД на Сервері А: 5–20 мс
Доставка через TCP федерації до Сервера Б: RTT мережі / 2
Обробка на Сервері Б та широкомовлення клієнтам: 5–30 мс
Загалом (LAN/VPN): зазвичай 30–100 мс
Загалом (супутник/КХ): 500 мс–2 с залежно від каналу

Якщо затримка значно перевищує очікуваний діапазон, перевірте конкуренцію при записі в БД на Сервері Б (моніторинг через pg_stat_activity), розбіжність годинників між серверами та повторну передачу TCP на шляху федеративного каналу.

Типові проблеми: невідповідність сертифікатів, NAT, розбіжність годинників та брандмауери

Статус федеративного каналу постійно показує «connecting». TCP-з'єднання до порту 9000 на віддаленому сервері не встановлюється. Перевірте, чи відкритий порт: openssl s_client -connect remote-server:9000. Якщо з'єднання завершується тайм-аутом, брандмауер блокує з'єднання. Якщо повертається помилка SSL, порт досяжний, але перевірка сертифіката не проходить — перейдіть до усунення несправностей сертифікатів.

Помилка рукостискання TLS: «certificate verify failed». Сертифікат віддаленого сервера не підписаний CA у вашому сховищі довіри. Підтвердьте, що ви встановили правильний CA (не сам серверний сертифікат) і що CA-сертифікат не закінчився. Для CloudTAK: openssl verify -CAfile /ssl/remote-ca.pem <(openssl s_client -connect remote-server:9000 2>/dev/null | openssl x509). Має повернути stdin: OK.

Канал показує «connected», але треки з віддаленого сервера не з'являються. Найпоширенішою причиною є розбіжність годинників. Перевірте системний час на обох серверах: date -u. Якщо вони відрізняються більш ніж на 5 хвилин, CoT-події з сервера з ранішим годинником надійдуть на приймальний сервер уже застарілими та будуть відхилені. Налаштуйте NTP на обох хостах і зачекайте кілька хвилин для синхронізації годинників перед повторним тестуванням.

Треки видимі на Сервері Б, але не на клієнтах ATAK, підключених до Сервера Б. Це проблема фільтра, а не федерації — події надходять на Сервер Б, але фільтруються до досягнення клієнтів. Перевірте призначення клієнта ATAK до групи: якщо вхідні федеративні треки належать до групи «Blue», але клієнт налаштований бачити лише групу «Red», треки не з'являться. Також перевірте, чи підтримує версія ATAK клієнта тип CoT вхідних подій.

NAT між партнерами федерації спричиняє переривчасті розриви з'єднання. Пристрої зі статичним NAT відкидають TCP-сесії, що простоюють довше тайм-ауту NAT (зазвичай 30–300 секунд). Федеративні канали з низьким обсягом CoT-подій можуть простоювати досить довго, щоб досягти цього тайм-ауту. Налаштуйте TCP keepalive на федеративному з'єднанні: для CloudTAK встановіть "keepalive_seconds": 60 у визначенні партнера федерації. Для застарілого TAK Server додайте -Dsun.net.client.defaultConnectTimeout=60000 до прапорців запуску JVM у setenv.sh.

Федерація між CloudTAK і застарілим TAK Server завершується помилкою «protocol version mismatch». Переконайтеся, що застарілий TAK Server налаштований на Federation v2 (v2Enabled="true", useV2="true" у CoreConfig.xml). CloudTAK не підтримує застарілий протокол Federation v1. Версії застарілого TAK Server старші за 4.8 можуть не підтримувати Federation v2 — оновіть принаймні до 4.8 перед спробою взаємодії з CloudTAK.

З'єднайте ваші TAK-мережі між командуваннями

Ми проектуємо та налаштовуємо топології федерації TAK Server для оборонних та урядових організацій — включаючи розгортання CloudTAK, інтеграцію застарілого TAK Server і AI-копілот TAKpilot для федеративних тактичних картин.

TAKpilot AI Copilot → Замовити брифінг

Цей аналіз підготовлений інженерами Corvus Intelligence, які розробляють критично важливе програмне забезпечення для оборонних та урядових організацій. Дізнайтеся про нашу команду →

Часті запитання

Що таке федерація TAK Server?

Федерація TAK Server — це протокол, що дозволяє двом або більше окремим екземплярам TAK Server обмінюватися потоками подій Cursor-on-Target (CoT) у реальному часі. При увімкненій федерації підрозділи, підключені до Сервера А, з'являються на карті клієнтів, підключених до Сервера Б, і навпаки — створюючи спільну загальну оперативну картину (COP) через організаційні або географічні межі без об'єднання серверів у єдиний екземпляр.

Який порт використовує федерація TAK Server?

Федерація TAK Server за замовчуванням використовує TCP-порт 9000 як на застарілому TAK Server, так і на CloudTAK. Обидві кінцеві точки повинні мати відкритий порт 9000 у своїх брандмауерах та бути досяжними з IP-адреси партнерського сервера. Якщо між партнерами федерації знаходиться NAT або брандмауер, вихідне з'єднання ініціюється налаштованим основним партнером; переконайтеся, що TCP-сесія може бути встановлена через будь-який станційний брандмауер на шляху.

У чому різниця між федерацією «рівний до рівного» та «зіркою»?

У федерації «рівний до рівного» кожен TAK-сервер підтримує прямий федеративний канал до кожного іншого сервера — O(n²) з'єднань при зростанні мережі. У федерації «зірка» всі сервери підключаються до єдиного центрального вузлового сервера; кожен периферійний сервер потребує лише одного федеративного каналу. «Зірка» є оперативно простішою та більш стійкою до відмов периферійних серверів, але вводить вузол як єдину точку відмови та додає один стрибок затримки для доставки CoT між периферійними серверами.

Чи може CloudTAK об'єднуватися у федерацію із застарілим TAK Server?

Так. CloudTAK реалізує протокол федерації TAK Server і є сумісним із застарілим TAK Server (як офіційним дистрибутивом TAK.gov, так і FreeTAKServer). Федеративний канал налаштовується на стороні CloudTAK через REST API або файл federation.json, вказуючи на федеративний порт застарілого TAK Server (за замовчуванням 9000). Взаємні TLS-сертифікати повинні бути обмінені між двома розгортаннями перед встановленням каналу.

Як працюють групові фільтри у федерації TAK?

Групові фільтри дозволяють адміністраторам контролювати, які CoT-події перетинають межу федерації. У застарілому TAK Server фільтри визначаються у federation-server.xml з використанням префіксів типів CoT (наприклад, дозволити лише треки дружніх сил 'a-f-', блокувати події сенсорів 'b-'). У CloudTAK фільтри налаштовуються для кожного федеративного каналу через REST API як масив дозволених типів CoT або шаблонів позивних. Події, що не відповідають фільтру, не пересилаються на федеративний сервер, зменшуючи пропускну здатність і запобігаючи ненавмисному обміну даними.

Які сертифікати потрібні для федерації TAK?

Федерація TAK використовує взаємний TLS: кожен сервер повинен представити сертифікат іншому, і кожен повинен довіряти центру сертифікації іншого. На практиці це означає: (1) кожен сервер має серверний TLS-сертифікат, підписаний CA свого розгортання; (2) CA-сертифікат кожного розгортання повинен бути доданий до сховища довіри іншого розгортання. Для CloudTAK додайте шлях до CA-сертифіката віддаленого сервера у виклик API федерації. Для застарілого TAK Server імпортуйте CA віддаленого сервера у сховище ключів Java федерації за допомогою keytool.

Як перевірити, що федерація TAK працює?

Впровадьте тестову CoT-подію безпосередньо на один сервер за допомогою інструмента впровадження CoT або netcat, потім перевірте, що подія з'являється на клієнті, підключеному до федеративного сервера. Використовуйте тип CoT 'a-f-G-U-C' (дружній наземний підрозділ) з унікальним позивним, щоб його було легко ідентифікувати. Перевірте статус федеративного каналу через адміністративний API (GET /api/federation на CloudTAK) — справний канал показує статус: 'connected' з ненульовим лічильником events_forwarded.

Що спричиняє збій федерації TAK через розбіжність годинників?

CoT-події містять часову мітку 'stale'. Якщо годинник приймаючого сервера випереджає годинник сервера, що надсилає, більш ніж на 300 секунд (5 хвилин), він відхиляє вхідні події як уже застарілі. У федеративних середовищах це зазвичай проявляється як справний статус каналу (TCP підключений), але нульова кількість треків від віддаленого сервера. Виправте, переконавшись, що обидві кінцеві точки федерації синхронізуються з одним і тим же джерелом NTP — в ідеалі з NTP-сервером, дисциплінованим GPS, у оперативних розгортаннях.

Як усунути проблеми проходження через NAT у федерації TAK?

Федеративні з'єднання є вихідними TCP від ініціювального сервера до порту 9000 віддаленого сервера. Якщо на шляху знаходиться NAT, вихідна TCP-сесія проходить через NAT і відповідний трафік повертається по тій самій сесії — стандартний станційний NAT це обробляє. Проблеми виникають із симетричним NAT або правилами брандмауера, що блокують сесію за портом призначення. Перевірте з'єднання за допомогою: openssl s_client -connect remote-server:9000. Якщо рукостискання TLS не вдається, проблема у брандмауері або сертифікаті; якщо з'єднання відхиляється, порт не відкритий на віддаленій стороні.

Чи може федерація TAK фільтрувати пакети даних і файли, або лише CoT-події?

За замовчуванням федерація TAK Server пересилає лише потоки CoT-подій — треки, повідомлення чату та потоки сенсорів, закодовані CoT. Пакети даних (тайли карт, шейп-файли, DTED) та місіонерські пакети не реплікуються автоматично через федеративні канали. Для обміну пакетами даних між федеративними серверами використовуйте функцію Mission Sync TAK Server або вручну розповсюджуйте пакети на кожен сервер. REST API CloudTAK надає кінцеву точку /api/package/sync, що може надсилати пакети на налаштований список партнерів федерації.