TAK Federation Hub: architektura, konfiguracja i kiedy wybrać go zamiast federacji bezpośredniej

TAK Federation Hub to opcjonalny broker wydany razem z TAK Server. Zamiast federowania się każdego TAK Server bezpośrednio z każdym, każdy serwer otwiera jedno połączenie federacyjne do huba; hub uwierzytelnia federatów i przekazuje dane zgodnie ze zdefiniowanym przez administratora grafem polityki z filtrami grup na każdej krawędzi. Używaj go, gdy łączysz więcej niż trzy serwery lub kilka domen administracyjnych.

Ta strona dotyczy decyzji architektonicznej (hub a bezpośrednia federacja serwer–serwer) i tego, co wiąże się z eksploatacją huba: wersje protokołu i domyślne porty, model polityki, PKI, wdrożenie, eksploatacja i rozwiązywanie problemów. Aby skonfigurować pojedyncze bezpośrednie połączenie między dwoma serwerami, sięgnij po nasz poradnik konfiguracji federacji TAK Server.

• Co to jest: broker w topologii hub-and-spoke dla federacji TAK Server (menedżer polityki, broker komunikatów, interfejs webowy administracji).
• Domyślne porty: 9102/tcp — federacja v2, 9101/tcp — federacja v1, 9100/tcp — panel administracyjny.
• Zależności: Java 17 i MongoDB; dystrybuowany jako RPM, DEB i pakiet Docker.
• Dojrzałość: oficjalny przewodnik konfiguracji TAK Server (wersja 5.7, marzec 2026) wciąż oznacza instalator huba jako „beta”.

Po co Federation Hub: problem N² bezpośredniej federacji

Bezpośrednia federacja to dwustronna umowa zaimplementowana w oprogramowaniu. Zgodnie z przewodnikiem konfiguracji TAK Server dwaj administratorzy wymieniają się certyfikatami CA; każdy serwer przechowuje je w magazynie zaufania federacji, oddzielnym od magazynu dla lokalnych użytkowników, więc serwer partnera może się połączyć, ale urządzenia ATAK partnera już nie. Jeden z dwóch serwerów tworzy połączenie wychodzące, a obie strony wybierają, które grupy mogą opuszczać ich serwer i do niego napływać. Klienci nie wymagają rekonfiguracji.

Dla dwóch–trzech serwerów to wystarcza. Pełna siatka (full mesh) n serwerów wymaga n(n−1)/2 połączeń: 6 dla czterech serwerów, 45 dla dziesięciu. Każde połączenie oznacza wymianę CA, otwarcie w zaporze sieciowej po stronie nasłuchującej i ustawienia grup na obu końcach, a każda zmiana polityki jest powtarzana dla każdego łącza.

Federation Hub zastępuje siatkę topologią gwiazdy. Każdy TAK Server federuje się raz — z hubem, który zarządza połączeniami i zaufaniem oraz pośredniczy w każdym komunikacie wzdłuż krawędzi grafu polityki, z filtrowaniem po grupach TAK. Zmieniają się trzy rzeczy:

• Zaufanie: każdy TAK Server importuje jeden zewnętrzny CA — CA huba — zamiast po jednym na każdego partnera. CA partnerów trzyma hub.
• Osiągalność: spoke zwykle nawiązują połączenia wychodzące do huba, więc serwery przednie za NAT lub za zaporami jednokierunkowymi nie potrzebują otwarć przychodzących. Nasłuchuje tylko hub.
• Polityka: kto co otrzymuje, żyje w jednym grafie zamiast w dziesiątkach ustawień na każdym serwerze, przy czym każdy serwer nadal kontroluje, co opuszcza jego granice.

Koszty też są realne: dodatkowy przeskok brokera na każdym komunikacie międzyserwerowym, nowy system wysokiej wartości, który kończy każdą sesję federacyjną i widzi cały ruch pośredniczony, oraz pojedynczy punkt awarii dla wymiany między serwerami. Gdy hub jest niedostępny, lokalny obraz na każdym serwerze dalej działa; zatrzymuje się tylko wymiana.

Wersje protokołu federacji i domyślne porty

TAK Server posługuje się dwoma protokołami federacji. Federacja v1 to oryginał: długotrwałe gniazdo TLS przenoszące zdarzenia federacyjne w kodowaniu protobuf. Federacja v2 przenosi komunikaty protobuf przez gRPC (HTTP/2) z tym samym wzajemnym TLS i to ona jest włączona w przykładowej konfiguracji TAK Server, podczas gdy v1 jest dostarczana wyłączona. Protokół wybiera się dla każdego połączenia wychodzącego, a ostrzeżenie z przewodnika obowiązuje: wybierz wersję protokołu odpowiadającą portowi, z którym się łączysz. O stronie klienckiej czytaj w porównaniu protokołów TAK: CoT XML kontra protobuf.

