TAK Federation Hub: Architektur, Einrichtung und wann Sie ihn statt direkter Federation einsetzen

Der TAK Federation Hub ist ein optionaler Broker, der zusammen mit TAK Server veröffentlicht wird. Statt dass sich jeder TAK Server direkt mit jedem anderen föderiert, öffnet jeder Server genau eine Federationsverbindung zum Hub; der Hub authentisiert die Federates und leitet Daten nach einem vom Administrator definierten Policy-Graph mit Gruppenfiltern je Kante weiter. Setzen Sie ihn ein, sobald Sie mehr als drei Server oder mehrere administrative Domänen verbinden.

Diese Seite behandelt die Architekturentscheidung (Hub oder direkte Server-zu-Server-Federation) und was der Betrieb eines Hubs bedeutet: Protokollversionen und Standardports, das Richtlinienmodell, PKI, Deployment, Betrieb und Fehlerbehebung. Um eine einzelne direkte Verbindung zwischen zwei Servern zu konfigurieren, nutzen Sie unsere Anleitung zur Federation-Einrichtung von TAK Server.

• Was es ist: ein Hub-and-Spoke-Broker für die TAK-Server-Federation (Policy-Manager, Messaging-Broker, Admin-Weboberfläche).
• Standardports: 9102/tcp Federation v2, 9101/tcp Federation v1, 9100/tcp Admin-UI.
• Abhängigkeiten: Java 17 und MongoDB; als RPM, DEB und Docker-Bundle paketiert.
• Reifegrad: das TAK Server Configuration Guide (Version 5.7, März 2026) bezeichnet den Hub-Installer weiterhin als „beta“.

Warum ein Federation Hub: das N²-Problem direkter Federation

Die direkte Federation ist eine bilaterale Vereinbarung, in Software gegossen. Laut TAK Server Configuration Guide tauschen zwei Administratoren CA-Zertifikate aus, die jeder Server in einem vom Truststore der lokalen Nutzer getrennten Federate-Truststore hält, sodass sich der Server des Partners verbinden kann, die ATAK-Geräte des Partners aber nicht. Einer der beiden Server baut die ausgehende Verbindung auf, und beide Seiten wählen, welche Gruppen ihren Server verlassen und ihn erreichen dürfen. Clients brauchen keine Umkonfiguration.

Für zwei, drei Server ist das in Ordnung. Ein Full Mesh aus n Servern braucht n(n−1)/2 Verbindungen: 6 für vier Server, 45 für zehn. Jede Verbindung bedeutet einen CA-Austausch, eine Firewall-Freigabe auf der lauschenden Seite und Gruppeneinstellungen an beiden Enden, und jede Richtlinienänderung wird pro Verbindung wiederholt.

Der Federation Hub ersetzt das Mesh durch einen Stern. Jeder TAK Server föderiert genau einmal, mit dem Hub, der Verbindungen und Vertrauen verwaltet und jede Nachricht entlang der Kanten eines Policy-Graphen vermittelt, gefiltert nach TAK-Gruppen. Drei Dinge ändern sich:

• Vertrauen: jeder TAK Server importiert genau ein externes CA, das des Hubs, statt je eines pro Partner. Die Partner-CAs hält der Hub.
• Erreichbarkeit: Spokes wählen sich üblicherweise zum Hub aus, damit vordere Server hinter NAT oder Einweg-Firewalls keine eingehenden Freigaben brauchen. Nur der Hub lauscht.
• Richtlinie: wer was empfängt, liegt in einem Graphen statt in Dutzenden Einstellungen je Server, während jeder Server weiterhin steuert, was ihn verlässt.

Die Kosten sind ebenso real: ein zusätzlicher Broker-Hop auf jeder serverübergreifenden Nachricht, ein neues hochwertiges System, das jede Federation-Sitzung beendet und den gesamten vermittelten Verkehr sieht, und ein Single Point of Failure für den Austausch zwischen Servern. Ist der Hub down, arbeitet das lokale Lagebild jedes Servers weiter; nur der Austausch stoppt.

Federation-Protokollversionen und Standardports

