Ein wiederkehrender Reibungspunkt bei gemeinsamen und Koalitionsoperationen ist die isolierte TAK-Insel: Einheit Alpha betreibt ihren eigenen TAK Server im vorderen Bereich, Einheit Bravo betreibt einen separaten Server zwei Ebenen höher, und keine kann die Spuren der anderen auf der Karte sehen. TAK Server Federation ist das Protokoll, das dieses Problem löst — es verbindet zwei oder mehr unabhängige TAK Server-Instanzen, sodass CoT-Ereignisströme bidirektional über die Grenze fließen und jedem Operator ein einheitliches gemeinsames Lagebild (COP) bieten, ohne die getrennten Server zu einem einzelnen Ausfallpunkt zusammenzuführen. Dieser Leitfaden behandelt den vollständigen Federationspfad: Architekturentscheidungen, CloudTAK REST API-Konfiguration, ältere TAK Server XML-Konfiguration, Gruppen- und CoT-Typfilter, gegenseitige TLS-Sicherheit und ein systematisches Testverfahren zur Überprüfung der korrekten Spurenweiterleitung.
Was ist TAK Server Federation und warum ist sie wichtig
Federation ist ein Server-zu-Server-Protokoll, das über TCP-Port 9000 mit gegenseitigem TLS betrieben wird. Wenn zwei TAK-Server föderiert sind, stellt jeder eine ausgehende TCP/TLS-Verbindung zum Federationsport des anderen her und beginnt, ausgewählte CoT-Ereignisse seiner eigenen Clients weiterzuleiten. Das Ergebnis ist, dass ein Soldat mit ATAK, der mit Server A verbunden ist, nahezu in Echtzeit die Spuren von Einheiten sieht, deren ATAK-Clients mit Server B verbunden sind — und umgekehrt.
- Mehrstufige Deployments — Vorwärtskompanie-Server und rückwärtiger Bataillons-Server benötigen gemeinsames Lagebewusstsein, ohne dass der gesamte Kompaniedatenverkehr nach hinten fließt.
- Koalitionsoperationen — Partnerkräfte operieren auf separaten Servern; Federation teilt ausgewählte Spuren ohne vollständigen Administratorzugriff zu gewähren.
- Ausfallsicherheit durch Design — Wenn ein Server ausfällt, arbeitet der andere weiter, und Federation stellt sich automatisch wieder her, sobald die Verbindung zurückkehrt.
- Bandbreitenmanagement — Filter lassen nur operativ relevante CoT-Typen über die Grenze, was den Datenverkehr auf eingeschränkten Verbindungen reduziert.
Federationsarchitektur: Peer-to-Peer vs. Hub-and-Spoke
In einer Peer-to-Peer-Topologie unterhält jeder TAK-Server eine direkte Federationsverbindung zu jedem anderen Server — O(n²) Verbindungen. In einer Hub-and-Spoke-Topologie verbinden sich alle Server mit einem zentralen Hub; jeder Spoke benötigt nur eine Verbindung. Hub-and-Spoke wird bei drei oder mehr Servern in Betriebsumgebungen generell bevorzugt, da es die Konfigurationsoberfläche reduziert und die Fehlersuche vereinfacht.
CloudTAK Federation-Konfiguration
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
}'CloudTAK unterstützt auch eine federation.json-Datei für Infrastructure-as-Code-Deployments. Mounten Sie diese in den Container als ./federation.json:/app/config/federation.json:ro.
Ältere TAK Server Federation-Konfiguration
Älterer TAK Server konfiguriert Federation über CoreConfig.xml (Aktivierung des Federation-Listeners auf Port 9000 mit v2Enabled="true") und federation-server.xml (Definition ausgehender Peer-Verbindungen). Importieren Sie das Remote-CA in den Federation-JKS-Truststore mit keytool -import, bevor Sie den Dienst neu starten.
Filterung: Kontrolle dessen, was die Federationsgrenze überquert
| CoT-Typ-Präfix | Beschreibung | Typische Federationsverwendung |
|---|---|---|
a-f- |
Atom freundlich | Immer zulassen |
a-h- |
Atom feindlich | Nur zulassen, wenn Klassifizierung es erlaubt |
t-x-m-c |
Chat-Nachricht | Für einheitenübergreifenden Chat zulassen |
b- |
Bits (Sensor-Feeds) | Standardmäßig blockieren |
Sicherheit: gegenseitiges TLS, Zertifikat-Pinning und Sperrung
Sicherheitsgrundlage: Jede operationelle Federationsverbindung muss gegenseitiges TLS verwenden. Setzen Sie Federation niemals mit selbstsignierten Zertifikaten ein, es sei denn, der Netzwerkpfad ist physisch isoliert.
Bei CloudTAK ist mTLS standardmäßig aktiviert, wenn ein ca_cert angegeben wird. Beim älteren TAK Server setzen Sie clientAuth="need". Berechnen Sie den Remote-CA-Fingerprint für Pinning mit openssl x509 -in remote-ca.pem -noout -fingerprint -sha256.
Federation testen: CoT-Einspeisung und Latenz
Speisen Sie ein Test-a-f-G-U-C-CoT-Ereignis in Server A ein und bestätigen Sie, dass das Callsign auf einem mit Server B verbundenen ATAK-Client innerhalb von 2–3 Sekunden erscheint. Überprüfen Sie Federation-Zähler über GET /api/federation — suchen Sie nach nicht-null-Werten für events_forwarded und events_received.
Häufige Probleme
„Connecting" auf unbestimmte Zeit: Überprüfen Sie Port 9000 mit openssl s_client -connect remote-server:9000.
Verbunden, aber keine Spuren erscheinen: Überprüfen Sie die Zeitverschiebung — wenn die Server um mehr als 5 Minuten abweichen (date -u auf beiden Servern), werden CoT-Ereignisse als veraltet verworfen.
Protokollversion-Konflikt mit älterem TAK Server: Stellen Sie sicher, dass älterer TAK Server 4.8+ mit v2Enabled="true" verwendet wird.
NAT-Verbindungsabbrüche: Setzen Sie "keepalive_seconds": 60 in der CloudTAK Federation-Peer-Definition.