TAK Federation Hub: arhitectură, configurare și când îl alegeți în locul federației directe

TAK Federation Hub este un broker opțional lansat împreună cu TAK Server. În loc ca fiecare TAK Server să se federeze direct cu toate celelalte, fiecare server deschide o singură conexiune de federație către hub; hubul autentifică federații și transmite datele conform unui graf de politici definit de administrator, cu filtre de grupuri pe fiecare muchie. Folosiți-l de îndată ce conectați mai mult de trei servere sau mai multe domenii administrative.

Această pagină acoperă decizia de arhitectură (hub versus federație directă de la server la server) și ce presupune operarea unui hub: versiunile de protocol și porturile implicite, modelul de politici, PKI, implementarea, operarea și depanarea. Pentru a configura o singură legătură directă între două servere, folosiți ghidul nostru de configurare a federației TAK Server.

• Ce este: un broker de tip hub-and-spoke pentru federația TAK Server (manager de politici, broker de mesaje, interfață web de administrare).
• Porturi implicite: 9102/tcp federație v2, 9101/tcp federație v1, 9100/tcp interfață de administrare.
• Dependențe: Java 17 și MongoDB; livrat ca RPM, DEB și pachet Docker.
• Maturitate: ghidul de configurare TAK Server (versiunea 5.7, martie 2026) marchează încă instalatorul hubului drept „beta”.

De ce un Federation Hub: problema N² a federației directe

Federația directă este un acord bilateral implementat în software. Conform ghidului de configurare TAK Server, doi administratori fac schimb de certificate CA, pe care fiecare server le păstrează într-un truststore de federație separat de cel pentru utilizatorii locali, astfel încât serverul partenerului se poate conecta, dar dispozitivele ATAK ale partenerului nu. Unul dintre cele două servere creează conexiunea de ieșire, iar ambele părți aleg ce grupuri pot ieși de pe serverul lor și pot intra pe el. Clienții nu necesită reconfigurare.

Este acceptabil pentru două-trei servere. O rețea complet conectată (full mesh) de n servere necesită n(n−1)/2 legături: 6 pentru patru servere, 45 pentru zece. Fiecare legătură înseamnă un schimb de CA, o deschidere în firewall pe partea care ascultă și setări de grupuri la ambele capete, iar fiecare schimbare de politică se repetă pe fiecare legătură.

Federation Hub înlocuiește meshul cu o stea. Fiecare TAK Server se federează o singură dată, cu hubul, care gestionează conexiunile și încrederea și intermediază fiecare mesaj de-a lungul muchiilor unui graf de politici, filtrat după grupurile TAK. Trei lucruri se schimbă:

• Încrederea: fiecare TAK Server importă un singur CA extern, cel al hubului, în loc de câte unul pentru fiecare partener. CA-urile partenerilor le deține hubul.
• Accesibilitatea: spoke-urile apelează de obicei ele către hub, deci serverele avansate din spatele NAT sau al firewall-urilor unidirecționale nu au nevoie de deschideri de intrare. Doar hubul ascultă.
• Politica: cine primește ce stă într-un singur graf în loc de zeci de setări pe fiecare server, iar fiecare server continuă să controleze ce pleacă de la el.

Costurile sunt la fel de reale: un salt suplimentar de broker pe fiecare mesaj între servere, un nou sistem de valoare ridicată care termină fiecare sesiune de federație și vede tot traficul intermediat, plus un punct unic de defecțiune pentru schimbul dintre servere. Când hubul cade, imaginea locală a fiecărui server continuă să funcționeze; se oprește doar schimbul.

Versiunile protocolului de federație și porturile implicite

TAK Server vorbește două protocoale de federație. Federația v1 este originalul: un socket TLS de lungă durată care transportă evenimente de federație codificate protobuf. Federația v2 transportă mesaje protobuf peste gRPC (HTTP/2) cu același TLS mutual și este versiunea activată în configurația exemplu a TAK Server, unde v1 vine dezactivată. Protocolul se alege pentru fiecare conexiune de ieșire, iar avertizarea ghidului se aplică: alegeți versiunea de protocol care corespunde portului la care vă conectați. Pentru partea de client, vezi protocolul TAK: CoT XML versus protobuf.

