Objectif
Déployer un VLAN de bout en bout en production en coordonnant commutation, routage/firewall, DHCP, DNS et Wi-Fi éventuel, avec un port pilote, une matrice de flux et un plan de retour arrière.
Prérequis
- Plan IP validé : VLAN ID, préfixe, passerelle, DHCP, DNS, réservations et convention de nommage.
- Schéma des trunks entre firewall, cœur, switchs d’accès, hyperviseurs et points d’accès.
- Matrice des flux inter-VLAN et Internet avec les services réellement nécessaires.
- Fenêtre de changement, port pilote et utilisateur ou équipement de test.
- Sauvegarde des configurations des équipements réseau concernés et accès hors bande lorsque possible.
Procédure pas à pas
Valider le plan et rechercher les chevauchements
Recherchez le VLAN ID sur les équipements et le préfixe dans les routes, VPN, scopes DHCP et documentation. Vérifiez aussi les plages statiques et les dépendances d’impression, supervision ou téléphonie. Le but est d’éviter une collision qui ne serait visible qu’au moment de la bascule. Identifiez également si le VLAN doit exister sur un seul site ou traverser plusieurs trunks.
- Le VLAN ID et le préfixe sont uniques dans le périmètre concerné.
- Les dépendances réseau sont listées avant création.
Créer la passerelle et les objets de sécurité
Créez l’interface L3 sur le firewall ou le routeur choisi, puis les objets réseau nécessaires aux policies. N’ouvrez pas immédiatement tous les flux. Préparez la configuration afin que le VLAN puisse être testé avec les règles minimales. Sur FortiGate, vérifiez que l’interface parent correspond au trunk réel et que le réseau connecté apparaît dans la table de routage.
- La route connectée du nouveau préfixe existe et aucune route plus spécifique inattendue ne la détourne.
Configurer DHCP ou relay
Créez le scope avec exclusions et options nécessaires, ou configurez le DHCP relay vers les serveurs existants. Si DHCP est centralisé, confirmez que les ACL/firewall autorisent correctement les échanges et que le serveur sait retourner le trafic vers le nouveau préfixe. Documentez les options DNS, suffixe, NTP ou VoIP spécifiques afin d’éviter une configuration implicite.
- Le scope ou relay est prêt sans distribuer d’adresses sur un mauvais VLAN.
Propager le VLAN sur les trunks nécessaires
Ajoutez le VLAN uniquement aux trunks qui doivent réellement le transporter. Vérifiez les trunks du cœur vers l’accès, les LAG/port-channels et les liens vers hyperviseurs ou AP. Ne changez pas la liste de VLANs autorisés avec une commande qui remplace involontairement les VLAN existants. Contrôlez le native VLAN/PVID avant et après.
- Le VLAN est transporté de la passerelle jusqu’au switch d’accès pilote sans modifier les autres VLAN.
Configurer un port ou SSID pilote
Attribuez un seul port access ou un SSID pilote au VLAN. Sur un port access, confirmez le PVID/native behavior du constructeur. Sur Wi-Fi, vérifiez le tagging entre AP et contrôleur. Le pilote doit permettre de tester le chemin complet sans déplacer immédiatement un service de production ni une population entière.
- Un équipement pilote peut rejoindre le nouveau VLAN sans modifier le reste du parc.
Valider l’adressage et les flux essentiels
Renouvelez le bail et contrôlez IP, masque, passerelle et DNS. Testez d’abord la passerelle, puis DNS, puis une ressource interne et Internet selon les règles. Cette progression localise rapidement le niveau de panne. Pour un service TCP, utilisez un test de port précis plutôt qu’un ping qui ne valide pas l’application.
ipconfig /allipconfig /releaseipconfig /renewping <GATEWAY-IP>Resolve-DnsName <NAME>Test-NetConnection <HOST> -Port <PORT>- Le poste pilote reçoit les bonnes options.
- Les services prévus fonctionnent depuis le VLAN pilote.
Tester les flux interdits et la segmentation
Une segmentation réussie se valide aussi par ce qui ne doit pas fonctionner. Testez un accès volontairement non autorisé vers un VLAN sensible ou un service administratif. Confirmez le deny dans les logs sans créer de règle permissive temporaire qui serait oubliée. Vérifiez aussi que le VLAN Guest ou IoT n’hérite pas accidentellement de droits d’un réseau interne.
- La matrice de flux est respectée dans les deux sens.
- Les refus attendus sont visibles dans les logs.
Migrer par lots et surveiller
Déplacez les ports, VM ou SSID par petits groupes. Contrôlez la consommation DHCP, les erreurs d’authentification et les applications qui utilisent encore des IP codées en dur. Après chaque lot, gardez une période d’observation avant de poursuivre. Les imprimantes, scanners et équipements anciens méritent souvent un lot spécifique.
- Chaque lot est validé avant le suivant et le rollback reste possible.
Finaliser la documentation et supprimer l’ancien chemin
Lorsque tous les équipements sont migrés, documentez les trunks, le scope, les règles et la passerelle. Ne supprimez l’ancien VLAN ou ancien scope qu’après vérification qu’aucun client, imprimante ou équipement hors supervision ne l’utilise encore. Conservez les métriques avant/après si le changement répond à un objectif de sécurité ou de performance.
- La configuration finale est documentée et l’ancien réseau n’est retiré qu’après confirmation d’inactivité.
Validation
La procédure est validée lorsque :
- Le VLAN est présent sur tous les trunks requis et absent des trunks inutiles.
- DHCP, DNS, passerelle et flux métier fonctionnent depuis le port pilote puis depuis les lots migrés.
- Les flux non autorisés sont effectivement bloqués.
- La documentation et le plan de rollback correspondent à la configuration réelle.
Retour arrière
- Replacer les ports ou SSID migrés dans l’ancien VLAN avant de retirer la nouvelle infrastructure.
- Restaurer les anciennes policies et scopes si le nouveau chemin ne peut pas être stabilisé dans la fenêtre.
- Retirer le nouveau VLAN des trunks dans l’ordre inverse du déploiement, puis supprimer la passerelle seulement lorsqu’aucun client ne l’utilise.
- Restaurer les sauvegardes des switchs ou du firewall si une erreur de trunk a affecté des VLAN préexistants.
Dépannage / erreurs fréquentes
- APIPA/169.254.x.x : vérifier d’abord couche 2, VLAN access/trunk et DHCP/relay.
- Bonne IP mais passerelle injoignable : contrôler tagging, interface L3 et éventuelle isolation ou port-security.
- Internet OK mais ressources internes KO : vérifier policies inter-VLAN, routes et DNS interne.
- Certains ports seulement échouent : comparer leur configuration access/PVID et le trunk du switch concerné.
- Une application échoue après migration malgré le réseau : rechercher une IP source autorisée en dur, une ACL applicative ou une dépendance DNS.