Federacja TAK Server: Łączenie Wielu Sieci TAK Między Pododdziałami i Dowództwami

Powtarzającym się problemem w operacjach połączonych i koalicyjnych jest izolowana wyspa TAK: Pododdział Alpha ma własny TAK Server działający w strefie przedniego obszaru, Pododdział Bravo ma oddzielny serwer dwa szczeble wyżej, a żaden z nich nie widzi śladów drugiego na mapie. Federacja TAK Server to protokół zaprojektowany do rozwiązania tego problemu — łączy dwie lub więcej niezależnych instancji TAK Server, dzięki czemu strumienie zdarzeń CoT przepływają dwukierunkowo przez granicę, dając każdemu operatorowi ujednolicony wspólny obraz operacyjny (COP) bez przekształcania oddzielnych serwerów w pojedynczy punkt awarii. Niniejszy przewodnik obejmuje pełną ścieżkę federacji: decyzje architektoniczne, konfigurację REST API CloudTAK, konfigurację XML dla starszego TAK Server, filtry grup i typów CoT, bezpieczeństwo mTLS oraz systematyczną procedurę testowania poprawności propagacji śladów.

Czym jest federacja TAK Server i dlaczego ma znaczenie

Federacja to protokół serwer-serwer działający przez TCP port 9000 z wzajemnym TLS. Gdy dwa serwery TAK są sfederowane, każdy z nich ustanawia wychodzące połączenie TCP/TLS do portu federacji drugiego i zaczyna przekazywać wybrane zdarzenia CoT odbierane od własnych klientów. W efekcie żołnierz z ATAK podłączony do Serwera A widzi, w czasie rzeczywistym, ślady pododdziałów, których klienci ATAK są podłączeni do Serwera B — i odwrotnie. Po stronie klienta nie są wymagane żadne zmiany konfiguracji: federacja jest wyłącznie funkcją administracyjną serwera.

Przypadki operacyjne, które wymagają federacji zamiast jednego ujednoliconego serwera, obejmują:

Wdrożenia wieloszczeblowe — serwer kompanii na linii i serwer batalionu na tyłach potrzebują wspólnej świadomości sytuacyjnej, bez przesyłania całego ruchu kompanii na tyły.
Operacje koalicyjne — siły partnerskie działają na oddzielnych serwerach pod oddzielnymi organami administracyjnymi; federacja umożliwia udostępnianie wybranych śladów bez przyznawania pełnego dostępu administracyjnego do serwera którejkolwiek ze stron.
Odporność przez projekt — dwa niezależne serwery obsługują podzbiory klientów; jeśli jeden ulegnie awarii, drugi nadal działa dla swoich klientów, a federacja przywraca się automatycznie po przywróceniu łączności.
Zarządzanie przepustowością — filtry na łączu federacyjnym przepuszczają przez granicę tylko operacyjnie istotne typy CoT, zmniejszając ruch w ograniczonych łączach taktycznych.

Architektura federacji: peer-to-peer vs. hub-and-spoke

Przed skonfigurowaniem jakiegokolwiek łącza należy zaplanować topologię federacji. Wybór między peer-to-peer a hub-and-spoke ma istotne konsekwencje operacyjne i techniczne.

Federacja peer-to-peer

W topologii peer-to-peer każdy serwer TAK utrzymuje bezpośrednie łącze federacyjne z każdym innym serwerem w sieci. Przy dwóch serwerach jest to jedno łącze. Przy pięciu serwerach — dziesięć łączy (n × (n−1) / 2), z których każde wymaga wymiany certyfikatów, reguł zapory sieciowej i niezależnego monitorowania. Zaletą jest to, że ślad pokonuje jeden hop federacyjny od źródła do celu: opóźnienie jest minimalne, a utrata któregokolwiek serwera dotyczy tylko bezpośrednio do niego podłączonych klientów.

Federacja hub-and-spoke

