Plusieurs cartes réseau, mauvaise route : corriger le routage Windows sans réinstaller

Le modèle mental : comment Windows choisit réellement une route

Les décisions de routage de Windows semblent chaotiques tant que vous ne les traitez pas comme un système de score. Pour chaque destination, Windows choisit la « meilleure » route en se basant sur :

1. Correspondance la plus longue : un /32 bat un /24 qui bat un /0. Les routes spécifiques gagnent.
2. Métrique de la route : plus bas est préféré.
3. Métrique de l’interface : si plusieurs routes sont à égalité, la métrique d’interface peut départager.
4. Atteignabilité du next hop : si la passerelle n’est pas joignable, Windows peut passer à autre chose (parfois après des timeouts qui semblent durer une éternité).

Le problème multi-NIC le plus courant est ennuyeux : quelqu’un a mis une passerelle par défaut sur deux adaptateurs. Il y a maintenant deux routes 0.0.0.0/0, et Windows en choisit une selon les métriques. Si ces métriques sont automatiques, Windows peut changer d’avis après un changement de vitesse de lien, une mise à jour de pilote, la posture d’un VPN, ou un rayon cosmique retournant un bit dans l’interface utilisateur. (Bon, peut-être pas le rayon cosmique. Probablement.)

Il existe aussi un deuxième mode d’échec qui ressemble au routage mais qui est en réalité la résolution de noms : Windows choisit le « mauvais » serveur DNS pour une requête, reçoit une adresse interne, et ensuite le routage fait exactement ce que vous lui avez dit de faire. Vous dépannez la table de routage pendant deux heures pendant que le client DNS sabote tranquillement votre journée.

Ce que « multi-homed » devrait signifier dans une conception sensée

Un serveur Windows multi-homed est acceptable lorsque chaque NIC a un rôle clair :

• Une interface porte la passerelle par défaut pour le trafic sortant général.
• Les autres interfaces n’ont pas de passerelle par défaut et utilisent des routes statiques spécifiques (ou du routage dynamique si vous êtes ce type d’organisation).
• Le DNS est configuré délibérément, pas copié-collé sur tous les adaptateurs comme un rituel.
• Le trafic est validé par capture et tests applicatifs réels, pas par des impressions subjectives.

Si votre conception s’écarte de cela, vous pouvez toujours y arriver. Mais vous paierez « l’intérêt de la complexité » à chaque mardi de patch.

Une citation à garder près de vos runbooks : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan. Ce n’est pas une citation réseau, mais elle s’applique justement aux opérations.

Blague n°1 : Le routage Windows n’est pas hanté ; il fait juste exactement ce que vous avez configuré, et il vous juge pour ça.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est le flux « rentrer à moitié réveillé à 2 h du matin ». Vous n’êtes pas là pour admirer les paquets. Vous êtes là pour arrêter l’hémorragie.

Premier : confirmez le mauvais chemin, ne supputez pas

• Vérifiez la route active vers une destination réelle (votre DC, votre serveur de fichiers, votre point de supervision).
• Confirmez quelle interface est utilisée et quelle passerelle.
• Confirmez s’il s’agit de routage ou de DNS (le nom résout-il vers où ?).

Deuxième : trouvez les défauts concurrents et les métriques

• Cherchez plusieurs routes 0.0.0.0/0.
• Vérifiez les métriques d’interface et si elles sont automatiques.
• Vérifiez si un client VPN a injecté des routes ou modifié des métriques.

Troisième : appliquez la correction minimale sûre

• Retirez la passerelle par défaut des NIC non-défault.
• Définissez des métriques d’interface explicites (cessez de laisser « Automatique » prendre des décisions de politique).
• Ajoutez des routes persistantes pour les sous-réseaux spécifiques qui doivent passer par l’autre NIC.
• Retestez le chemin applicatif, pas seulement un ping.

Si vous réalisez ces trois étapes, la plupart des incidents « Windows a choisi la mauvaise NIC » se résolvent rapidement. Le reste relève du DNS, des WFP/politiques pare-feu ou de bizarreries de virtualisation, que nous aborderons.

Faits et contexte intéressants (pourquoi Windows se comporte ainsi)