Acestea sunt valori implicite; confirmați-le în fișierele dumneavoastră. Configurația exemplu a 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>

Și configurația brokerului hubului, /opt/tak/federation-hub/configs/federation-hub-broker.yml (extras):

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

Regula practică: standardizați toate conexiunile pe v2, îndreptați conexiunile de ieșire ale TAK Server către portul 9102 al hubului și dezactivați v1 pe hub, cu excepția cazului în care un partener vechi îl mai necesită. Filtrarea pe grupuri depinde și ea de asta: conexiunile v1 nu transmit hubului informații despre grupurile TAK, deci orice muchie care filtrează după grup respinge traficul v1.

Cum direcționează Federation Hub traficul: graful de politici și filtrele de grupuri

Hubul rulează ca servicii Java care cooperează sub un singur serviciu de sistem federation-hub: un manager de politici, un broker de mesaje și o interfață web de administrare (pachetele recente adaugă un manager de plugin-uri). Rutarea provine dintr-un graf de politici pe care îl desenați în interfață. Nodurile lui sunt:

• Grupuri de CA: orice federaț al cărui certificat se leagă în lanț de un CA încărcat intră în grupul acelui CA. Majoritatea politicilor se scriu împotriva grupurilor de CA, adică în practică împotriva organizațiilor.
• Federați: TAK Server individuale, pentru când un server are nevoie de un tratament diferit de restul organizației lui.
• Conexiuni de ieșire: conexiuni pe care hubul însuși le deschide către un TAK Server sau alt hub — așa se construiesc topologiile multi-salt de la hub la hub.
• Grupuri cu token: federați care se autentifică cu tokenuri în loc de TLS mutual.

Muchiile sunt orientate. O muchie de la A la B permite traficului din A să ajungă la B, nu și invers, deci partajarea bidirecțională cere două muchii, iar fluxurile unidirecționale (un partener care primește imaginea forțelor proprii dar nu trimite nimic înapoi) sunt un tipar perfect suportat. Fiecare muchie poartă un filtru de grupuri: toate grupurile, grupuri permise, grupuri interzise sau permise și interzise. Grupurile sunt grupurile TAK Server atașate fiecărui mesaj, pe care utilizatorii ATAK le văd ca canale. Un mesaj trece de o muchie cu listă de permisiuni dacă cel puțin unul dintre grupurile lui este pe listă și pică la o muchie cu listă de interdicții dacă oricare dintre grupurile lui este pe listă; un mesaj fără grupuri trece doar de o muchie cu toate grupurile.

Grupurile de CA au și un indicator Interconnected: membrii unui grup interconnected fac schimb de absolut tot între ei, fără muchie și fără filtrare. Comod în interiorul unei organizații și periculos într-o coaliție — verificați-l la fiecare grup pe care îl adăugați. Editorul separă de asemenea salvarea unei politici de activarea ei; o politică salvată dar inactivă nu schimbă nimic.

Minimizarea datelor: trei etape de filtrare

1. TAK Server sursă: grupurile de ieșire setate pentru federațul hubului decid ce pleacă de pe serverul dumneavoastră. Într-o coaliție, aceasta este singura etapă pe care o controlați pe deplin.
2. Muchiile hubului: decid ce destinații primesc ce grupuri.
3. TAK Server destinație: grupurile de intrare și maparea grupurilor federate decid ce utilizatori locali văd traficul de intrare.

Fișierele au nevoie de reguli proprii. Blocantul de Data Package și Mission File din TAK Server blochează fișierele federate după extensie (pref implicit, astfel încât fișierele de configurare să nu poată reconfigura dispozitivele partenerilor), iar federația misiunilor este o decizie separată de partajarea CoT; vezi pachetele de date și pachetele de misiune TAK. Ghidul enunță și limita direct: fiecare domeniu controlează ce partajează, nu ce face celălalt domeniu cu datele. Clienții rămân în afara toate acestora: ATAK, WinTAK și clienții de browser precum CloudTAK continuă să vorbească cu propriul server.

Modelul de încredere al certificatelor: CA, identitățile federaților și revocarea

Încrederea în federație este TLS mutual bazat pe CA. Într-o topologie cu hub:

• Fiecare TAK Server importă CA-ul hubului în truststore-ul său de federație (interfața hubului poate descărca propriul CA) și își prezintă certificatul de server la conectare.
• Hubul importă CA-ul fiecărei organizații; încărcarea creează grupul de CA la care se referă politica.
• Identitatea unui federaț este certificatul său, iar lanțul de emitere îi determină grupurile de CA. Un server al cărui lanț include un CA intermediar poate ajunge în mai multe grupuri de CA — atunci muchiile tuturor trebuie să permită traficul.

Din acestea decurg patru reguli de proiectare:

• Folosiți un CA de federație dedicat pentru fiecare organizație. Ghidul de configurare descrie această variantă alternativă — un CA și un certificat de server separate, folosite doar pentru federație — astfel încât partenerii să nu vadă niciodată CA-ul care semnează certificatele voastre de client, iar eliminarea unui CA din hub decoptează exact o organizație.
• Planificați revocarea înainte să aveți nevoie de ea. Muchiile scrise împotriva unui grup de CA se aplică fiecărui server din acel CA. Pentru a deconecta un server compromis fără să atingeți organizația lui, dați partenerilor cu risc ridicat muchii pe federaț sau bazați-vă pe verificarea revocării (brokerul hubului are o opțiune OCSP, implicit oprită). Rețelele izolate fără responder OCSP se bazează pe durate scurte de valabilitate și pe un exercițiu repetat de eliminare a CA-ului.
• Protejați cheia hubului ca pe o cheie de CA și schimbați parolele implicite ale keystore-urilor (atakatak în exemplele livrate): cine deține cheia hubului se poate da drept el în fața fiecărui spoke.
• Tratați autentificarea cu token ca excepție. TAK Server și hubul pot autentifica federația cu tokenuri acolo unde proxy-urile cu inspecție TLS („break and inspect”) fac TLS-ul mutual imposibil; ghidul însuși notează că tokenurile sunt mai puțin sigure decât mTLS.

Pentru proiectarea PKI între țări partenere, vezi managementul identităților în coaliție.

Instalarea Federation Hub și opțiunile de implementare

Hubul este distribuit pe tak.gov ca pachet propriu lângă TAK Server: takserver-fed-hub ca RPM (RHEL, Rocky) sau DEB (Ubuntu, Debian), plus un pachet Docker care împerechează o imagine de hub cu o imagine MongoDB separată. Necesită Java 17 și MongoDB, unde brokerul stochează evenimentele de federație și metadatele, și rulează cu sau fără un TAK Server colocat. Dați unui hub de teatru sau de coaliție un host dedicat: este o ancoră de încredere pentru fiecare partener și nu trebuie să împartă un domeniu de defecțiune sau o echipă de administrare cu vreun spoke.

1. PKI. Creați CA-ul hubului și certificatul de server cu aceleași scripturi și procedură ca pentru TAK Server (anexa B a ghidului de configurare); keystore-ul și truststore-ul se află sub /opt/tak/federation-hub/certs/files/.
2. Instalare. Instalați Java 17, pachetul hubului și MongoDB; setați datele de autentificare ale bazei în federation-hub-broker.yml și rulați scriptul de configurare a bazei hubului.
3. Pornire și autorizare. Porniți serviciul, autorizați un certificat de administrator și autentificați-vă cu el în interfață pe portul 9100 (comenzile mai jos).
4. Schimb de CA. Încărcați CA-ul de federație al fiecărui partener în interfața hubului și trimiteți fiecărui partener CA-ul hubului.
5. Desenați politica. Adăugați grupuri de CA (și federați individuali unde e nevoie), conectați-le cu muchii orientate, setați filtrul de grupuri al fiecărei muchii, decideți Interconnected pentru fiecare grup, apoi salvați și activați.
6. Conectați fiecare TAK Server. Activați federația v2, încărcați CA-ul hubului sub Federate Certificate Authorities, creați o conexiune de ieșire către hub pe 9102 cu protocolul v2, apoi setați grupurile de ieșire și de intrare ale federațului hubului.
7. Testați în ambele sensuri. Trimiteți o pistă de test cunoscută într-un grup care trebuie să treacă și una într-un grup care trebuie blocat (exemplele noastre adnotate de mesaje CoT sunt fixture-uri comode), apoi verificați că vizualizarea Active Connections a hubului arată versiunea de protocol și identitățile de grup așteptate.

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

