Audio sur IP en rénovation : sécuriser Dante (ports, cloisonnement, rôles, Domain Manager/Director, chiffrement des médias)

Illustration générée par IA — visuel conceptuel.

En rénovation, le risque classique est de mélanger audio temps réel, découverte, management et trafic bureautique sur un même LAN, puis de “résoudre” les problèmes en désactivant la sécurité (ACL / firewall) et en laissant passer tous les multicast. Résultat : un réseau instable, difficile à diagnostiquer, et une surface d’attaque inutilement large.

Objectif : proposer une démarche exploitable par un architecte, un bureau d’études et une équipe IT/AV pour sécuriser Dante sans dégrader la qualité audio — avec des exigences VLAN / firewall / recette utilisables en CCTP.

Important : ce guide reste strictement centré sur Dante (audio). Pour des problématiques vidéo AV-over-IP (bandes passantes très élevées, PIM, etc.), voir plutôt AV-over-IP : comment distribuer audio et vidéo sur un réseau professionnel ?

1) Le principe qui évite “ouvrir tout le multicast partout”

La méthode la plus fiable consiste à séparer les fonctions réseau Dante, puis à décider (et documenter) ce qui traverse ou non les frontières :

  • Découverte (mDNS / DNS-SD)
  • Horloge (PTP)
  • Contrôle & monitoring (Dante Controller, supervision)
  • Flux audio (unicast / multicast)
  • Management (Dante Domain Manager / Dante Director, si retenu)
  • Optionnel : AES67 / ST 2110-30 (si vous activez ces modes)

Ensuite, au lieu de “mettre Dante sur le réseau”, on conçoit un périmètre Dante : un VLAN (au minimum), des règles explicites, et une recette.

À ce stade, les deux décisions structurantes sont :

  • Voulez-vous que Dante reste local (L2) ? (le plus simple et souvent le plus robuste en rénovation)
  • Ou voulez-vous opérer Dante sur plusieurs sous-réseaux ? (ce qui impose une gouvernance + une recette plus exigeante)

2) Ports et protocoles Dante : la “surface réseau” à connaître

Audinate publie une FAQ consolidée des ports Dante (et DDM) : Which network ports does Dante use?. Cette liste est large (elle couvre plusieurs produits et options). En BE, l’objectif est de retenir le socle, puis de compléter selon les composants réellement utilisés.

2.1 Découverte : mDNS / DNS-SD

La découverte Dante s’appuie notamment sur mDNS (224.0.0.251:5353/UDP). C’est un point clé en segmentation : mDNS est conçu pour le link-local et ne traverse pas naturellement une frontière L3. Source : Dante Domain Manager – Information for Network Administrators (PDF).

2.2 Horloge : PTP

Dante utilise PTP et des ports dédiés (notamment UDP 319/320, sur des groupes multicast). Source : Information for Network Administrators (PDF).

2.3 Contrôle / monitoring

Audinate documente un trafic de contrôle/monitoring, comprenant des plages multicast et des ports unicast (à traiter comme partie intégrante du système). Référence : Dante Information for Network Administrators (PDF).

2.4 Audio : unicast et multicast

Les flux audio Dante utilisent des plages UDP documentées (unicast et multicast). Source : Information for Network Administrators (PDF).

3) Trois patterns de cloisonnement (rénovation)

Pattern A — VLAN Dante L2 (simple, robuste)

À choisir si : le système reste dans une même zone (étage, aile, plateau), et l’objectif est de limiter la surface d’exposition.

  • Créer un VLAN Dante dédié (même si l’infrastructure de switches est partagée).
  • Mettre tous les endpoints Dante en ports access dans ce VLAN.
  • Limiter les trunks aux liens nécessaires (et les documenter).
  • Éviter de rendre Dante accessible depuis des VLAN “utilisateurs” (PC bureautique, Wi‑Fi invités).

Cette logique de segmentation VLAN (pour éviter des transferts inutiles et stabiliser le réseau) est notamment documentée dans le guide Dante de Yamaha. Source : Yamaha – Dante Network Design Guide (VLAN).

Pour les principes généraux de segmentation (et surtout le rôle des règles inter-VLAN), voir : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?

Pattern B — Dante Domain Manager (DDM) : gouvernance + multi-sous-réseaux maîtrisés

À choisir si : vous devez opérer Dante sur plusieurs sous-réseaux (bâtiment multi-ailes, événements, extension progressive), et que vous voulez des droits et de l’audit.

DDM est conçu pour apporter une gouvernance (domaines, rôles) et une exploitation plus “entreprise”. Voir la présentation produit : Dante Domain Manager.

Point d’attention majeur (à intégrer au CCTP) : DDM documente une limite importante sur la redondance Dante entre subnets : la redondance est supportée dans un subnet, mais pas entre subnets. Source : DDM – Redundant Networks.

Pattern C — Dante Director (cloud) : monitoring/gouvernance “SaaS”