To wartości domyślne; potwierdź je we własnych plikach. Przykładowa konfiguracja 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>

Oraz konfiguracja brokera huba, /opt/tak/federation-hub/configs/federation-hub-broker.yml (fragment):

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

Praktyczna reguła: ustandaryzuj wszystkie połączenia na v2, skieruj połączenia wychodzące TAK Server na port 9102 huba i wyłącz v1 na hubie, chyba że wciąż potrzebuje jej starszy partner. Zależy od tego też filtrowanie grup: połączenia v1 nie przekazują hubowi informacji o grupach TAK, więc każda krawędź filtrująca po grupie odrzuca ruch v1.

Jak Federation Hub kieruje ruchem: graf polityki i filtry grup

Hub działa jako współpracujące usługi Javy pod jedną usługą systemową federation-hub: menedżer polityki, broker komunikatów i administracyjny interfejs webowy (nowsze pakiety dodają menedżer wtyczek). Trasowanie pochodzi z grafu polityki rysowanego w interfejsie. Jego węzły to:

• Grupy CA: każdy federat, którego certyfikat wywodzi się łańcuchem z przesłanego CA, dołącza do grupy tego CA. Większość polityk pisze się pod grupy CA, co w praktyce oznacza pod organizacje.
• Federaci: pojedyncze TAK Server — gdy jeden serwer wymaga innego traktowania niż reszta jego organizacji.
• Połączenia wychodzące: połączenia, które sam hub otwiera do TAK Server lub innego huba; tak buduje się wieloskokowe topologie hub–hub.
• Grupy tokenowe: federaci uwierzytelniający się tokenami zamiast wzajemnym TLS.

Krawędzie są skierowane. Krawędź od A do B pozwala ruchowi A dotrzeć do B, ale nie odwrotnie, więc wymiana dwukierunkowa wymaga dwóch krawędzi, a przepływy jednokierunkowe (partner odbiera wasz obraz sił własnych, ale niczego nie odsyła) to w pełni wspierany wzorzec. Każda krawędź niesie filtr grup: wszystkie grupy, grupy dozwolone, grupy zablokowane albo dozwolone i zablokowane. Grupy to grupy TAK Server dołączone do każdego komunikatu, które użytkownicy ATAK widzą jako kanały. Komunikat przechodzi krawędź z listą dozwolonych, jeśli co najmniej jedna z jego grup jest na liście, i nie przechodzi krawędzi z listą zablokowanych, jeśli którakolwiek z jego grup jest na liście; komunikat bez grup przechodzi tylko krawędź „wszystkie grupy”.

Grupy CA mają dodatkowo flagę Interconnected: członkowie takiej grupy wymieniają się wszystkim nawzajem — bez krawędzi i bez filtrowania. To wygodne wewnątrz jednej organizacji i niebezpieczne w koalicji, więc sprawdzaj ją przy każdej dodawanej grupie. Edytor rozdziela też zapisanie polityki od jej aktywacji; zapisana, ale nieaktywna polityka niczego nie zmienia.

Minimalizacja danych: trzy etapy filtrowania

1. Źródłowy TAK Server: grupy wychodzące ustawione dla federata huba decydują, co w ogóle opuszcza wasz serwer. W koalicji to jedyny etap, którym w pełni zarządzacie.
2. Krawędzie huba: decydują, które adresaty otrzymują które grupy.
3. Docelowy TAK Server: grupy przychodzące i mapowanie grup sfederowanych decydują, którzy lokalni użytkownicy widzą ruch przychodzący.

Pliki wymagają własnych reguł. Bloker Data Package i Mission File w TAK Server blokuje pliki federacyjne po rozszerzeniu (domyślnie pref, więc pliki konfiguracyjne nie mogą przekonfigurować urządzeń partnerów), a federacja misji to odrębna od udostępniania CoT decyzja; zobacz pakiety danych i pakiety misji TAK. Przewodnik formułuje też granicę wprost: każda domena kontroluje to, co udostępnia, a nie to, co druga domena z tym robi. Klienci pozostają poza tym wszystkim: ATAK, WinTAK i klienci przeglądarkowi tacy jak CloudTAK nadal rozmawiają z własnym serwerem.