TAK Server spricht zwei Federation-Protokolle. Federation v1 ist das Original: ein langlebiger TLS-Socket, der protobuf-kodierte Federation-Ereignisse transportiert. Federation v2 trägt protobuf-Nachrichten über gRPC (HTTP/2) mit demselben gegenseitigen TLS und ist die in der Beispielkonfiguration von TAK Server aktivierte Version, während v1 ausgeliefert deaktiviert ist. Das Protokoll wird je ausgehender Verbindung gewählt, und der Hinweis des Guides gilt: Wählen Sie die Protokollversion, die zum Port passt, mit dem Sie sich verbinden. Für die Client-Seite siehe TAK-Protokoll: CoT XML vs. protobuf.

Es sind Standardwerte; bestätigen Sie sie in Ihren eigenen Dateien. Die Beispielkonfiguration von 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>

Und die Broker-Konfiguration des Hubs, /opt/tak/federation-hub/configs/federation-hub-broker.yml (Auszug):

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

Praktische Regel: Standardisieren Sie alle Verbindungen auf v2, richten Sie die ausgehenden Verbindungen von TAK Server auf Port 9102 des Hubs und schalten Sie v1 am Hub ab, außer ein Alt-Peer braucht es noch. Die Gruppenfilterung hängt ebenfalls daran: v1-Verbindungen tragen keine TAK-Gruppeninformationen zum Hub, daher verwirft jede Kante mit Gruppenfilter v1-Verkehr.

Wie der Federation Hub Daten lenkt: Policy-Graph und Gruppenfilter

Der Hub läuft als kooperierende Java-Dienste unter einem Systemdienst federation-hub: ein Policy-Manager, ein Messaging-Broker und eine administrative Weboberfläche (neuere Pakete ergänzen einen Plugin-Manager). Das Routing stammt aus einem Policy-Graphen, den Sie in der UI zeichnen. Seine Knoten sind:

• CA-Gruppen: jeder Federate, dessen Zertifikat auf ein hochgeladenes CA zurückgeht, gehört zur Gruppe dieses CA. Die meisten Richtlinien werden gegen CA-Gruppen geschrieben, praktisch also gegen Organisationen.
• Federates: einzelne TAK Server, wenn ein Server anders behandelt werden soll als der Rest seiner Organisation.
• Ausgehende Verbindungen: Verbindungen, die der Hub selbst zu einem TAK Server oder einem anderen Hub öffnet – so entstehen mehrstufige Hub-zu-Hub-Topologien.
• Token-Gruppen: Federates, die sich mit Tokens statt mit gegenseitigem TLS authentifizieren.

Kanten sind gerichtet. Eine Kante von A nach B lässt den Verkehr von A B erreichen, nicht umgekehrt; bidirektionales Teilen braucht also zwei Kanten, und Einweg-Feeds (ein Partner empfängt Ihr Blue-Force-Lagebild, sendet aber nichts zurück) sind ein vollwertiges Muster. Jede Kante trägt einen Gruppenfilter: alle Gruppen, erlaubte Gruppen, verbotene Gruppen oder erlaubte und verbotene. Die Gruppen sind die an jeder Nachricht hängenden TAK-Server-Gruppen, die ATAK-Nutzer als Kanäle sehen. Eine Nachricht passiert eine Allow-Listen-Kante, wenn mindestens eine ihrer Gruppen gelistet ist, und scheitert an einer Deny-Listen-Kante, wenn eine ihrer Gruppen gelistet ist; eine Nachricht ohne Gruppen passiert nur eine Alle-Gruppen-Kante.

CA-Gruppen haben zudem ein Flag Interconnected: Mitglieder einer interconnected-Gruppe tauschen untereinander alles aus, ohne Kante und ohne Filter. Innerhalb einer Organisation ist das bequem, in einer Koalition gefährlich – prüfen Sie es bei jeder Gruppe, die Sie hinzufügen. Der Editor trennt außerdem das Speichern einer Richtlinie von ihrer Aktivierung; eine gespeicherte, aber inaktive Richtlinie ändert nichts.