• Fait 1 : Windows prend en charge les métriques d’interface automatiques depuis longtemps ; il corrèle souvent « lien plus rapide » avec « meilleure route », ce qui n’est pas toujours souhaitable pour le routage par politique.
• Fait 2 : L’« ordre de liaison » était important dans les anciennes piles réseau Windows ; aujourd’hui il compte moins pour le routage pur, mais il peut encore affecter certains comportements hérités et les préférences de résolution de nom.
• Fait 3 : Windows peut conserver plusieurs routes par défaut ; le vainqueur est celui avec la métrique combinée la plus basse, pas celui que vous aviez prévu.
• Fait 4 : Les clients VPN ajoutent fréquemment des routes et ajustent les métriques pour prioriser le tunnel. Certains le font poliment, d’autres comme s’ils payaient le loyer.
• Fait 5 : SMB Multichannel existe et peut utiliser plusieurs NIC simultanément lorsqu’il est configuré et que le réseau le supporte. C’est génial — jusqu’à ce que vous forciez accidentellement SMB sur la NIC de gestion avec un DNS inadapté.
• Fait 6 : La « détection de passerelle morte » peut amener Windows à basculer depuis une passerelle après des échecs, ce qui peut ressembler à un flapping de routes aléatoire quand un chemin est intermittemment brisé.
• Fait 7 : Hyper-V vSwitch et les adaptateurs vEthernet peuvent introduire des interfaces supplémentaires qui rivalisent pour les métriques et l’enregistrement DNS si on les laisse en valeurs par défaut.
• Fait 8 : Les guides iSCSI recommandent depuis longtemps de ne pas mettre de passerelle par défaut sur les NIC de stockage, avec des routes explicites si nécessaire. Les gens l’ignorent encore, généralement juste avant une panne.
• Fait 9 : En environnement Windows d’entreprise, la stratégie de groupe et les agents endpoint peuvent modifier le pare-feu et les paramètres réseau après que vous les ayez « corrigés » localement, donc la persistance implique de comprendre le plan de gestion.

Tâches pratiques : commandes, sorties et décisions (12+)

Chaque tâche ci‑dessous inclut : une commande, ce que signifie la sortie, et la décision à en tirer. Les commandes sont montrées depuis un shell. En pratique vous les exécuterez sous PowerShell ou CMD ; la sémantique est ce qui compte. Si vous faites cela à distance, prévoyez un accès hors bande.

Tâche 1 : Lister les interfaces et voir lesquelles sont actives

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name                  Status LinkSpeed MacAddress
----                  ------ --------- ----------
Ethernet0             Up     1 Gbps    00-15-5D-01-02-03
Ethernet1             Up     10 Gbps   3C-EC-EF-10-20-30
vEthernet (Default)   Up     10 Gbps   00-15-5D-AA-BB-CC

Sens : Vous avez au moins trois interfaces. La vitesse du lien peut influencer les métriques automatiques et vos hypothèses sur les chemins « préférés ».

Décision : Identifiez quelle NIC doit être la défaut (habituellement gestion), et lesquelles sont à usage spécifique (stockage, réplication, cluster).

Tâche 2 : Afficher la configuration IP incluant passerelles par défaut et DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,Ipv4Address,Ipv4DefaultGateway,DnsServer"
InterfaceAlias     : Ethernet0
Ipv4Address        : 10.20.30.40
Ipv4DefaultGateway : 10.20.30.1
DnsServer          : {10.20.30.10, 10.20.30.11}

InterfaceAlias     : Ethernet1
Ipv4Address        : 172.16.50.40
Ipv4DefaultGateway : 172.16.50.1
DnsServer          : {172.16.50.10}

Sens : Deux NIC ont des passerelles par défaut. C’est le générateur classique de « mauvaise route ».

Décision : Sauf si vous voulez volontairement un comportement de type ECMP (ce que vous ne voulez probablement pas), retirez la passerelle par défaut du NIC non‑défaut et remplacez‑la par des routes spécifiques.

Tâche 3 : Inspecter la table de routage pour des défauts concurrents

cr0x@server:~$ powershell -NoProfile -Command "route print -4"
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      172.16.50.1    172.16.50.40      5
        10.20.30.0    255.255.255.0         On-link     10.20.30.40    281
       172.16.50.0    255.255.255.0         On-link    172.16.50.40    281
===========================================================================

Sens : Windows préférera la route par défaut 172.16.50.1 parce que métrique 5 bat 25. Cela peut être votre VLAN de stockage, et non le VLAN internet/gestion.