Disponibilitatea și monitorizarea Federation Hub

Documentația publică a Federation Hub nu descrie un hub în cluster activ-activ, deci planificați o rezervă caldă care pornește repede, nu timp de nefuncționare zero:

• Salvați starea hubului: certificatele și keystore-urile, fișierele de politici, authorized_users.yml, directorul configs și baza MongoDB. Notele de upgrade ale hubului cer să salvați întâi fișierul de politici și utilizatorii autorizați.
• Țineți o rezervă cu certificate și politici identice în spatele unui nume DNS sau IP virtual mutabil. TAK Server-ele se reconectează singure, la intervalul de reconectare setat pe fiecare conexiune de ieșire.
• Faceți spoke-urile reziliente: o cădere a hubului oprește partajarea, nu operațiunile locale, deci cea mai mare parte a muncii de disponibilitate revine fiecărui server; vezi disponibilitatea ridicată și clusteringul TAK Server.
• Dimensionați pe baza măsurătorilor: nu există un sizing publicat separat pentru hub. Porniți de la baseline-ul TAK Server din ghid (4 nuclee, 8 GB RAM, 40 GB disc), apoi urmăriți heap-ul și ratele de mesaje la sarcină de exercițiu; pârghiile pe partea de server sunt în reglarea performanței TAK Server.

Monitorizați pe trei niveluri. În interfața hubului, tabloul de metrici arată conexiunile totale, citirile și scrierile pe secundă, octeții pe secundă, CPU și heap-ul, iar tabelul Active Connections enumără pentru fiecare federaț adresa distantă, versiunea de protocol și identitățile de grup. Pe hosturi, colectați /opt/tak/federation-hub/logs și urmăriți starea de federație a fiecărui TAK Server. Din exterior, testați 9102 și 9100, alertați la expirarea certificatelor — fiecare CA de federaț și fiecare certificat de server —, urmăriți deviația NTP și dați alarma când numărul de federați conectați scade sub cel așteptat.

Modele operaționale: huburi de teatru, de coaliție, de exercițiu și pe domenii

Hubul de teatru

Unitățile subordonate își rulează propriile TAK Server și se federează în sus, către un hub la cartierul general superior. Unitățile își păstrează imaginea locală când backhaul-ul cedează, hubul decide ce eșalon ce grupuri vede, iar spoke-urile care apelează ele se potrivesc serverelor avansate din spatele NAT sau al terminalelor prin satelit.

Hubul de coaliție

Fiecare națiune își păstrează propriul TAK Server, CA-ul și administratorii; un hub rulat de națiunea lider sau de o parte de încredere reciprocă poartă imaginea comună, iar muchiile orientate și listele de permisiuni codifică deciziile de difuzare. Grupurile de ieșire naționale rămân prima linie de control. Dacă coaliția folosește și formate NATO, un gateway la granița națională face traducerea; vezi puntea dintre CoT și standardele NATO și implementarea unui afiliat FMN.

Hubul de exercițiu

Un hub cu propriul CA de exercițiu, certificate de scurtă durată și o politică specifică scenariului lasă participanții să intre și să iasă fără să-și atingă serverele unii altora. După aceea eliminați un CA și retrageți politica; în timpul evenimentului, tabelul de conexiuni al hubului servește și ca tablou de prezență și stare.

Câte un hub pe domeniu de clasificare

Un hub filtrează după grupuri; nu este un guard. Nu inspectează conținutul față de regulile de difuzare și nu este acreditat să mute date între niveluri de clasificare. Rulați câte un hub separat pentru fiecare domeniu de securitate și conectați domeniile doar printr-o soluție cross-domain acreditată, un produs aparte cu propria acreditare; vezi arhitectura soluției cross-domain.

Huburile pot deschide și conexiuni de ieșire către alte huburi, deci un hub național se poate împerechea cu unul de coaliție. Țineți astfel de lanțuri scurte: fiecare salt adaugă latență și încă o politică care trebuie menținută consecventă.

Depanarea conexiunilor Federation Hub