Datenminimierung: drei Filterstufen

1. Quell-TAK-Server: die für den Hub-Federate gesetzten ausgehenden Gruppen entscheiden, was Ihren Server überhaupt verlässt. In einer Koalition ist das die einzige Stufe, die Sie vollständig kontrollieren.
2. Hub-Kanten: sie entscheiden, welche Ziele welche Gruppen erhalten.
3. Ziel-TAK-Server: eingehende Gruppen und das Federated-Group-Mapping entscheiden, welche lokalen Nutzer eingehenden Verkehr sehen.

Dateien brauchen eigene Regeln. Der Data-Package- und Mission-File-Blocker von TAK Server blockiert föderierte Dateien nach Erweiterung (pref standardmäßig, damit Konfigurationsdateien keine Partner-Geräte umkonfigurieren können), und die Missions-Federation ist eine eigene Entscheidung neben dem CoT-Austausch; siehe TAK-Datenpakete und Missionspakete. Der Guide benennt die Grenze auch klipp und klar: Jede Domäne kontrolliert, was sie teilt, nicht, was die andere Domäne damit macht. Von all dem unberührt bleiben die Clients: ATAK, WinTAK und Browser-Clients wie CloudTAK sprechen weiterhin mit ihrem eigenen Server.

Zertifikatsvertrauensmodell: CAs, Federate-Identitäten und Sperrung

Federationsvertrauen ist CA-basiertes gegenseitiges TLS. In einer Hub-Topologie:

• Jeder TAK Server importiert das CA des Hubs in seinen Federate-Truststore (die Hub-UI kann das eigene CA herunterladen) und legt beim Verbinden sein Serverzertifikat vor.
• Der Hub importiert das CA jeder Organisation; das Hochladen erzeugt die CA-Gruppe, auf die sich die Richtlinie bezieht.
• Die Identität eines Federates ist sein Zertifikat, und seine Ausstellungskette bestimmt seine CA-Gruppen. Ein Server, dessen Kette ein Intermediate-CA enthält, kann in mehreren CA-Gruppen landen – dann müssen die Kanten aller den Verkehr erlauben.

Daraus folgen vier Designregeln:

• Nutzen Sie ein dediziertes Federation-CA je Organisation. Das Configuration Guide beschreibt dieses alternative Setup – ein separates CA und Serverzertifikat, nur für die Federation –, damit Partner nie das CA sehen, das Ihre Client-Zertifikate signiert, und das Entfernen eines CA vom Hub exakt eine Organisation abschaltet.
• Planen Sie die Sperrung, bevor Sie sie brauchen. Kanten gegen eine CA-Gruppe gelten für jeden Server dieses CA. Um einen kompromittierten Server abzuschalten, ohne seine Organisation anzutasten, geben Sie risikoreichen Peers Kanten je Federate oder setzen auf Sperrprüfungen (der Hub-Broker hat eine OCSP-Option, standardmäßig aus). Abgeschottete Netze ohne OCSP-Responder verfallen auf kurze Zertifikatslaufzeiten und eine geübte CA-Entfernungs-Übung.
• Schützen Sie den Hub-Schlüssel wie einen CA-Schlüssel und ändern Sie die Standard-Passwörter der Keystores (atakatak in den mitgelieferten Beispielen): wer den Hub-Schlüssel hält, kann sich gegenüber jedem Spoke als der Hub ausgeben.
• Behandeln Sie Token-Authentifizierung als Ausnahme. TAK Server und der Hub können Federation mit Tokens authentifizieren, wo TLS-inspizierende Proxies („Break and Inspect“) gegenseitiges TLS verhindern; der Guide selbst merkt an, dass Tokens weniger sicher sind als mTLS.

Zum PKI-Design über Partnernationen hinweg siehe Identitätsmanagement in der Koalition.

Federation-Hub-Einrichtung und Deployment-Optionen