Décision : Corrigez les métriques ou retirez la passerelle supplémentaire. Ne comptez pas sur l’espoir que Windows choisisse l’autre.

Tâche 4 : Demander à Windows quelle route il utiliserait pour une destination spécifique

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 8.8.8.8 | Format-Table -Auto"
ifIndex DestinationPrefix NextHop       RouteMetric InterfaceMetric
------ ----------------- ------       ----------- ---------------
    12 0.0.0.0/0         172.16.50.1              5              5

Sens : Pour cette destination, le next hop choisi est sur Ethernet1.

Décision : Si Ethernet1 n’est pas destiné au trafic sortant général, empêchez‑le de gagner (retirez la passerelle ou augmentez sa métrique).

Tâche 5 : Vérifier les métriques d’interface et si elles sont automatiques

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceMetric | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric,ConnectionState"
InterfaceAlias        InterfaceMetric AutomaticMetric ConnectionState
--------------        -------------- --------------- ---------------
Ethernet1                          5            True Connected
Ethernet0                         25            True Connected

Sens : AutomaticMetric est activé ; Windows a calculé ces métriques et a décidé que Ethernet1 est « meilleur ».

Décision : Désactivez les métriques automatiques et définissez des valeurs explicites qui reflètent l’intention (pas la vitesse du lien).

Tâche 6 : Définir des métriques d’interface explicites (la politique bat les suppositions)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Ethernet0' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Ethernet1' -AddressFamily IPv4 -AutomaticMetric Disabled -InterfaceMetric 50; Get-NetIPInterface -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,InterfaceMetric,AutomaticMetric"
InterfaceAlias InterfaceMetric AutomaticMetric
-------------- -------------- ---------------
Ethernet0                  10           False
Ethernet1                  50           False

Sens : Ethernet0 gagnera désormais en cas d’égalité. Cela ne supprime pas la seconde route par défaut, mais change la sélection si les métriques de route s’alignent.

Décision : Retirez quand même la passerelle par défaut supplémentaire à moins d’avoir un vrai design multi‑sortie et la maturité opérationnelle pour le supporter.

Tâche 7 : Supprimer la passerelle par défaut d’un NIC non‑défault

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -InterfaceAlias 'Ethernet1' -DestinationPrefix '0.0.0.0/0' | Remove-NetRoute -Confirm:\$false; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto"
ifIndex DestinationPrefix NextHop     RouteMetric PolicyStore
------ ----------------- ------     ----------- -----------
     8 0.0.0.0/0         10.20.30.1          25 ActiveStore

Sens : Une seule route par défaut reste. C’est ce que vous voulez 95 % du temps.

Décision : Si Ethernet1 doit encore atteindre des sous‑réseaux spécifiques, ajoutez ensuite des routes spécifiques.

Tâche 8 : Ajouter une route statique persistante pour un sous‑réseau spécifique via la NIC secondaire

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '172.16.60.0/24' -InterfaceAlias 'Ethernet1' -NextHop '172.16.50.1' -PolicyStore PersistentStore -RouteMetric 5; Get-NetRoute -DestinationPrefix '172.16.60.0/24' | Format-Table -Auto"
ifIndex DestinationPrefix  NextHop       RouteMetric PolicyStore
------ ------------------  ------       ----------- -----------
    12 172.16.60.0/24      172.16.50.1           5 PersistentStore

Sens : Le trafic vers 172.16.60.0/24 sortira par Ethernet1, indépendamment de la route par défaut.

Décision : C’est ainsi que vous gardez les chemins de stockage/réplication stricts sans perturber la passerelle par défaut globale.

Tâche 9 : Vérifier la sélection du serveur DNS par interface et empêcher l’enregistrement « utile »

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet0      {10.20.30.10, 10.20.30.11}
Ethernet1      {172.16.50.10}

Sens : Ethernet1 a du DNS configuré. Si cet espace de noms n’est pas destiné à la résolution générale, vous pouvez obtenir des problèmes de « mauvaise destination » qui ressemblent à du routage.

Décision : Habituellement : seul le NIC de gestion reçoit des serveurs DNS. Pour les réseaux isolés (iSCSI, sauvegarde), ne mettez pas de DNS et désactivez l’enregistrement DNS dynamique sur cet adaptateur.

