TAK Federation Hub: architectuur, setup en wanneer u het kiest in plaats van directe federatie

De TAK Federation Hub is een optionele broker die samen met TAK Server is uitgebracht. In plaats dat elke TAK Server rechtstreeks met elke andere federateert, opent elke server één federatieverbinding met de hub; de hub authenticeert de federates en stuurt data door volgens een door de beheerder gedefinieerde beleidsgraaf met groepsfilters per rand. Gebruik het zodra u meer dan drie servers of meerdere administratieve domeinen verbindt.

Deze pagina behandelt de architectuurbeslissing (hub versus directe server-naar-serverfederatie) en wat het draaien van een hub inhoudt: protocolversies en standaardpoorten, het beleidsmodel, PKI, uitrol, beheer en probleemoplossing. Voor één directe koppeling tussen twee servers gebruikt u onze handleiding voor het instellen van TAK Server-federatie.

• Wat het is: een hub-and-spoke-broker voor TAK Server-federatie (beleidsbeheerder, message-broker, beheerwebinterface).
• Standaardpoorten: 9102/tcp federatie v2, 9101/tcp federatie v1, 9100/tcp beheerinterface.
• Afhankelijkheden: Java 17 en MongoDB; geleverd als RPM, DEB en Docker-bundle.
• Rijpheid: de TAK Server Configuration Guide (versie 5.7, maart 2026) noemt de hub-installer nog steeds “beta”.

Waarom een Federation Hub: het N²-probleem van directe federatie

Directe federatie is een bilaterale afspraak, in software gegoten. Volgens de TAK Server Configuration Guide wisselen twee beheerders CA-certificaten uit, die elke server bewaart in een truststore voor federates, gescheiden van die voor lokale gebruikers, zodat de server van de partner kan verbinden, maar de ATAK-apparaten van de partner niet. Een van de twee servers legt de uitgaande verbinding, en beide kanten kiezen welke groepen hun server mogen verlaten en binnen mogen komen. Clients hoeven niet te worden aangepast.

Voor twee of drie servers is dat prima. Een volledig mesh van n servers vergt n(n−1)/2 koppelingen: 6 voor vier servers, 45 voor tien. Elke koppeling betekent een CA-uitwisseling, een firewallopening aan de luisterende kant en groepsinstellingen aan beide uiteinden, en elke beleidswijziging wordt per koppeling herhaald.

De Federation Hub vervangt de mesh door een ster. Elke TAK Server federateert één keer, met de hub, die verbindingen en vertrouwen beheert en elk bericht bemiddelt langs de randen van een beleidsgraaf, gefilterd op TAK-groep. Drie dingen veranderen:

• Vertrouwen: elke TAK Server importeert één externe CA, die van de hub, in plaats van één per partner. De partner-CA’s bewaart de hub.
• Bereikbaarheid: spokes bellen meestal zelf naar de hub uit, zodat forward servers achter NAT of eenzijdige firewalls geen inkomende openingen nodig hebben. Alleen de hub luistert.
• Beleid: wie wat ontvangt ligt in één graaf in plaats van tientallen instellingen per server, terwijl elke server zelf bepaalt wat zijn grens verlaat.

De kosten zijn net zo reëel: een extra brokersprong op elk bericht tussen servers, een nieuw waardevol systeem dat elke federatiesessie beëindigt en al het bemiddelde verkeer kan zien, en één storingspunt voor de uitwisseling tussen servers. Is de hub down, dan blijft het lokale beeld op elke server werken; alleen de uitwisseling stopt.

Federatieprotocolversies en standaardpoorten

TAK Server spreekt twee federatieprotocollen. Federatie v1 is het origineel: een langlevende TLS-socket met protobuf-gecodeerde federatiegebeurtenissen. Federatie v2 vervoert protobuf-berichten over gRPC (HTTP/2) met dezelfde mutual TLS, en het is de versie die in de voorbeeldconfiguratie van TAK Server is aangezet, terwijl v1 uitgeleverd wordt uitgeschakeld. Het protocol wordt per uitgaande verbinding gekozen, en de waarschuwing uit de guide geldt: kies de protocolversie die bij de poort hoort waarmee u verbindt. Voor de clientkant zie TAK-protocol: CoT XML versus protobuf.