Der Hub wird auf tak.gov als eigenes Paket neben TAK Server vertrieben: takserver-fed-hub als RPM (RHEL, Rocky) oder DEB (Ubuntu, Debian), plus ein Docker-Bundle, das ein Hub-Image mit einem separaten MongoDB-Image paart. Er benötigt Java 17 und MongoDB, in dem der Broker Federation-Ereignisse und Metadaten speichert, und läuft mit oder ohne mitplatzierten TAK Server. Geben Sie einem Einsatz- oder Koalitions-Hub einen dedizierten Host: Er ist eine Vertrauensanker für jeden Partner und sollte weder eine Ausfalldomäne noch ein Admin-Team mit irgendeinem Spoke teilen.

1. PKI. Erzeugen Sie das Hub-CA und das Serverzertifikat mit denselben Skripten und demselben Verfahren wie für TAK Server (Anhang B des Configuration Guide); Keystore und Truststore liegen unter /opt/tak/federation-hub/certs/files/.
2. Installation. Installieren Sie Java 17, das Hub-Paket und MongoDB; setzen Sie die Datenbank-Zugangsdaten in federation-hub-broker.yml und führen Sie das Datenbank-Konfigurationsskript des Hubs aus.
3. Start und Autorisierung. Starten Sie den Dienst, autorisieren Sie ein Admin-Zertifikat und melden Sie sich damit in der UI auf Port 9100 an (Befehle unten).
4. CA-Austausch. Laden Sie das Federation-CA jedes Partners in der Hub-UI hoch und senden Sie jedem Partner das CA des Hubs.
5. Richtlinie zeichnen. Fügen Sie CA-Gruppen hinzu (und einzelne Federates, wo nötig), verbinden Sie sie mit gerichteten Kanten, setzen Sie den Gruppenfilter jeder Kante, entscheiden Sie Interconnected je Gruppe, dann speichern und aktivieren.
6. Jeden TAK Server anbinden. Aktivieren Sie Federation v2, laden Sie das Hub-CA unter Federate Certificate Authorities hoch, legen Sie eine ausgehende Verbindung zum Hub auf 9102 mit Protokoll v2 an und setzen Sie dann die ausgehenden und eingehenden Gruppen des Hub-Federates.
7. In beide Richtungen testen. Senden Sie einen bekannten Test-Track in einer Gruppe, die durchkommen soll, und einen in einer Gruppe, die blockiert werden soll (unsere kommentierten CoT-Nachrichtenbeispiele sind bequeme Prüflinge), und prüfen Sie dann, dass die Active-Connections-Ansicht des Hubs die erwartete Protokollversion und Gruppenidentitäten zeigt.

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

Hochverfügbarkeit und Monitoring des Federation Hub

Die öffentliche Federation-Hub-Dokumentation beschreibt keinen aktiv-aktiven, geclusterten Hub – planen Sie also einen schnell anspringenden Warm Standby statt Null Downtime:

• Sichern Sie den Hub-Zustand: Zertifikate und Keystores, Richtliniendateien, authorized_users.yml, das configs-Verzeichnis und die MongoDB-Datenbank. Die Upgrade-Hinweise des Hubs mahnen, zuerst Richtliniendatei und autorisierte Nutzer zu sichern.
• Halten Sie einen Standby mit identischen Zertifikaten und identischer Richtlinie hinter einem DNS-Namen oder einer virtuellen IP, die Sie umziehen können. TAK Server verbinden sich von selbst neu, im auf jeder ausgehenden Verbindung gesetzten Wiederverbindungsintervall.
• Machen Sie die Spokes widerstandsfähig: ein Hub-Ausfall stoppt das Teilen, nicht die lokalen Operationen – der Großteil der Verfügbarkeitsarbeit gehört in jeden Server; siehe Hochverfügbarkeit und Clustering von TAK Server.
• Dimensionieren Sie aus Messungen: ein separates, veröffentlichtes Hub-Sizing gibt es nicht. Starten Sie von der TAK-Server-Baseline des Guides (4 Kerne, 8 GB RAM, 40 GB Disk) und beobachten Sie dann Heap und Nachrichtenraten unter Übungslast; die serverseitigen Stellschrauben stehen in TAK Server Performance Tuning.