Model zaufania certyfikatów: CA, tożsamości federatów i unieważnianie

Zaufanie federacji opiera się na CA i wzajemnym TLS. W topologii z hubem:

• Każdy TAK Server importuje CA huba do swojego magazynu zaufania federacji (interfejs huba potrafi pobrać własne CA) i przedstawia swój certyfikat serwera przy połączeniu.
• Hub importuje CA każdej organizacji; przesłanie go tworzy grupę CA, do której odwołuje się polityka.
• Tożsamością federata jest jego certyfikat, a łańcuch wystawienia decyduje o jego grupach CA. Serwer, którego łańcuch obejmuje pośrednie CA, może trafić do kilku grup CA — wtedy krawędzie wszystkich muszą zezwalać na ruch.

Z tego wynikają cztery reguły projektowe:

• Używaj dedykowanego CA federacji na organizację. Przewodnik konfiguracji opisuje ten wariant alternatywny — osobne CA i certyfikat serwera używane wyłącznie do federacji — aby partnerzy nigdy nie zobaczyli CA podpisującego wasze certyfikaty klientów, a usunięcie jednego CA z huba odcina dokładnie jedną organizację.
• Zaplanuj unieważnianie, zanim będzie potrzebne. Krawędzie pisane pod grupą CA mają zastosowanie do każdego serwera z tego CA. Aby odciąć jeden przejęty serwer bez ruszania jego organizacji, dawaj partnerom wysokiego ryzyka krawędzie per federat albo polegaj na sprawdzaniu unieważnień (broker huba ma opcję OCSP, domyślnie wyłączoną). Odcięte sieci bez respondera OCSP opierają się na krótkich okresach ważności certyfikatów i wyćwiczonej procedurze usunięcia CA.
• Chroń klucz huba jak klucz CA i zmień domyślne hasła magazynów kluczy (atakatak w dostarczonych przykładach): kto dzierży klucz huba, może podszywać się pod niego przed każdym spoke.
• Traktuj uwierzytelnianie tokenem jako wyjątek. TAK Server i hub mogą uwierzytelniać federację tokenami tam, gdzie proxy z inspekcją TLS („break and inspect”) uniemożliwiają wzajemny TLS; sam przewodnik zauważa, że tokeny są mniej bezpieczne niż mTLS.

O projektowaniu PKI między krajami partnerskimi czytaj w materiale o zarządzaniu tożsamością w koalicji.

Instalacja i opcje wdrożenia Federation Hub

Hub jest dystrybuowany na tak.gov jako osobny pakiet obok TAK Server: takserver-fed-hub jako RPM (RHEL, Rocky) lub DEB (Ubuntu, Debian), plus pakiet Docker łączący obraz huba z osobnym obrazem MongoDB. Wymaga Java 17 i MongoDB, gdzie broker przechowuje zdarzenia federacyjne i metadane, i działa z kolokowanym TAK Server lub bez niego. Hubowi teatru działań czy koalicji daj dedykowany host: to kotwica zaufania dla każdego partnera i nie powinien dzielić domeny awarii ani zespołu administracji z żadnym spoke.

1. PKI. Utwórz CA huba i certyfikat serwera tymi samymi skryptami i procedurą co dla TAK Server (dodatek B przewodnika konfiguracji); magazyn kluczy i magazyn zaufania leżą pod /opt/tak/federation-hub/certs/files/.
2. Instalacja. Zainstaluj Java 17, pakiet huba i MongoDB; ustaw poświadczenia bazy w federation-hub-broker.yml i uruchom skrypt konfiguracji bazy huba.
3. Start i autoryzacja. Uruchom usługę, autoryzuj certyfikat administratora i zaloguj się nim w interfejsie na porcie 9100 (polecenia poniżej).
4. Wymiana CA. Prześlij CA federacji każdego partnera w interfejsie huba i wyślij każdemu partnerowi CA huba.
5. Narysuj politykę. Dodaj grupy CA (i pojedynczych federatów tam, gdzie trzeba), połącz je krawędziami skierowanymi, ustaw filtr grup na każdej krawędzi, zdecyduj o Interconnected dla każdej grupy, a następnie zapisz i aktywuj.
6. Podepnij każdy TAK Server. Włącz federację v2, prześlij CA huba pod Federate Certificate Authorities, utwórz połączenie wychodzące do huba na 9102 z protokołem v2, a potem ustaw grupy wychodzące i przychodzące federata huba.
7. Przetestuj oba kierunki. Wyślij znany tor testowy w grupie, która ma przechodzić, i jeden w grupie, która ma być blokowana (nasze opatrzone komentarzem przykłady komunikatów CoT to dogodne materiały testowe), a następnie sprawdź, czy widok Active Connections huba pokazuje oczekiwaną wersję protokołu i tożsamości grupowe.

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