Dit zijn standaardwaarden; controleer ze in uw eigen bestanden. De voorbeeldconfiguratie van 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>

En de brokerconfiguratie van de hub, /opt/tak/federation-hub/configs/federation-hub-broker.yml (uittreksel):

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

Praktische regel: standaardiseer alle verbindingen op v2, richt de uitgaande verbindingen van TAK Server op poort 9102 van de hub, en zet v1 op de hub uit tenzij een verouderde peer het nog nodig heeft. Ook groepsfiltering hangt ervan af: v1-verbindingen dragen geen TAK-groepsinformatie naar de hub, dus elke rand die op groep filtert, laat v1-verkeer vallen.

Hoe de Federation Hub verkeer routeert: beleidsgraaf en groepsfilters

De hub draait als samenwerkende Java-diensten onder één systeemdienst federation-hub: een beleidsbeheerder, een message-broker en een beheerwebinterface (recente pakketten voegen een plugin-manager toe). Routing komt uit een beleidsgraaf die u in de interface tekent. De knopen zijn:

• CA-groepen: elke federate waarvan het certificaat via een keten naar een geüpload CA teruggaat, valt onder de groep van dat CA. De meeste beleidsregels worden tegen CA-groepen geschreven, in de praktijk dus tegen organisaties.
• Federates: afzonderlijke TAK Servers, wanneer één server anders behandeld moet worden dan de rest van zijn organisatie.
• Uitgaande verbindingen: verbindingen die de hub zelf naar een TAK Server of een andere hub opent; zo bouwt u multi-hop hub-naar-hub-topologieën.
• Tokengroepen: federates die met tokens authenticeren in plaats van mutual TLS.

Randen zijn gericht. Een rand van A naar B laat het verkeer van A bij B aankomen, niet omgekeerd, dus tweerichtings delen vergt twee randen, en eenrichtingsfeeds (een partner die uw blue-force-beeld ontvangt maar niets terugstuurt) zijn een volwaardig patroon. Elke rand draagt een groepsfilter: alle groepen, toegestane groepen, geweigerde groepen, of toegestane en geweigerde. De groepen zijn de TAK Server-groepen die aan elk bericht hangen en die ATAK-gebruikers als kanalen zien. Een bericht passeert een rand met een toegestane-lijst als minstens één van zijn groepen erop staat, en valt door een rand met een weigerlijst als een van zijn groepen erop staat; een bericht zonder groepen passeert alleen een alle-groepen-rand.

CA-groepen hebben bovendien een vlag Interconnected: leden van een interconnected-groep wisselen onderling alles uit, zonder rand en zonder filtering. Dat is handig binnen één organisatie en gevaarlijk in een coalitie — controleer het bij elke groep die u toevoegt. De editor scheidt ook het opslaan van een beleid van het activeren ervan; een opgeslagen maar inactief beleid verandert niets.

Dataminimalisatie: drie filterfasen

1. Bron-TAK Server: de uitgaande groepen die voor de hub-federate zijn ingesteld, bepalen wat uw server überhaupt verlaat. In een coalitie is dit de enige fase die u volledig beheerst.
2. Hub-randen: bepalen welke bestemmingen welke groepen ontvangen.
3. Doel-TAK Server: inkomende groepen en de federated-group-mapping bepalen welke lokale gebruikers inkomend verkeer zien.

Bestanden hebben eigen regels nodig. De Data Package- en Mission File Blocker van TAK Server blokkeert gefedereerde bestanden op extensie (standaard pref, zodat configuratiebestanden geen partnerapparaten kunnen herconfigureren), en missie-federatie is een aparte beslissing naast CoT-deling; zie TAK-datapakketten en missiepakketten. De guide formuleert de grens ook letterlijk: elk domein beheerst wat het deelt, niet wat het andere domein ermee doet. Clients blijven hier buiten staan: ATAK, WinTAK en browserclients zoals CloudTAK blijven met hun eigen server praten.

Certificaatvertrouwensmodel: CA’s, federate-identiteiten en intrekking