Überwachen Sie auf drei Ebenen. In der Hub-UI zeigt das Metrik-Dashboard Gesamtverbindungen, Lese- und Schreibvorgänge pro Sekunde, Bytes pro Sekunde, CPU und Heap, und die Active-Connections-Tabelle listet für jeden Federate Remote-Adresse, Protokollversion und Gruppenidentitäten. Auf den Hosts sammeln Sie /opt/tak/federation-hub/logs und beobachten den Federation-Status jedes TAK Server. Von außen sondieren Sie 9102 und 9100, alarmieren auf ablaufende Zertifikate – jedes Federate-CA und jedes Serverzertifikat –, verfolgen den NTP-Offset und alarmieren, wenn die Zahl der verbundenen Federates unter die erwartete Anzahl fällt.

Betriebsmuster: Einsatz-, Koalitions-, Übungs- und Domänen-Hubs

Einsatz-Hub

Nachgeordnete Einheiten betreiben eigene TAK Server und föderieren nach oben zu einem Hub im übergeordneten Hauptquartier. Die Einheiten behalten ihr lokales Lagebild, wenn das Backhaul ausfällt, der Hub entscheidet, welche Führungsebene welche Gruppen sieht, und auswählende Spokes passen zu vorderen Servern hinter NAT oder Satellitenterminals.

Koalitions-Hub

Jede Nation behält eigenen TAK Server, eigenes CA und eigene Administratoren; ein von der Leitnation oder einer beidseitig vertrauenswürdigen Partei betriebener Hub trägt das gemeinsame Lagebild, und gerichtete Kanten sowie Allow-Listen kodieren Freigabeentscheidungen. Nationale ausgehende Gruppen bleiben die erste Kontrolllinie. Nutzt die Koalition zusätzlich NATO-Formate, übernimmt ein Gateway an der nationalen Grenze die Übersetzung; siehe CoT und NATO-Standards verbinden und einen FMN-Affiliate einführen.

Übungs-Hub

Ein Hub mit eigenem Übungs-CA, kurzlebigen Zertifikaten und einer szenariospezifischen Richtlinie lässt Teilnehmer kommen und gehen, ohne einander Server anzufassen. Danach entfernen Sie ein CA und ziehen die Richtlinie zurück; während der Veranstaltung dient die Verbindungstabelle des Hubs zugleich als Anwesenheits- und Statusanzeige.

Ein Hub je Klassifizierungsdomäne

Ein Hub filtert nach Gruppen; er ist kein Guard. Er prüft Inhalte nicht gegen Freigaberegeln und ist nicht akkreditiert, Daten zwischen Klassifizierungsstufen zu bewegen. Betreiben Sie einen separaten Hub je Sicherheitsdomäne und verbinden Sie Domänen ausschließlich über eine akkreditierte Cross-Domain-Lösung, ein eigenständiges Produkt mit eigener Akkreditierung; siehe Cross-Domain-Lösung und Guard-Architektur.

Hubs können auch ausgehende Verbindungen zu anderen Hubs öffnen, sodass sich ein nationaler Hub mit einem Koalitions-Hub paaren kann. Halten Sie solche Ketten kurz: Jeder Hop fügt Latenz und eine weitere Richtlinie hinzu, die konsistent bleiben muss.

Fehlerbehebung bei Federation-Hub-Verbindungen