Tâche 10 : Valider la résolution de noms et sa source

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName fileserver.corp.local | Select-Object -First 1 Name,IPAddress,Server | Format-List"
Name      : fileserver.corp.local
IPAddress : 172.16.60.25
Server    : 172.16.50.10

Sens : Le serveur DNS côté stockage a répondu et renvoyé une adresse dans la plage stockage/réplication. Maintenant SMB/RDP peut tenter d’utiliser ce réseau même si vous avez « corrigé » le routage.

Décision : Corrigez le DNS : retirez le DNS d’Ethernet1 ou fixez des règles DNS split‑horizon pour que les clients obtiennent l’adresse correcte selon leur rôle.

Tâche 11 : Prouver l’interface d’egress réelle avec un test (pas seulement ping)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection -ComputerName 10.20.30.10 -Port 445 -InformationLevel Detailed"
ComputerName           : 10.20.30.10
RemoteAddress          : 10.20.30.10
RemotePort             : 445
InterfaceAlias         : Ethernet0
SourceAddress          : 10.20.30.40
TcpTestSucceeded       : True

Sens : Pour SMB vers le point DC/fichier, le trafic sort via Ethernet0 avec la bonne IP source.

Décision : Si InterfaceAlias ou SourceAddress est incorrect, le routage et/ou le DNS ne sont pas encore alignés sur votre intention.

Tâche 12 : Vérifier l’injection de routes par le VPN (le concurrent silencieux)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,PolicyStore"
ifIndex InterfaceAlias          NextHop      RouteMetric PolicyStore
------ --------------          ------      ----------- -----------
    22 MyCorpVPN               0.0.0.0               1 ActiveStore
     8 Ethernet0               10.20.30.1           25 ActiveStore

Sens : Votre adaptateur VPN a inséré une route par défaut avec métrique 1. C’est intentionnel pour un VPN full‑tunnel ; désastreux si vous ne vouliez pas cela sur un serveur.

Décision : Décidez la politique : full‑tunnel ou split‑tunnel. Puis imposez‑la côté configuration client VPN, pas en éditant les routes à la main après chaque reconnexion.

Tâche 13 : Identifier les routes persistantes qui survivent au redémarrage (et vous surprennent plus tard)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -PolicyStore PersistentStore | Sort-Object DestinationPrefix | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop       InterfaceAlias RouteMetric
----------------- ------       -------------- -----------
172.16.60.0/24    172.16.50.1  Ethernet1                5

Sens : Des routes persistantes existent. Bon quand elles sont intentionnelles, terrible quand elles sont oubliées lors d’une migration.

Décision : Auditez les routes persistantes lors de changements de NIC, de VLAN ou de renumérotation IP. Traitez‑les comme de la configuration, pas comme du folklore.

Tâche 14 : Vérifier le forwarding IP (vous avez peut‑être accidentellement construit un routeur)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Select-Object -First 5 InterfaceAlias,Forwarding | Format-Table -Auto"
InterfaceAlias Forwarding
-------------- ----------
Ethernet0      Disabled
Ethernet1      Disabled

Sens : Le forwarding est désactivé, donc cet hôte ne route pas entre réseaux. C’est la posture habituelle d’un serveur.

Décision : Si Forwarding est activé de façon inattendue, comprenez pourquoi. Un routage accidentel entre VLANs peut créer des chemins asymétriques et des incidents de sécurité.

Tâche 15 : Confirmer que le maillon faible n’est pas le pare‑feu Windows ou une politique

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -Auto Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Sens : Inbound par défaut est bloqué, outbound autorisé. Si votre trafic échoue seulement sur une interface, la classification du profil et les types d’interface importent.

Décision : Si la NIC « erronée » est classée Public et que la politique la bloque, votre « problème de routage » est en réalité une question de politique. Corrigez la classification du réseau et les règles pare‑feu délibérément.

Règles de conception pour Windows multi-NIC durables

Règle 1 : Exactement une passerelle par défaut par domaine de routage

Si votre serveur Windows a deux passerelles par défaut, ce n’est pas de la « redondance ». C’est ambigu. Si vous avez besoin d’un vrai comportement multi‑sortie, faites‑le au niveau du routeur, du routage dynamique ou d’un design supporté. Windows n’est pas votre routeur d’edge. Il essayera, mais il ne sera pas poli à ce sujet.

Règle 2 : Traitez les métriques d’interface comme de la configuration, pas une suggestion