Wysoka dostępność Federation Hub i monitoring

Publiczna dokumentacja Federation Hub nie opisuje huba klastrowanego w trybie active-active, więc planuj szybką ciepłą rezerwę zamiast zerowego przestoju:

• Backupuj stan huba: certyfikaty i magazyny kluczy, pliki polityki, authorized_users.yml, katalog configs i bazę MongoDB. Notatki o aktualizacji huba każą najpierw zapisać plik polityki i użytkowników autoryzowanych.
• Trzymaj rezerwę z identycznymi certyfikatami i polityką za nazwą DNS lub wirtualnym IP, który można przenieść. TAK Server łączą się ponownie same — w interwale ponownego łączenia ustawionym na każdym połączeniu wychodzącym.
• Zadbaj o odporność spoke: awaria huba zatrzymuje wymianę, nie operacje lokalne, więc większość pracy nad dostępnością przypada każdemu serwerowi; zobacz wysoką dostępność i klastrowanie TAK Server.
• Wymiaruj z pomiarów: nie ma odrębnego opublikowanego sizingu huba. Wyjdź od bazowej konfiguracji TAK Server z przewodnika (4 rdzenie, 8 GB RAM, 40 GB dysku), potem obserwuj stertę i intensywność komunikatów pod obciążeniem ćwiczeń; serwerowe dźwignie opisuje strojenie wydajności TAK Server.

Monitoruj na trzech poziomach. W interfejsie huba pulpit metryk pokazuje łączne połączenia, odczyty i zapisy na sekundę, bajty na sekundę, CPU i stertę, a tabela Active Connections wymienia dla każdego federata adres zdalny, wersję protokołu i tożsamości grupowe. Na hostach zbieraj /opt/tak/federation-hub/logs i śledź status federacji każdego TAK Server. Z zewnątrz sonduj 9102 i 9100, alarmuj na wygasanie certyfikatów — każdego CA federata i każdego certyfikatu serwera — śledź offset NTP i alarmuj, gdy liczba podłączonych federatów spadnie poniżej oczekiwanej.

Wzorce operacyjne: hub teatru działań, koalicyjny, ćwiczebny i domenowy

Hub teatru działań

Podległe pododdziały prowadzą własne TAK Server i federują się w górę, do huba w wyższym sztabie. Pododdziały zachowują lokalny obraz, gdy zawodzi łącze szkieletowe (backhaul), hub decyduje, który szczebel widzi które grupy, a spoke z inicjatywą połączenia pasują serwerom przednim za NAT lub za terminalami satelitarnymi.

Hub koalicyjny

Każde państwo zachowuje własny TAK Server, CA i administratorów; hub prowadzony przez państwo wiodące lub wzajemnie zaufaną stronę niesie wspólny obraz, a krawędzie skierowane i listy dozwolonych kodują decyzje o udostępnianiu. Narodowe grupy wychodzące pozostają pierwszą linią kontroli. Gdzie koalicja używa też formatów NATO, brama na granicy narodowej wykonuje translację; zobacz splatanie CoT ze standardami NATO oraz wdrożenie afilianta FMN.

Hub ćwiczebny

Hub z własnym CA ćwiczeń, krótkotrwałymi certyfikatami i polityką scenariuszową pozwala uczestnikom dołączać i odchodzić bez dotykania cudzych serwerów. Potem usuwasz jedno CA i wycofujesz politykę; w trakcie zdarzenia tabela połączeń huba służy jednocześnie za tablo obecności i stanu.

Po jednym hubie na domenę klasyfikacyjną

Hub filtruje po grupach; nie jest strażnikiem międzydomenowym. Nie bada treści pod kątem reguł udostępniania i nie ma akredytacji na przenoszenie danych między poziomami klasyfikacji. Prowadź osobny hub na każdą domenę bezpieczeństwa i łącz domeny wyłącznie przez akredytowane rozwiązanie międzydomenowe (CDS) — osobny produkt z własną akredytacją; zobacz architekturę rozwiązania międzydomenowego.

Huby mogą też otwierać połączenia wychodzące do innych hubów, więc hub narodowy może się sparować z koalicyjnym. Trzymaj takie łańcuchy krótkie: każdy przeskok dodaje opóźnienie i kolejną politykę do utrzymania w spójności.

