Fédération TAK Server : Connexion de plusieurs réseaux TAK entre unités et commandements

Un point de friction récurrent dans les opérations interarmées et de coalition est l'îlot TAK déconnecté : l'Unité Alpha dispose de son propre TAK Server fonctionnant en zone avancée, l'Unité Bravo dispose d'un serveur distinct deux échelons plus haut, et aucune ne peut voir les pistes de l'autre sur la carte. La fédération TAK Server est le protocole conçu pour résoudre ce problème — il relie deux ou plusieurs instances TAK Server indépendantes afin que les flux d'événements CoT circulent de manière bidirectionnelle à travers la frontière, offrant à chaque opérateur une image opérationnelle commune (COP) unifiée sans fusionner les serveurs séparés en un unique point de défaillance. Ce guide couvre l'intégralité du chemin de fédération : décisions architecturales, configuration de l'API REST CloudTAK, configuration XML du TAK Server hérité, filtres de groupes et de types CoT, sécurité TLS mutuelle et procédure de test systématique pour vérifier que les pistes se propagent correctement.

Qu'est-ce que la fédération TAK Server et pourquoi est-elle importante

La fédération est un protocole serveur à serveur fonctionnant sur le port TCP 9000 avec TLS mutuel. Lorsque deux serveurs TAK sont fédérés, chacun transmet les événements CoT sélectionnés à l'autre — offrant aux opérateurs sur les deux serveurs une image opérationnelle commune sans aucune modification de configuration côté client.

Déploiements multi-échelons — le serveur de compagnie avancée et le serveur de bataillon arrière partagent la connaissance situationnelle sans fusionner.
Opérations de coalition — des autorités administratives distinctes partagent des pistes sélectionnées à travers les frontières organisationnelles.
Résilience — la fédération se rétablit automatiquement lorsque la connectivité est restaurée après une panne de serveur.
Gestion de la bande passante — les filtres ne laissent passer que les types CoT opérationnellement pertinents sur les liaisons contraintes.

Architecture de fédération : pair-à-pair vs. hub-and-spoke

Le pair-à-pair crée O(n²) liaisons entre tous les serveurs. Le hub-and-spoke connecte tous les serveurs à un hub central, nécessitant une seule liaison par spoke. Le hub-and-spoke est généralement préféré pour trois serveurs ou plus — plus simple à configurer, plus facile à dépanner, au coût d'un saut de fédération supplémentaire.

Configuration de la fédération CloudTAK

Enregistrez une liaison de fédération via l'API REST, puis vérifiez l'état :

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
  }'

# Vérification
curl -s https://tak.yourdomain.com:8443/api/federation \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq '.[].status'

Vous pouvez également définir les liaisons de manière déclarative dans federation.json monté dans le conteneur à /app/config/federation.json.

Configuration de la fédération du TAK Server hérité

Activez le listener de fédération dans CoreConfig.xml avec v2Enabled="true" et useV2="true" sur le port 9000. Définissez les connexions peer sortantes dans federation-server.xml avec des éléments de filtre de groupe. Importez le certificat CA distant dans le truststore JKS de fédération avec keytool -import et redémarrez le service.

Filtrage : contrôle de ce qui franchit la frontière de fédération

Configurez les filtres de types CoT et les filtres de groupe sur chaque liaison de fédération. Commencez de manière restrictive — autorisez a-f- (ami), a-n- (neutre) et t-x-m-c (chat) par défaut ; bloquez b- (flux de capteurs) sauf si opérationnellement nécessaire. Appliquez des filtres de groupe pour contrôler les pistes des équipes qui franchissent la frontière.

Sécurité : TLS mutuel, épinglage de certificats et révocation

Base de sécurité : Chaque liaison de fédération opérationnelle doit utiliser le TLS mutuel. Ne déployez jamais la fédération avec des certificats auto-signés sauf si le chemin réseau est physiquement isolé.

CloudTAK active mTLS automatiquement lorsqu'un ca_cert est fourni. Le TAK Server hérité nécessite clientAuth="need" dans CoreConfig.xml. Épinglez le CA distant avec "ca_pin": "SHA256:<empreinte>" dans la définition du peer de fédération CloudTAK.

Test de la fédération

Injectez un événement CoT synthétique a-f-G-U-C dans le Serveur A et vérifiez que le callsign apparaît sur un client connecté au Serveur B dans les 2–3 secondes. Confirmez des valeurs non nulles pour events_forwarded et events_received via GET /api/federation.

Problèmes courants

« Connecting » indéfiniment : vérifiez le port 9000 avec openssl s_client -connect remote-server:9000.

Connecté mais aucune piste : un décalage d'horloge supérieur à 5 minutes provoque l'arrivée d'événements CoT obsolètes. Synchronisez NTP sur les deux serveurs.

Incompatibilité de version de protocole : assurez-vous que le TAK Server hérité 4.8+ utilise la Fédération v2.

Déconnexions NAT : définissez "keepalive_seconds": 60 dans la définition du peer de fédération CloudTAK.