Les métriques automatiques conviennent aux portables et postes utilisateurs. Sur les serveurs, c’est une panne en attente lors de la prochaine mise à jour de pilote ou d’une renégociation de lien. Les métriques explicites apportent une stabilité peu coûteuse.

Règle 3 : Les NIC de stockage ne sont pas « juste une autre NIC »

iSCSI, SMB Direct (RDMA), réplication de sauvegarde, battements de cœur de cluster : ces flux veulent des chemins prévisibles et des IP source prévisibles. Cela implique :

• Pas de passerelle par défaut
• Pas de serveurs DNS (en général)
• Désactiver l’enregistrement DNS dynamique si cela cause de la confusion
• Routes statiques uniquement pour les sous‑réseaux qui appartiennent à ce fabric

Règle 4 : Le DNS fait partie du routage, que ça vous plaise ou non

Quand un nom résout vers une adresse sur « l’autre » réseau, Windows enverra volontiers le trafic là‑bas. Ensuite vous regardez la table de routage en vous demandant pourquoi la mauvaise NIC est utilisée, quand la vérité est : la destination elle‑même est inadaptée pour cette charge.

Règle 5 : Les adaptateurs virtuels méritent la même attention que les physiques

Les adaptateurs vEthernet Hyper‑V, le réseau des conteneurs et les adaptateurs VPN peuvent insérer des routes, des serveurs DNS et des métriques étranges. Ne les ignorez pas parce qu’« ils sont virtuels ». Les problèmes virtuels restent de vraies pannes.

Blague n°2 : Une seconde passerelle par défaut, c’est comme donner deux volants à votre serveur — techniquement possible, émotionnellement regrettable.

Trois mini-histoires d’entreprise depuis les tranchées du routage

Mini‑histoire 1 : L’incident causé par une fausse supposition

Un serveur de fichiers du département finance a reçu une seconde NIC pour un nouveau réseau de sauvegarde. L’ingénieur qui a fait le changement a supposé que « des passerelles sur les deux NIC signifient plus de résilience », parce que c’est comme leur mesh Wi‑Fi domestique. Ils ne cherchaient pas à être imprudents ; ils voulaient aider sous pression.

Ça a fonctionné pendant la fenêtre de maintenance. Les sauvegardes ont démarré. Tout le monde est rentré chez soi. Durant la nuit, l’amont du VLAN de sauvegarde a eu un souci intermittent de passerelle — de la perte de paquets brève, suffisante pour provoquer des retries, pas assez pour tomber complètement.

Le matin, l’accès SMB au serveur de fichiers était lent pour certains utilisateurs et correct pour d’autres. Le RDP était lent. La supervision affichait de la perte de paquets vers des destinations aléatoires. L’équipe a cherché du côté stockage, puis antivirus, puis « peut‑être le switch ». La table de routage avait deux défauts, et Windows préférait le VLAN de sauvegarde à cause des métriques automatiques. Chaque fois que la passerelle instable décrochait, Windows subissait des timeouts et finissait par basculer vers l’autre défaut… jusqu’à ce qu’il revienne.

La correction fut simple : retirer la passerelle par défaut de la NIC de sauvegarde, ajouter une route uniquement vers le sous‑réseau cible de sauvegarde, et définir des métriques d’interface explicites. Le post‑mortem fut moins simple : ils ont mis à jour le standard de build pour que « une seule passerelle par défaut » ne soit plus un savoir tribal mais une exigence auditable.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une équipe exploitant des hôtes Hyper‑V voulait accélérer la migration à chaud. Ils ont ajouté des NICs 25Gb dédiées et défini des métriques d’interface très basses pour « s’assurer que les migrations utilisent les tuyaux rapides ». Pris isolément, l’idée semblait raisonnable.

Ce qu’ils ont oublié : ces mêmes hôtes faisaient aussi l’authentification de domaine, les patchs et la coordination des sauvegardes, tous sur le réseau de gestion. Pendant une semaine chargée, un changement de switch a brièvement réduit la vitesse négociée d’un lien de gestion. Les métriques automatiques ont recalculé ; la NIC « migration rapide » a commencé à gagner plus de routes que prévu. Quelques services ont commencé à annoncer et contacter avec une IP source non voulue.