À choisir si : vous recherchez une approche cloud pour la visibilité, le contrôle et des fonctions de sécurité (selon offre), en acceptant les implications IT (accès Internet sortant, dépendance au service, gouvernance des comptes).

Audinate décrit Dante Director et ses fonctionnalités (Standard vs Pro) dans sa base support : What is Dante Director?

Et Audinate documente une logique de consolidation des ports côté Director (dont l’usage de TCP 443 pour Dante Controller vers Director, avec maintien d’UDP 8000 côté devices). Source : Consolidating ports…

4) Matrice “ports / protocoles” : exigences firewall/ACL (à adapter au projet)

Les tableaux ci-dessous sont une base de rédaction. Ils doivent être confirmés selon :

  • les produits utilisés (endpoints Dante, logiciels, options AES67, DDM/Director, etc.) ;
  • le design réseau (L2 vs L3, VLAN unique vs multi-VLAN) ;
  • les règles IT (filtrage inter-VLAN, inspection, proxy, etc.).

4.1 À l’intérieur du VLAN Dante (communications internes)

Fonction Flux (repères) Pourquoi c’est structurant
Découverte mDNS (224.0.0.251:5353/UDP) Indispensable à la découverte locale ; ne pas compter sur lui pour traverser du routage L3.
Horloge PTP (UDP 319/320 + multicast associés) La stabilité audio dépend de l’horloge ; QoS et design multicast sont déterminants.
Contrôle / monitoring Plages multicast + ports unicast documentés par Audinate Sans ces flux, Dante Controller voit mal (ou pas) l’écosystème, et le diagnostic devient fragile.
Audio Plages UDP unicast/multicast documentées Ce sont les flux médias ; à contenir dans le VLAN Dante par défaut (sauf design inter-VLAN explicite).

Référence technique (ports/flux) : Audinate – Information for Network Administrators (PDF) et Dante Information for Network Administrators (PDF).

4.2 Flux entre VLAN “Admin AV” et VLAN Dante

Bon réflexe : créer un VLAN Admin AV (ou un sous-réseau d’administration) qui contient les postes autorisés (et éventuellement un bastion/VPN), puis ouvrir uniquement ce qui est requis pour :

  • Dante Controller / outils de diagnostic,
  • accès DDM (si on-prem),
  • ou accès Director (cloud).

Cette approche réduit fortement le risque qu’un poste “bureautique” (ou un invité Wi‑Fi) manipule des abonnements audio.

4.3 Ports DDM (si DDM on-prem)

La page Audinate “Which network ports does Dante use?” liste les ports DDM (inbound/outbound) et doit servir de référence contractuelle pour construire la matrice de filtrage. Source : Audinate – Which network ports does Dante use?

Conseil BE : ce document liste un ensemble large de ports (selon features). Dans votre CCTP, vous pouvez exiger :

  • une liste de ports “minimum requis” basée sur l’architecture retenue ;
  • une liste de ports “optionnels” (haute dispo, base, etc.) “uniquement si le projet active la fonction”.

4.4 AES67 / ST 2110-30 : ne pas l’activer “par défaut”

Si vous activez AES67/ST 2110-30, vous introduisez des flux et contraintes supplémentaires (ports, multicast, horloge, interop). La note Audinate liste des ports typiques (SAP/SDP et RTP). Source : Information for Network Administrators (PDF).

Exigence recommandée : prototyper et recetter l’interop (et son impact sur la sécurité) avant généralisation.

5) IGMP : contenir le multicast au lieu de le supprimer

Un VLAN Dante “propre” ne signifie pas “pas de multicast”. Cela signifie :

  • IGMP snooping activé,
  • présence (et identification) d’un IGMP querier par VLAN,
  • et vérification que les flux multicast ne sont pas floodés inutilement.

Audinate documente ces points et rappelle que Dante implémente IGMP v2 ou v3 et qu’un querier doit exister par VLAN. Source : Dante Information for Network Administrators (PDF).

6) QoS : sécuriser sans “casser” l’audio (et éviter les faux diagnostics)

En rénovation, Dante est souvent déployé sur des switches existants ou hétérogènes. Deux erreurs fréquentes :

  • penser que l’audio “fonctionne comme du streaming” (alors qu’il est très sensible aux congestions) ;
  • penser que la QoS “répare” un réseau saturé (elle ne compense pas un goulot d’étranglement structurel).

Audinate publie des recommandations QoS, incluant un tableau DSCP typique (PTP, audio) et recommande une stratégie de file à strict priority queueing. Source : Dante Information for Network Administrators (PDF).

Audinate recommande également de désactiver EEE (Energy Efficient Ethernet) sur les ports Dante, car cela peut contribuer à des décrochages. Même source : PDF Audinate.

7) Gouvernance : qui a le droit de router l’audio ? (DDM / Director)

Sans gouvernance, toute machine capable d’exécuter Dante Controller et d’atteindre le segment Dante peut potentiellement modifier des abonnements. En environnement commercial (hôtel, retail, bureaux), c’est rarement acceptable.

