Mon UDM Pro (Ubiquiti Dream Machine Pro) fait très bien son travail de routeur/pare-feu à la maison. C’est le modèle V1, et sur cette première génération, les huit ports intégrés ne font pas du tout de PoE — aucune alimentation sur les ports réseau, pour quoi que ce soit. Pour alimenter mes points d’accès et autres équipements réseau en PoE, il fallait donc forcément passer par un switch dédié en complément. Plutôt que de prendre un petit switch PoE grand public, j’ai préféré voir plus large et délester complètement l’UDM Pro de la partie switching — et pour ça, direction Leboncoin.
Avant ce projet, tout le réseau reposait sur l’écosystème UniFi d’Ubiquiti : l’UDM Pro pour le routage/pare-feu/DHCP/DNS/contrôleur Wi-Fi, et une ancienne passerelle USG Pro qui gérait encore une partie du DHCP en tâche de fond. Le problème classique du tout-en-un : quand une seule boîte fait tout, elle fait tout moyennement — DHCP en dnsmasq bridé, DNS interne peu configurable, pas de routage L3 avancé, et un unique point de défaillance pour l’ensemble du réseau.
Un lot de Catalyst 3750X pour 250 €
J’ai trouvé un vendeur qui se débarrassait d’un lot de trois Cisco Catalyst WS-C3750X-24P (24 ports cuivre 1 Gbps PoE+ chacun, avec un module d’extension C3KX-NM-10G apportant 4 ports SFP+ 10 Gbps, et un budget PoE+ de 435 W par switch), pour 250 € les trois — un excellent prix pour du matériel qui, neuf, valait plusieurs milliers d’euros à l’unité à sa sortie. C’est tout l’intérêt du matériel réseau d’entreprise d’occasion : une fois qu’une société renouvelle son parc, des switchs encore largement capables (gigabit, PoE, fonctions L3 avancées) se retrouvent sur le marché pour une fraction de leur prix neuf, alors qu’ils ont encore de belles années de service devant eux pour un usage personnel ou associatif.
Des trois, j’en ai gardé deux et donné le troisième à mon club de radio amateur, sur Angers — toujours utile pour un club qui gère son propre petit réseau, ses équipements de contrôle de répéteurs ou simplement besoin de ports PoE supplémentaires sans se ruiner.
StackWise : deux switchs, une seule unité logique
Les deux unités que j’ai gardées à la maison, je les ai stackées ensemble avec de vrais cordons StackWise — la technologie de stacking propriétaire de Cisco sur cette génération de Catalyst. Contrairement à un simple lien Ethernet entre deux switchs indépendants, StackWise relie les unités par une interconnexion dédiée à haut débit (32 Gbps par sens — la technologie supporte jusqu’à 9 switchs dans un même stack) qui fusionne les deux boîtiers en une seule unité logique : une seule adresse IP de management, une seule configuration IOS synchronisée automatiquement, un seul plan de contrôle à administrer, même si physiquement il y a toujours deux châssis empilés dans le rack. Un switch master est élu automatiquement parmi les deux ; s’il tombe, l’autre prend le relais en moins d’une seconde, et le stack se reconfigure seul au redémarrage.
Au total, le stack expose 48 ports cuivre PoE+ (24 + 24) et 8 ports SFP+ 10 Gbps (4 + 4), pour un budget PoE+ combiné de 870 W.
Et puisque j’étais sur l’alimentation électrique haute disponibilité, je suis allé jusqu’au bout : les deux switchs sont aussi reliés par un cordon StackPower, le pendant électrique de StackWise. Ce câble permet aux deux alimentations de mutualiser leur budget électrique à travers le stack — utile en particulier pour le PoE : si une unité a besoin de plus de courant que ce que fournit sa propre alimentation, l’autre membre du stack peut compenser la différence, au lieu de la limiter strictement à sa propre alimentation.
La licence IP Services : passer du simple switch au routeur
Les Catalyst de cette génération se vendent avec plusieurs niveaux de licence logicielle Cisco IOS, qui débloquent progressivement les fonctions L3 : LAN Base pour du switching pur, IP Base pour du routage statique et quelques fonctions de base, et IP Services au sommet, qui ouvre l’accès au routage inter-VLAN natif via des SVI (Switched Virtual Interface), aux protocoles de routage dynamique complets (OSPF, EIGRP, BGP), au Policy-Based Routing, à l’IPv6 complet et à la QoS avancée. J’ai activé cette licence IP Services sur le stack — de quoi transformer mes deux 3750X en bien plus qu’un simple commutateur PoE : un vrai routeur L3, sans avoir besoin d’un routeur dédié pour faire passer le trafic entre VLANs.
Concrètement, ça m’a permis d’aller plus loin dans le délestage de l’UDM Pro : le serveur DHCP tourne maintenant directement à l’intérieur du stack, via la fonction DHCP native d’IOS, plutôt que par le serveur DHCP intégré d’Ubiquiti. L’UDM Pro n’a donc plus qu’à faire du routage et du pare-feu pur, pendant que toute la distribution réseau — switching PoE, attribution des adresses IP, et potentiellement du routage inter-VLAN si besoin un jour — est gérée par le stack Catalyst lui-même.
Dernière mise à jour IOS possible, via TFTP
Avec la licence IP Services, le stack fonctionne bien en véritable commutateur Layer 3, pas seulement en switch PoE évolué. J’ai profité de la remise en service pour chercher la dernière version d’IOS encore supportée sur la plateforme 3750X — ces switchs étant en fin de vie chez Cisco, il faut faire attention à prendre l’image correcte, la dernière réellement validée pour ce matériel plutôt qu’une version plus récente destinée à d’autres familles de Catalyst. La mise à jour s’est faite en TFTP, à l’ancienne, et s’est bien déroulée — avec tout de même un bon 45 minutes pour flasher les deux switchs du stack l’un après l’autre.
Le 10 Gbps comme colonne vertébrale
Les ports SFP+ 10 Gbps du stack ne sont pas juste pour la forme. Deux liens structurants passent par là : l’UDM Pro vers le stack, pour que le trafic internet (et tout le routage inter-VLAN qui remonte vers lui) ne soit jamais limité par un lien 1 Gbps ; et le NAS vers le stack, qui profite ainsi du plein débit pour tous ses transferts, quel que soit le client — la seule limite devient alors le lien de ce client, jamais le NAS lui-même. Les ports SFP+ restants attendent une future extension : un serveur avec sa propre carte 10G, ou un switch annexe.
Et le DNS, avec Unbound sur une VM
Dernière brique du puzzle : le DNS. Plutôt que de laisser l’UDM Pro faire ce travail aussi, j’ai monté Unbound sur une VM dédiée — un résolveur DNS récursif et validant, qui répond lui-même aux requêtes DNS du réseau plutôt que de se contenter de relayer vers un résolveur tiers. Encore une fonction essentielle du réseau sortie de l’UDM Pro et confiée à un composant choisi et maîtrisé spécifiquement pour ce rôle.
Le résultat : tout désolidarisé de l’UDM Pro, presque
Switching et PoE sur le stack Catalyst, DHCP embarqué dans ce même stack grâce à la licence IP Services, DNS sur Unbound dans sa propre VM : à la fin, l’UDM Pro ne fait plus que deux choses — la passerelle internet, et le contrôleur Wi-Fi pour les points d’accès UniFi. Bénéfice immédiat : si l’UDM Pro tombe, tout le réseau local (NAS, serveurs, VMs, le stack lui-même) continue de fonctionner sans la moindre coupure. Seul l’accès à internet s’arrête.
Mais même réduit à ce rôle résiduel, l’UDM Pro reste un problème de fond pour moi : c’est une solution hybride-cloud, avec une dépendance structurelle aux serveurs Ubiquiti même pour un usage purement local — compte cloud requis pour certaines fonctions, télémétrie envoyée en continu, mises à jour imposées sans contrôle sur le calendrier, fonctions d’accès distant qui ne marchent qu’avec une connexion active vers Ubiquiti, pas d’accès root sur l’appareil, pas de configuration exportable ou versionnable, et un historique de fonctionnalités gratuites devenues payantes du jour au lendemain. Autrement dit : l’UDM Pro sait toujours où est mon réseau, quand il est actif, et quels appareils y sont connectés. Pour une infrastructure pensée pour durer, ce n’est pas acceptable à long terme.
La suite logique : faire disparaître l’UDM Pro complètement
L’objectif à moyen terme de tout ce projet, c’est de sortir l’UDM Pro du réseau pour de bon — pas d’un coup, mais par une sortie progressive où chaque étape du projet Catalyst le rend un peu moins indispensable. Il ne reste que deux rôles à lui retirer :
- La passerelle/pare-feu : remplacée par un OPNsense ou pfSense sur une VM Proxmox (ou un petit mini-PC dédié) — un pare-feu stateful complet, open source et auditable, sans télémétrie ni compte cloud, avec une configuration exportable et versionnable dans git, et des extensions comme un IDS/IPS Suricata ou un serveur VPN WireGuard directement intégrés.
- Le contrôleur Wi-Fi : soit en gardant les points d’accès UniFi mais avec leur contrôleur auto-hébergé localement sur Proxmox plutôt que lié au cloud Ubiquiti, soit en migrant vers des points d’accès compatibles OpenWRT pilotés par un contrôleur lui aussi open source.
Le Cisco, lui, est déjà prêt pour cette étape : le routage inter-VLAN, la QoS, les ACL de sécurité réseau et le LLDP/CDP pour la cartographie du réseau tournent déjà dessus. Une fois l’UDM Pro remplacé, l’architecture cible devient entièrement locale, entièrement open source : zéro cloud obligatoire, zéro télémétrie subie.
Le résultat, version longue
C’est un choix assez cohérent avec ma façon de voir l’auto-hébergement : je n’aime pas les solutions hybrides cloud, où une partie du fonctionnement de mon propre réseau local dépendrait, de près ou de loin, d’un compte ou d’un service tiers hébergé ailleurs. Avec DHCP et DNS désormais entièrement internes, et la sortie de l’UDM Pro programmée, le réseau continue — et continuera de plus en plus — de fonctionner intégralement sans dépendre d’un boîtier, ni de son fournisseur.