L’échec fut subtil. Les migrations étaient effectivement rapides. Mais la validation de cluster a commencé à alerter. Un outil de gestion perdait intermittente­ment le contact avec des hôtes. Un job de sauvegarde a commencé à se connecter sur une IP de migration qui n’était pas joignable depuis le segment backup. Ça ressemblait à de la flakiness aléatoire jusqu’à ce que quelqu’un corrèle les horaires avec des changements de route.

Ils ont annulé l’« optimisation », puis l’ont reconstruite correctement : pas de passerelle par défaut sur les NIC de migration, routes statiques nécessaires, et SMB Multichannel configuré explicitement pour que la migration puisse utiliser les bonnes interfaces sans détourner l’identité réseau du reste de l’hôte.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise de fabrication avait une checklist stricte de provisionnement serveur. Ce n’était pas glamour. Ça agaçait ceux qui aiment « juste livrer ». Elle incluait des métriques d’interface explicites, la règle d’une seule passerelle par défaut, et un petit ensemble de routes persistantes pour les réseaux de réplication. Elle incluait aussi un audit routinier : dumper les tables de routage mensuellement et comparer à une baseline.

Un mois, l’audit a signalé une route persistante supplémentaire vers 0.0.0.0/0 dans PersistentStore sur un contrôleur de domaine. Rien n’était encore cassé. C’est le meilleur moment pour trouver une panne.

Ils ont retracé cela à un test d’un client VPN réalisé par un prestataire lors d’un dépannage. Le prestataire a désinstallé le client, mais la route est restée. Le serveur aurait commencé à préférer cette route au prochain reconnect d’un adaptateur d’index similaire ou après un shuffle de métriques. Au lieu de cela, l’équipe a supprimé la route persistante obsolète et documenté la procédure du prestataire : pas de clients VPN sur les DC, jamais.

La checklist n’a pas empêché les erreurs. Elle a empêché les surprises. En exploitation, c’est la majeure partie du combat.

Erreurs courantes : symptôme → cause racine → correction

1) RDP fonctionne, mais il est lent et coupe parfois

Symptôme : RDP se connecte, mais les frappes sont en retard ; les sessions tombent lors d’oscillations réseau.

Cause racine : Deux routes par défaut ; Windows utilise parfois la « mauvaise » passerelle avec des pertes intermittentes.

Correction : Garder une seule passerelle par défaut. Retirer 0.0.0.0/0 du NIC secondaire, définir des métriques d’interface explicites et ajouter des routes spécifiques pour les sous‑réseaux distants nécessaires.

2) Le SMB vers un serveur de fichiers passe par la NIC de stockage

Symptôme : La copie de fichiers utilise une IP source inattendue ; les logs pare‑feu montrent du trafic bloqué depuis le VLAN de stockage.

Cause racine : Le DNS résout le nom du serveur de fichiers vers une adresse joignable via la NIC de stockage (ou SMB Multichannel choisit des interfaces non souhaitées).

Correction : Corriger l’attribution DNS ; rendre la NIC de gestion autoritaire pour la résolution de noms. Si vous utilisez SMB Multichannel, validez les rôles RSS/RDMA des NIC et assurez‑vous que les sous‑réseaux client/serveur correspondent aux chemins prévus.

3) L’accès Internet échoue après l’ajout d’une NIC de sauvegarde

Symptôme : Le serveur peut atteindre les sous‑réseaux internes mais pas les adresses externes.

Cause racine : La route par défaut a basculé vers un réseau sans NAT/egress ; la passerelle existe mais ne route pas vers Internet.

Correction : Assurez‑vous que la seule passerelle par défaut se trouve sur l’interface capable d’egress. Ajoutez des routes statiques pour les cibles de sauvegarde au lieu d’ajouter une passerelle.

4) « Ça marchait jusqu’au redémarrage »

Symptôme : Les corrections manuelles disparaissent après redémarrage.

Cause racine : Vous avez édité ActiveStore seulement ; les routes/métriques persistantes n’ont pas été définies, ou la gestion de configuration a écrasé.

Correction : Utilisez PersistentStore pour les routes statiques. Définissez les métriques d’interface explicitement. Vérifiez les stratégies de groupe, scripts et agents qui réappliquent des paramètres réseau.

5) Le trafic vers un sous‑réseau distant prend la mauvaise NIC même avec une seule passerelle

Symptôme : Seules certaines destinations posent problème.