Federatievertrouwen is op CA’s gebaseerde mutual TLS. In een hubtopologie:

• Elke TAK Server importeert het CA van de hub in zijn federate-truststore (de hub-interface kan zijn eigen CA downloaden) en toont zijn servercertificaat bij het verbinden.
• De hub importeert het CA van elke organisatie; het uploaden creëert de CA-groep waar het beleid naar verwijst.
• De identiteit van een federate is zijn certificaat, en zijn uitgiftesketen bepaalt zijn CA-groepen. Een server wiens keten een intermediate-CA bevat, kan in meerdere CA-groepen terechtkomen — dan moeten de randen van al die groepen het verkeer toestaan.

Vier ontwerpregels volgen daaruit:

• Gebruik een eigen federatie-CA per organisatie. De configuratieguide beschrijft deze alternatieve opzet — een apart CA en servercertificaat, uitsluitend voor federatie — zodat partners nooit het CA zien dat uw clientcertificaten ondertekent, en één CA van de hub verwijderen precies één organisatie afsluit.
• Plan intrekking voordat u het nodig hebt. Randen tegen een CA-groep gelden voor elke server van dat CA. Om één gecompromitteerde server af te sluiten zonder zijn organisatie te raken, geeft u hoog-risicopeers randen per federate, of leunt u op intrekkingscontrole (de hub-broker heeft een OCSP-optie, standaard uit). Geïsoleerde netten zonder OCSP-responder vallen terug op korte certificaatlooptijden en een gerepeteerde CA-verwijderingsprocedure.
• Bewaak de hub-sleutel als een CA-sleutel en wijzig de standaardwachtwoorden van de keystores (atakatak in de meegeleverde voorbeelden): wie de sleutel van de hub heeft, kan zich tegenover elke spoke als de hub voordoen.
• Beschouw tokenauthenticatie als uitzondering. TAK Server en de hub kunnen federatie met tokens authenticeren waar TLS-inspecterende proxies (“break and inspect”) mutual TLS onmogelijk maken; de guide zelf merkt op dat tokens minder veilig zijn dan mTLS.

Voor PKI-ontwerp over partnerlanden heen, zie identiteitsbeheer in een coalitie.

Federation Hub installeren en implementatieopties

De hub wordt op tak.gov gedistribueerd als eigen pakket naast TAK Server: takserver-fed-hub als RPM (RHEL, Rocky) of DEB (Ubuntu, Debian), plus een Docker-bundle die een hub-image koppelt aan een apart MongoDB-image. Hij vereist Java 17 en MongoDB, waar de broker federatiegebeurtenissen en metadata opslaat, en draait met of zonder een co-gelegen TAK Server. Geef een hub voor een operatiegebied of coalitie een eigen host: het is een vertrouwensanker voor elke partner en moet geen storingsdomein of beheerteam met een enkele spoke delen.

1. PKI. Maak het CA en het servercertificaat van de hub met dezelfde scripts en procedure als voor TAK Server (bijlage B van de configuratieguide); keystore en truststore staan onder /opt/tak/federation-hub/certs/files/.
2. Installatie. Installeer Java 17, het hub-pakket en MongoDB; zet de databasecredentials in federation-hub-broker.yml en draai het databaseconfiguratiescript van de hub.
3. Start en autoriseren. Start de dienst, autoriseer een beheercertificaat en log daarmee in op de interface op poort 9100 (opdrachten hieronder).
4. CA’s uitwisselen. Upload het federatie-CA van elke partner in de hub-interface en stuur elke partner het CA van de hub.
5. Teken het beleid. Voeg CA-groepen toe (en afzonderlijke federates waar nodig), verbind ze met gerichte randen, stel per rand het groepsfilter in, beslis over Interconnected per groep, en sla op en activeer daarna.
6. Verbind elke TAK Server. Zet federatie v2 aan, upload het hub-CA onder Federate Certificate Authorities, maak een uitgaande verbinding naar de hub op 9102 met protocol v2, en stel daarna de uitgaande en inkomende groepen van de hub-federate in.
7. Test beide richtingen. Stuur een bekend testspoor in een groep die moet doorkomen en één in een groep die geblokkeerd moet worden (onze van commentaar voorziene CoT-berichtvoorbeelden zijn handige testobjecten), en controleer daarna of de Active Connections-weergave van de hub de verwachte protocolversie en groepsidentiteiten toont.

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