• Handshake-ul TLS eșuează sau legătura se reconectează continuu. De obicei lanțul: spoke-ul trebuie să aibă încredere în CA-ul hubului (nu doar în certificatul lui de server), hubul trebuie să dețină CA-ul emitent al spoke-ului inclusiv intermediarele, nimeni nu trebuie să fi schimbat un certificat de client și nimic nu trebuie să fi expirat.
• Conectat, dar nimic nu circulă. Politica, nu rețeaua: este grupul de CA al spoke-ului în politica activă, există o muchie în direcția pe care o așteptați, serverul sursă a setat grupuri de ieșire pentru federațul hubului și destinația a setat grupuri de intrare?
• Unele grupuri circulă, altele nu. Numele grupurilor trebuie să coincidă exact, un mesaj fără grupuri trece doar de muchiile cu toate grupurile, iar conexiunile v1 nu poartă grupuri. Pe TAK Server-ul receptor, maparea grupurilor federate cade înapoi pe setările de grupuri ale federațului când nicio mapare nu se potrivește.
• Circulă prea mult. Căutați întâi un grup de CA Interconnected sau o muchie cu toate grupurile.
• Decalaj de ceas. Validarea certificatelor, precum și timpul și prospețimea CoT depind de ceas; rulați NTP dintr-o sursă comună pe hub și pe fiecare spoke.
• Firewall, NAT și proxy-uri. Hubul trebuie să accepte 9102/tcp (iar 9100/tcp doar din rețelele de administrare); firewall-urile cu stare cu timeout-uri scurte de inactivitate taie conexiunile liniștite; proxy-urile cu inspecție TLS rup TLS-ul mutual — scoateți calea de federație de sub inspecție sau folosiți autentificarea cu token.
• Nepotrivire de versiune. O conexiune de ieșire setată pe v2 dar îndreptată spre un port v1 — sau invers — nu urcă niciodată.
• Servere clonate. TAK Server scrie un ID de server aleatoriu în CoreConfig.xml la prima pornire și îl ștampilează ca etichetă de flux pe mesajele procesate, respingând orice poartă deja eticheta lui, ca să prevină buclele de rutare. Federații construiți dintr-un server clonat deja inițializat împart acel ID; dați-le câte unul propriu.

# 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

Federație directă vs. Federation Hub vs. un singur TAK Server partajat

Regula practică: pentru doi-trei parteneri stabili, federați-vă direct. Pentru patru sau mai multe servere, mai multe domenii administrative sau o listă de parteneri care se schimbă la fiecare exercițiu, folosiți un hub. Pentru o organizație cu o singură echipă de administrare, un singur TAK Server în cluster cu grupuri e mai simplu decât orice federație.

Lista de verificare pentru planificarea federației

1. Faceți inventarul fiecărui federaț: proprietar, versiunea TAK Server, accesibilitate și protocol (v2).
2. Alegeți topologia cu tabelul de mai sus; numiți operatorul hubului și cine îi aprobă configurația.
3. Proiectați PKI: un CA de federație pentru fiecare organizație, duratele de valabilitate, datele de reînnoire și o procedură de revocare; schimbați parolele implicite ale keystore-urilor.
4. Conveniți asupra unui catalog de grupuri între parteneri: nume exacte de grupuri, ce trimite fiecare server (ieșire) și ce acceptă (intrare).
5. Desenați graful de politici întâi pe hârtie: muchii orientate, tipul de filtru pe fiecare muchie și o decizie Interconnected explicită pentru fiecare grup de CA.
6. Decideți federația fișierelor și a misiunilor separat de CoT și țineți blocantul de fișiere pref activat.
7. Deschideți firewall-ul: 9102/tcp de intrare către hub, 9100/tcp doar din rețelele de administrare, pentru spoke-uri doar de ieșire; verificați timeout-urile de inactivitate NAT și inspecția TLS.
8. Sincronizați ora pe fiecare host.
9. Scrieți o matrice de testare cu un caz care trebuie să treacă și unul care trebuie blocat pentru fiecare muchie, și rerulați-o după fiecare schimbare de politică.
10. Configurați monitorizarea, copiile de rezervă și un failover repetat către hubul de rezervă.
11. Țineți un singur hub pe domeniu de securitate; tot ce traversează domeniile trece printr-o soluție cross-domain acreditată.