Rozwiązywanie problemów z połączeniami Federation Hub

• Nawiązanie TLS nie przechodzi albo łącze wciąż się łączy ponownie. Zwykle łańcuch: spoke musi ufać CA huba (nie tylko jego certyfikatowi serwera), hub musi trzymać CA wystawiające spoke wraz z pośrednimi, nikt nie mógł podmienić certyfikatu klienta i nic nie mogło wygasnąć.
• Połączono, ale nic nie płynie. Polityka, nie sieć: czy grupa CA spoke jest w aktywnej polityce, czy istnieje krawędź w oczekiwanym kierunku, czy serwer źródłowy ustawił grupy wychodzące dla federata huba, czy cel ustawił grupy przychodzące?
• Część grup płynie, część nie. Nazwy grup muszą zgadzać się co do znaku, komunikat bez grup przechodzi tylko krawędzie „wszystkie grupy”, a połączenia v1 nie niosą grup. Na odbierającym TAK Server mapowanie grup sfederowanych spada do ustawień grup federata, gdy żadne mapowanie nie pasuje.
• Płynie za dużo. Szukaj najpierw grupy CA z Interconnected albo krawędzi „wszystkie grupy”.
• Rozjazd zegarów. Walidacja certyfikatów oraz czas i świeżość CoT zależą od zegara; uruchom NTP ze wspólnego źródła na hubie i każdym spoke.
• Zapora, NAT i proxy. Hub musi przyjmować 9102/tcp (a 9100/tcp tylko z sieci administracyjnych); zapory stanowe z krótkim limitem bezczynności zrywają spokojne połączenia; proxy z inspekcją TLS łamią wzajemny TLS — wyłącz federację spod inspekcji albo użyj uwierzytelniania tokenem.
• Niezgodność wersji. Połączenie wychodzące ustawione na v2, ale skierowane na port v1 — albo odwrotnie — nigdy nie wstanie.
• Serwery klonowane. TAK Server zapisuje losowy identyfikator serwera do CoreConfig.xml przy pierwszym starcie i stempluje nim przetworzone komunikaty jako znacznik przepływu, odrzucając wszystko, co już niesie jego własny znacznik, by zapobiegać pętlom trasowania. Federaci zbudowani ze sklonowanego, już zainicjowanego serwera współdzielą ten ID; daj każdemu własny.

# 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

Bezpośrednia federacja vs Federation Hub vs jeden wspólny TAK Server

Praktyczna reguła: przy dwóch–trzech stabilnych partnerach federuj się bezpośrednio. Przy czterech i więcej serwerach, kilku domenach administracyjnych albo liście partnerów zmieniającym się co ćwiczenia użyj huba. Dla jednej organizacji z jednym zespołem administracji pojedynczy sklastrowany TAK Server z grupami jest prostszy niż jakakolwiek federacja.

Lista kontrolna planowania federacji

1. Zrób rejestr każdego federata: właściciel, wersja TAK Server, osiągalność i protokół (v2).
2. Wybierz topologię według tabeli powyżej; wskaż operatora huba i kto zatwierdza jego konfigurację.
3. Zaprojektuj PKI: CA federacji na organizację, okresy ważności certyfikatów, daty odnowienia i procedurę unieważniania; zmień domyślne hasła magazynów kluczy.
4. Uzgodnij z partnerami katalog grup: dokładne nazwy grup, co każdy serwer wysyła (wyjście) i przyjmuje (wejście).
5. Narysuj graf polityki najpierw na papierze: krawędzie skierowane, typ filtra na każdej krawędzi i wyraźna decyzja Interconnected dla każdej grupy CA.
6. Zdecyduj o federacji plików i misji osobno od CoT i nie wyłączaj blokera plików pref.
7. Otwórz zaporę: 9102/tcp przychodząco do huba, 9100/tcp tylko z sieci administracyjnych, dla spoke wyłącznie wychodząco; sprawdź limity bezczynności NAT i inspekcję TLS.
8. Zsynchronizuj czas na każdym hoście.
9. Napisz macierz testów z jednym przypadkiem obowiązkowo przechodzącym i jednym obowiązkowo blokowanym na każdą krawędź i powtarzaj ją po każdej zmianie polityki.
10. Ustaw monitoring, kopie zapasowe i wyćwiczone przejście na hub zapasowy.
11. Trzymaj jeden hub na domenę bezpieczeństwa; wszystko, co przekracza domeny, idzie przez akredytowane rozwiązanie międzydomenowe.