Hoge beschikbaarheid en monitoring van de Federation Hub

De publieke Federation Hub-documentatie beschrijft geen actief-actief geclusteerde hub, plan dus een snel opstartende warme standby in plaats van nul downtime:

• Back-up de hub-toestand: certificaten en keystores, beleidsbestanden, authorized_users.yml, de map configs en de MongoDB-database. De upgrade-notities van de hub zeggen eerst het beleidsbestand en de geautoriseerde gebruikers te bewaren.
• Houd een standby met identieke certificaten en beleid achter een DNS-naam of virtueel IP dat u kunt verplaatsen. TAK Servers herverbinden zelf, met het herverbindingsinterval dat per uitgaande verbinding is ingesteld.
• Maak de spokes weerbaar: een hub-uitval stopt de deling, niet de lokale operaties, dus het meeste beschikbaarheidswerk zit in elke server; zie hoge beschikbaarheid en clustering van TAK Server.
• Dimensioneer op meting: er is geen aparte gepubliceerde hub-sizing. Vertrek van de TAK Server-baseline uit de guide (4 kernen, 8 GB RAM, 40 GB schijf) en volg daarna heap en berichtsnelheden onder oefenbelasting; de knoppen aan serverzijde staan in prestatieafstemming van TAK Server.

Monitor op drie niveaus. In de hub-interface toont het metricdashboard totaal verbindingen, lees- en schrijfbewerkingen per seconde, bytes per seconde, CPU en heap, en de Active Connections-tabel somt per federate het externe adres, de protocolversie en de groepsidentiteiten op. Op de hosts verzamelt u /opt/tak/federation-hub/logs en volgt u de federatiestatus van elke TAK Server. Van buiten test u 9102 en 9100, alarmeert u op aflopende certificaten — elk federate-CA en elk servercertificaat —, volgt u de NTP-afwijking en alarmeert u wanneer het aantal verbonden federates onder de verwachte telling zakt.

Operationele patronen: theater-, coalitie-, oefen- en domeinhubs

Theaterhub

Ondergeschikte eenheden draaien eigen TAK Servers en federeren omhoog naar een hub bij het hogere hoofdkwartier. Eenheden houden hun lokale beeld als de backhaul uitvalt, de hub bepaalt welk echelon welke groepen ziet, en uitbellende spokes passen bij forward servers achter NAT of satellietterminals.

Coalitiehub

Elk land houdt eigen TAK Server, CA en beheerders; een hub die door het leadland of een wederzijds vertrouwde partij wordt gedraaid, draagt het gedeelde beeld, en gerichte randen met toegestane-lijsten coderen releasedecisies. Nationale uitgaande groepen blijven de eerste controlelijn. Gebruikt de coalitie ook NATO-formaten, dan verzorgt een gateway op de nationale grens de vertaling; zie CoT en NATO-standaarden verbinden en een FMN-affiliate implementeren.

Oefenhub

Een hub met eigen oefen-CA, kortlopende certificaten en een scenariogebonden beleid laat deelnemers komen en gaan zonder elkaars servers aan te raken. Daarna verwijdert u één CA en haalt u het beleid weg; tijdens de gebeurtenis dient de verbindingstabel van de hub tegelijk als aanwezigheids- en statusbord.

Eén hub per classificatiedomein

Een hub filtert op groep; het is geen guard. Hij inspecteert inhoud niet tegen release-regels en is niet geaccrediteerd om data tussen classificatieniveaus te verplaatsen. Draai een aparte hub per beveiligingsdomein en verbind domeinen uitsluitend via een geaccrediteerde cross-domain-oplossing, een apart product met eigen accreditatie; zie guard-architectuur van een cross-domain-oplossing.

Hubs kunnen ook uitgaande verbindingen naar andere hubs openen, dus een nationale hub kan aan een coalitiehub gekoppeld worden. Houd zulke ketens kort: elke hop voegt vertraging en nog een beleid toe dat consistent moet blijven.