7.1 DDM : rôles et permissions

Audinate documente des rôles (site + domaine) dans la documentation DDM. Exemple : DDM User Guide (PDF) et présentation webhelp : About user roles.

Exigence CCTP (à adapter) :

  • comptes nominaux (pas de comptes “partagés” sans traçabilité),
  • rôles “lecture seule” pour MOA/AMO si nécessaire,
  • rôles “opérateur” limités aux domaines concernés,
  • procédure de retrait d’accès (fin de chantier, fin de contrat, prestataire événementiel).

7.2 Director : différences Standard vs Pro

Audinate décrit les différences (dont logging) dans sa documentation support : What is Dante Director?

8) Chiffrement des médias : Dante Media Encryption

Le chiffrement ne remplace pas la segmentation réseau. Mais, dans certains environnements (confidentialité des micros, salles de réunion, captation/streaming, zones sensibles), il est pertinent de chiffrer les flux audio.

8.1 Ce que documente Audinate

Audinate présente Dante Media Encryption comme un chiffrement AES-256 des flux media. Source : Dante Media Encryption.

Le webhelp Dante Controller décrit le chiffrement (AES 256-bit), ainsi que la logique de politiques (Strict / Compatible) et certaines restrictions (notamment avec AES67 / ST 2110-30). Source : Dante Controller – Media Encryption.

8.2 Exigences BE : “Strict” vs “Compatible” (à écrire au cahier des charges)

  • Strict : le receiver doit supporter le chiffrement ; sinon la subscription échoue (comportement attendu et testable).
  • Compatible : tentative chiffrée, puis repli non chiffré si receiver legacy (transition plus douce en rénovation).

Recommandation de projet : décider par usage (par exemple “microphones / enregistrement” en Strict, “musique d’ambiance” en Compatible), puis recetter explicitement les cas d’échec et de repli, conformément à la documentation. Source : Media Encryption – webhelp.

9) Recette : vérifier la sécurité et la qualité audio (tests réalisables)

En rénovation, une recette n’est pas un “plus”. C’est ce qui évite de découvrir les effets secondaires (flood multicast, QoS incohérente, ports manquants) après mise en exploitation.

Test Procédure (simple) Résultat attendu Limites / pièges
Isolement bureautique → Dante Depuis un poste “utilisateur” (hors VLAN Admin AV), vérifier la visibilité des endpoints Dante. Pas de visibilité / pas de contrôle (hors besoins explicitement définis). Selon design, une visibilité partielle peut exister : elle doit être justifiée et documentée.
Admin AV → Dante Depuis un poste “Admin AV” autorisé, ouvrir Dante Controller, lister, router un flux de test. Accès fonctionnel, stable, sans ouvrir le reste du LAN. Éviter de conclure “réseau OK” sur un seul flux ; tester plusieurs scénarios.
IGMP querier Vérifier que le VLAN Dante a un querier (identifié) et que le snooping est cohérent. Multicast limité aux ports abonnés, pas de flooding inutile. Un multicast “qui marche” peut quand même flooder : vérifier tables/compteurs.
QoS et horloge Vérifier la cohérence QoS (PTP / audio) sur switches concernés. Pas de décrochage horloge/audio en charge raisonnable. La QoS ne compense pas une saturation : surveiller uplinks et erreurs physiques.
EEE (802.3az) Contrôler que l’EEE est désactivé sur ports Dante (si la plateforme le permet). Comportement stable. Ne pas modifier à l’aveugle : faire un point “standard config” par modèle de switch.
Chiffrement (si utilisé) Tester un receiver compatible et non compatible en Strict/Compatible (selon policy). Succès/échec/repli conformes à la documentation. Attention aux restrictions avec AES67/ST2110-30 : décider au design, pas “en prod”.

Références : IGMP/QoS/EEE (Audinate 2022) PDF Audinate, chiffrement (Audinate) webhelp.

10) Livrables BE (ce qui rend l’installation maintenable)

  • Schéma VLAN : VLAN Dante, VLAN Admin AV, VLAN IT, VLAN invités… (et responsabilités).
  • Matrice firewall/ACL : flux autorisés, ports, sens, justification, “qui parle à qui”.
  • Plan d’adressage (si L3 / multi-sous-réseaux) et nomenclature exploitable. Sur la méthode : Plan d’adressage IP & nomenclature : méthode orientée exploitation.
  • Politique d’exploitation : qui a le droit de router, qui change les policies, comment on retire un accès.
  • PV de recette : tests, résultats, limites, réserves levées.

Discret mais important : en rénovation, la réussite vient souvent moins d’un “bon produit” que d’une architecture documentée et d’une recette formelle.

Sources et documentation (primaires)

Besoin d’un cadrage BE (VLAN + firewall + recette) adapté à un site existant ? L’approche la plus efficace consiste à partir d’un schéma cible, puis à valider par un pilote sur une zone représentative avant généralisation.