W topologii hub-and-spoke centralny serwer hub utrzymuje łącza federacyjne ze wszystkimi serwerami spoke; serwery spoke łączą się tylko z hubem. Ślad z sieci Spoke A trafia do Huba, który przekazuje go do Spoke B. Dodaje to jeden hop federacyjny, zwiększając opóźnienie end-to-end (zazwyczaj 50–150 ms dla dobrze połączonego huba), ale znacznie zmniejsza nakład konfiguracyjny. Dla trzech lub więcej serwerów hub-and-spoke jest generalnie preferowany w środowiskach operacyjnych.

Konfiguracja federacji CloudTAK

CloudTAK udostępnia zarządzanie federacją wyłącznie przez REST API. Wszystkie łącza federacyjne są przechowywane w bazie danych CloudTAK i zarządzane przez uwierzytelnione wywołania API.

Konfigurowanie wychodzącego łącza federacyjnego

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
  }'

Używanie federation.json dla infrastruktury jako kodu

{
  "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"]
      }
    }
  ]
}

Konfiguracja federacji starszego TAK Server

Starszy TAK Server konfiguruje federację przez CoreConfig.xml i federation-server.xml, oba znajdujące się w /opt/tak/.

<federation port="9000" v1Enabled="true" v2Enabled="true"
            useV1="false" useV2="true"
            allowMissionPackageUpload="false"/>

keytool -import \
  -trustcacerts \
  -alias cloudtak-ca \
  -file /opt/tak/ssl/cloudtak-ca.pem \
  -keystore /opt/tak/certs/files/fed-truststore.jks \
  -storepass atakatak

systemctl restart takserver

Filtrowanie: kontrola tego, co przekracza granicę federacyjną

Filtry umożliwiają administratorom przepuszczanie przez granicę federacyjną tylko określonych typów CoT, grup lub wzorców callsign, zmniejszając zużycie przepustowości i zapobiegając niezamierzonemu udostępnianiu informacji.

Prefiks typu CoT	Opis	Typowe zastosowanie w federacji
`a-f-`	Atom przyjazny	Zawsze zezwalaj
`a-n-`	Atom neutralny	Zezwalaj, jeśli wspólny COP obejmuje ślady neutralne
`a-h-`	Atom wrogi	Zezwalaj tylko jeśli klasyfikacja na to pozwala
`t-x-m-c`	Wiadomość czat	Zezwalaj na czat między pododdziałami
`b-`	Bits (kanały sensorów)	Blokuj domyślnie

Bezpieczeństwo: wzajemny TLS, przypinanie certyfikatów i unieważnianie

Podstawa bezpieczeństwa: Każde operacyjne łącze federacyjne musi używać wzajemnego TLS. Nigdy nie wdrażaj federacji z certyfikatami self-signed, chyba że ścieżka sieciowa jest fizycznie izolowana.

W przypadku CloudTAK wzajemny TLS na porcie federacyjnym jest domyślnie włączony, gdy w wywołaniu API federacji podany jest ca_cert. Dla starszego TAK Server ustaw clientAuth="need" na łączniku federacyjnym w CoreConfig.xml. Przypnij odcisk palca zdalnego CA poleceniem:

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

Testowanie federacji: iniekcja CoT, propagacja śladów i opóźnienie

Nigdy nie zakładaj, że łącze federacyjne działa, bo punkt końcowy statusu zwraca connected. Jedynym wiarygodnym testem jest end-to-end iniekcja śladów i weryfikacja.

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

Typowe problemy: niezgodność certyfikatów, NAT, przesunięcie zegara i zapory sieciowe

Status łącza federacyjnego wyświetla "connecting" w nieskończoność. Sprawdź, czy port 9000 jest otwarty: openssl s_client -connect remote-server:9000.

Łącze wyświetla "connected", ale ślady nie pojawiają się. Najczęstszą przyczyną jest przesunięcie zegara — sprawdź date -u na obu serwerach. Jeśli różnią się o więcej niż 5 minut, zdarzenia CoT będą odrzucane jako nieaktualne.

Federacja między CloudTAK a starszym TAK Server kończy się błędem "protocol version mismatch". Upewnij się, że starszy TAK Server jest skonfigurowany dla Federation v2 i ma wersję 4.8 lub nowszą.