Problemen oplossen met Federation Hub-verbindingen

• De TLS-handshake mislukt of de koppeling blijft herverbinden. Meestal de keten: de spoke moet het CA van de hub vertrouwen (niet alleen zijn servercertificaat), de hub moet het uitgevende CA van de spoke inclusief intermediates vasthouden, niemand mag een clientcertificaat hebben omgewisseld, en er mag niets afgelopen zijn.
• Verbonden, maar er stroomt niets. Beleid, geen netwerk: staat de CA-groep van de spoke in het actieve beleid, bestaat er een rand in de richting die u verwacht, heeft de bronserver uitgaande groepen voor de hub-federate ingesteld, en heeft de bestemming inkomende groepen ingesteld?
• Sommige groepen stromen wel, andere niet. Groepsnamen moeten exact overeenkomen, een bericht zonder groepen passeert alleen alle-groepen-randen, en v1-verbindingen dragen geen groepen. Op de ontvangende TAK Server valt de federated-group-mapping terug op de groepsinstellingen van de federate als geen enkele mapping past.
• Er stroomt te veel. Zoek eerst naar een Interconnected-CA-groep of een alle-groepen-rand.
• Klokafwijking. Certificaatvalidatie én de tijd en versheid van CoT hangen aan de klok; draai NTP vanaf een gemeenschappelijke bron op de hub en elke spoke.
• Firewall, NAT en proxies. De hub moet 9102/tcp accepteren (en 9100/tcp alleen vanaf beheernetwerken); stateful firewalls met korte idle-timeouts laten stille verbindingen vallen; TLS-inspecterende proxies breken mutual TLS — haal het federatiepad uit de inspectie of gebruik tokenauthenticatie.
• Versieverschil. Een uitgaande verbinding op v2 die naar een v1-poort wijst — of omgekeerd — komt nooit op.
• Gekloonde servers. TAK Server schrijft bij de eerste start een willekeurig server-ID naar CoreConfig.xml en stempelt het als flow-tag op verwerkte berichten, en verwerpt alles wat al zijn eigen tag draagt, om routinglussen te voorkomen. Federates die van een gekloonde, al geïnitialiseerde server zijn gemaakt, delen dat ID; geef elk een eigen.

# 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

Directe federatie vs. Federation Hub vs. één gedeelde TAK Server

Vuistregel: federateer bij twee of drie vaste partners direct. Gebruik bij vier of meer servers, meerdere administratieve domeinen of een partnerlijst die elke oefening wisselt een hub. Voor één organisatie met één beheerteam is een enkele geclusteerde TAK Server met groepen eenvoudiger dan welke federatie ook.

Checklist voor federatieplanning

1. Leg van elke federate een inventaris vast: eigenaar, TAK Server-versie, bereikbaarheid en protocol (v2).
2. Kies de topologie met de tabel hierboven; benoem de hub-operator en wie de configuratie goedkeurt.
3. Ontwerp de PKI: een federatie-CA per organisatie, certificaatlooptijden, verloopdata en een intrekkingsprocedure; wijzig de standaardwachtwoorden van de keystores.
4. Spreek met partners een groepscatalogus af: exacte groepsnamen, wat elke server verzendt (uitgaand) en accepteert (inkomend).
5. Teken de beleidsgraaf eerst op papier: gerichte randen, filtertype per rand en een expliciet Interconnected-besluit per CA-groep.
6. Beslis over bestands- en missie-federatie apart van CoT en laat de pref-bestandsblokkering aan.
7. Open de firewall: 9102/tcp inkomend naar de hub, 9100/tcp alleen vanuit beheernetwerken, voor spokes uitsluitend uitgaand; controleer NAT-idle-timeouts en TLS-inspectie.
8. Synchroniseer de tijd op elke host.
9. Schrijf een testmatrix met één must-pass- en één must-block-geval per rand, en draai die na elke beleidswijziging opnieuw.
10. Regel monitoring, back-ups en een gerepeteerde failover naar de standby-hub.
11. Houd één hub per beveiligingsdomein; alles wat domeinen overschrijdt, gaat door een geaccrediteerde cross-domain-oplossing.