• Der TLS-Handshake scheitert oder die Verbindung verbindet sich ständig neu. Meist die Kette: der Spoke muss dem CA des Hubs vertrauen (nicht nur seinem Serverzertifikat), der Hub muss das ausstellende CA des Spokes inklusive Intermediates halten, niemand darf ein Client-Zertifikat getauscht haben, und nichts darf abgelaufen sein.
• Verbunden, aber nichts fließt. Richtlinie, nicht Netz: Steht die CA-Gruppe des Spokes in der aktiven Richtlinie, existiert eine Kante in der erwarteten Richtung, hat der Quellserver ausgehende Gruppen für den Hub-Federate gesetzt und das Ziel eingehende?
• Manche Gruppen fließen, andere nicht. Gruppennamen müssen exakt übereinstimmen, eine Nachricht ohne Gruppen passiert nur Alle-Gruppen-Kanten, und v1-Verbindungen tragen keine Gruppen. Auf dem empfangenden TAK Server fällt das Federated-Group-Mapping auf die Gruppeneinstellungen des Federates zurück, wenn kein Mapping passt.
• Zu viel fließt. Suchen Sie zuerst nach einer Interconnected-CA-Gruppe oder einer Alle-Gruppen-Kante.
• Uhrabweichung. Zertifikatsprüfung sowie Zeit und Stale-Werte von CoT hängen an der Uhr; betreiben Sie NTP aus einer gemeinsamen Quelle auf dem Hub und jedem Spoke.
• Firewall, NAT und Proxies. Der Hub muss 9102/tcp annehmen (und 9100/tcp nur aus Admin-Netzen); Stateful-Firewalls mit kurzen Idle-Timeouts werfen stille Verbindungen weg; TLS-inspizierende Proxies brechen gegenseitiges TLS – nehmen Sie den Federation-Pfad von der Inspektion aus oder nutzen Sie Token-Authentifizierung.
• Versionskonflikt. Eine ausgehende Verbindung, die auf v2 steht, aber auf einen v1-Port zeigt – oder umgekehrt –, kommt nie hoch.
• Geklonte Server. TAK Server schreibt beim ersten Start eine zufällige Server-ID in CoreConfig.xml und stempelt sie als Flow-Tag auf verarbeitete Nachrichten, verwirft alles, was bereits sein eigenes Tag trägt, um Routing-Schleifen zu verhindern. Federates von einem geklonten, bereits initialisierten Server teilen diese ID; geben Sie jedem eine eigene.

# 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

Direkte Federation vs. Federation Hub vs. ein gemeinsamer TAK Server

Faustregel: Für zwei, drei stabile Partner föderieren Sie direkt. Ab vier oder mehr Servern, mehreren administrativen Domänen oder einer Partnerliste, die sich mit jeder Übung ändert, nutzen Sie einen Hub. Für eine Organisation mit einem Admin-Team ist ein einzelner geclusterter TAK Server mit Gruppen einfacher als jede Federation.

Checkliste für die Federationsplanung

1. Nehmen Sie jeden Federate ins Inventar: Eigentümer, TAK-Server-Version, Erreichbarkeit und Protokoll (v2).
2. Wählen Sie die Topologie anhand der Tabelle oben; benennen Sie den Hub-Betreiber und wer seine Konfiguration freigibt.
3. Entwerfen Sie die PKI: ein Federation-CA je Organisation, Zertifikatslaufzeiten, Erneuerungsdaten und eine Sperrprozedur; ändern Sie die Standard-Keystore-Passwörter.
4. Verständigen Sie mit den Partnern einen Gruppenkatalog: exakte Gruppennamen, was jeder Server sendet (ausgehend) und annimmt (eingehend).
5. Zeichnen Sie den Policy-Graph zuerst auf Papier: gerichtete Kanten, Filtertyp je Kante und eine ausdrückliche Interconnected-Entscheidung für jede CA-Gruppe.
6. Entscheiden Sie Datei- und Missions-Federation getrennt vom CoT und lassen Sie den pref-Dateiblocker an.
7. Öffnen Sie die Firewall: 9102/tcp eingehend zum Hub, 9100/tcp nur aus Admin-Netzen, für Spokes nur ausgehend; prüfen Sie NAT-Idle-Timeouts und TLS-Inspektion.
8. Synchronisieren Sie die Zeit auf jedem Host.
9. Schreiben Sie eine Testmatrix mit einem Muss-Pass- und einem Muss-Block-Fall je Kante und wiederholen Sie sie nach jeder Richtlinienänderung.
10. Richten Sie Monitoring, Backups und eine geübte Standby-Hub-Übernahme ein.
11. Behalten Sie einen Hub je Sicherheitsdomäne; alles, was Domänen überschreitet, läuft über eine akkreditierte Cross-Domain-Lösung.