Cause racine : Une route plus spécifique existe (persistante, injectée par VPN ou ajoutée par un logiciel).

Correction : Trouvez la route exacte utilisée avec Find-NetRoute, puis supprimez/ajustez la route spécifique concurrente ou donnez‑lui une métrique moins favorable.

6) Après activation de Hyper‑V, les routes et le DNS sont bizarres

Symptôme : De nouveaux adaptateurs vEthernet apparaissent ; la résolution de noms change ; la sélection de la route par défaut change.

Cause racine : Les adaptateurs vSwitch participent aux métriques/à l’enregistrement DNS ; parfois la NIC physique devient un uplink virtuel et les paramètres bougent.

Correction : Ré‑auditez les métriques et le DNS sur tous les adaptateurs après Hyper‑V. Désactivez l’enregistrement DNS là où c’est inapproprié. Assurez‑vous que le vNIC de gestion est celui qui porte la passerelle par défaut.

7) « La passerelle est joignable, mais les applis échouent »

Symptôme : Le ping fonctionne, mais SQL/HTTP/SMB timeout.

Cause racine : Routage asymétrique : les réponses sortent par une NIC/source IP différente de celle attendue par le client, ou le suivi d’état du pare‑feu les rejette.

Correction : Assurez‑une IP source cohérente en corrigeant la sélection de route et en évitant plusieurs sorties. Validez avec Test‑NetConnection et capture de paquets si nécessaire.

Listes de contrôle / plan étape par étape (faites ceci, n’improvisez pas)

Checklist A : Stabiliser un serveur multi‑NIC cassé en production

1. Identifiez l’interface par défaut prévue (gestion/egress). Notez‑la pour que l’équipe arrête de débattre.
2. Capturez l’état actuel : adaptateurs, IPs, passerelles, serveurs DNS, table de routage, routes persistantes.
3. Confirmez la route réelle vers les points clés : DC, supervision, cible de sauvegarde, cible de stockage, sonde internet.
4. Retirez les routes par défaut supplémentaires : gardez exactement un 0.0.0.0/0 (sauf si vous avez un design multi‑sortie formel).
5. Définissez des métriques d’interface explicites : désactivez AutomaticMetric sur les NIC serveurs ; choisissez des valeurs stables (ex. mgmt 10, storage 50, migration 60).
6. Corrigez l’affectation DNS : le NIC de gestion reçoit le DNS ; les NIC spécialisés en sont généralement privés. Évitez de mélanger les espaces de noms sans réflexion.
7. Ajoutez des routes persistantes spécifiques pour les sous‑réseaux distants qui doivent utiliser la NIC secondaire.
8. Validez avec des tests au niveau application (SMB port 445, SQL port 1433, contrôles santé HTTP). Le ping est nécessaire mais insuffisant.
9. Fenêtre de reboot (si possible) et re‑validation. Si vous ne pouvez pas redémarrer, au moins assurez‑vous que la configuration est persistante.
10. Documentez l’intention : quelle NIC sert quoi, et ce qui ne doit jamais être ajouté (comme une seconde passerelle par défaut).

Checklist B : Standard de construction pour nouveaux serveurs Windows multi‑NIC

1. Définir les rôles : gestion, stockage, sauvegarde, réplication, migration, DMZ, etc.
2. Une seule passerelle par défaut, sur la NIC de gestion/egress.
3. Métriques d’interface explicites ; AutomaticMetric désactivé.
4. DNS uniquement sur la NIC de gestion sauf si vous avez un design multi‑espace‑de‑noms délibéré.
5. Désactiver l’enregistrement DNS sur les NIC non‑gestion si cela crée de la confusion dans DNS intégré AD.
6. Routes statiques persistantes pour les réseaux spécialisés distants.
7. Contrôles de supervision qui vérifient l’IP source pour les flux critiques (détecter les mauvaises routes tôt).
8. Étape de gestion des changements : après ajout d’une NIC, ré‑auditer routes et DNS.

Checklist C : Quand vous avez vraiment besoin de plus d’un chemin d’egress

C’est là que les équipes deviennent créatives puis reçoivent des pages.

1. Décidez si l’hôte doit faire du routage multi‑sortie ; souvent il ne devrait pas.
2. Si oui, définissez explicitement les exigences de routage par politique (quelles destinations utilisent quel egress).
3. Implémentez avec des routes spécifiques (et possiblement du routage dynamique côté réseau), pas « deux passerelles par défaut et une prière ».
4. Testez le comportement de basculement sous perte, latence et pannes partielles.
5. Ayez un plan opérationnel : comment détecter la sélection de chemin, comment faire rollback, et comment prévenir la dérive.

FAQ

1) Pourquoi Windows choisit‑il la « mauvaise » NIC après l’ajout d’un second adaptateur ?

Parce que vous lui avez donné deux routes viables (souvent deux passerelles par défaut) et que les métriques rendent l’autre moins coûteuse. Les métriques automatiques peuvent changer avec la vitesse du lien et les pilotes.

2) Est‑il jamais acceptable de configurer deux passerelles par défaut sur un serveur Windows ?

Rarement, et seulement avec un design délibéré et testé. Si votre objectif est la résilience, faites‑le dans le réseau (protocoles de routage, passerelles redondantes), pas en donnant deux sorties à un serveur.

3) Si je retire la passerelle par défaut du NIC de stockage, comment atteindra‑t‑il quoi que ce soit ?

Il atteindra les sous‑réseaux on‑link directement, et tout le reste via des routes spécifiques que vous ajoutez (routes statiques persistantes). Les réseaux de stockage ne devraient généralement pas être à usage général.

4) Quelle est la différence entre métrique de route et métrique d’interface ?

La métrique de route est liée à une entrée de route spécifique. La métrique d’interface est associée à l’interface et peut influencer la préférence de route quand plusieurs routes existent. Plus bas gagne.

5) Pourquoi ma « correction » a‑t‑elle disparu après redémarrage ?

Vous avez probablement modifié uniquement ActiveStore ; ou un système de gestion a réappliqué des paramètres. Utilisez PersistentStore pour les routes et définissez les métriques d’interface explicitement.

6) Le DNS peut‑il vraiment faire croire que le routage est cassé ?

Absolument. Si un nom résout vers une IP sur le réseau secondaire, Windows y route correctement. La table de routage est innocente ; votre politique de résolution de noms ne l’est pas.

7) Qu’en est‑il de SMB Multichannel — il n’utilisera pas toutes les NIC de toute façon ?

Il peut le faire, si les deux extrémités le supportent et que c’est configuré. Mais cela n’excuse pas des passerelles et un DNS bâclés. Validez quelles interfaces SMB utilise et assurez‑vous que les sous‑réseaux et règles pare‑feu correspondent à l’intention.

8) Dois‑je désactiver AutomaticMetric partout ?

Sur les serveurs avec plusieurs NIC : oui, en général. Sur les portables : c’est acceptable. La différence est que les serveurs sont de l’infrastructure ; la prévisibilité vaut mieux que la commodité.

9) Hyper‑V a ajouté des adaptateurs vEthernet — doivent‑ils aussi avoir des métriques ?

Oui. Traitez‑les comme des interfaces de première classe. Assurez‑vous que seule l’interface de gestion porte la passerelle par défaut et le DNS, et que les métriques vNIC ne gagnent pas de façon inattendue.

10) Comment savoir quelle interface Windows utilisera avant de casser la prod ?

Utilisez les vérifications de sélection de route (ex. Find‑NetRoute) pour des destinations représentatives, puis testez avec Test‑NetConnection et validez SourceAddress/InterfaceAlias.

Conclusion : étapes suivantes qui tiennent dans le temps

Les problèmes Windows multi‑NIC ne nécessitent pas de réinstallation. Ils exigent d’admettre que le routage est de la politique, et que la politique doit être explicite.

Faites ceci ensuite :

1. Auditez la présence de passerelles par défaut multiples et retirez les excédents.
2. Désactivez les métriques d’interface automatiques et définissez‑les délibérément.
3. Déplacez les réseaux à usage spécial vers des routes persistantes spécifiques.
4. Corrigez le DNS pour que les noms résolvent vers le bon réseau selon le rôle.
5. Après tout changement de NIC/VLAN/VPN, relancez les vérifications de diagnostic rapides avant que les utilisateurs ne le fassent pour vous.

Si vous voulez une habitude opérationnelle qui rapporte toujours : capturez une table de routage et les métriques d’interface de référence pour chaque rôle de serveur. Quand le prochain incident « Windows a choisi la violence » surviendra, vous aurez un diff, pas un mystère.