Votre nouveau NAS se connecte puis disparaît 20 secondes plus tard ? Ce guide pas‑à‑pas aide à isoler l’origine (réseau, DNS, DHCP, MTU, ACL, AD/Kerberos) et à appliquer des correctifs concrets, reproductibles et sûrs—même si l’ICMP est bloqué.
Problème de connexion intermittente à un NAS
Vue d’ensemble de la question
Un NAS fraîchement installé présente une connectivité aléatoire : l’accès fonctionne, puis échoue au bout d’une vingtaine de secondes, avant de redevenir disponible. Les éléments suivants ont été observés :
- Entrées DNS apparemment correctes.
- Restrictions ICMP : impossible de tester la passerelle/DNS par ping depuis le NAS.
- Droits Active Directory et partages configurés en « Full Access ».
Hypothèse de l’administrateur : la cause est probablement réseau (câblage, adressage, switching, sécurité, MTU) plutôt qu’un défaut de configuration du NAS lui‑même.
Réponse et pistes de solution
| Axe de diagnostic | Actions proposées | Pourquoi c’est pertinent |
|---|---|---|
| Stabilité du lien physique | Tester/échanger le câble, changer de port sur le switch, connecter le NAS directement au routeur. | Ports défectueux et faux‑contacts sont des causes physiques fréquentes d’interruptions courtes. |
| Adresses IP & DHCP | Vérifier qu’aucun autre équipement n’utilise la même IP ; envisager une IP statique hors plage DHCP. | Un conflit d’adresse provoque exactement ce type d’apparition/disparition sur le réseau. |
| Bande passante & latence | Surveiller trafic et gigue avec un analyseur (ex. iperf, Wireshark). | Une saturation éphémère ou une tempête de broadcast peut couper SMB/CIFS quelques secondes. |
| Pare‑feu / ACL | Valider que le pare‑feu du NAS et du réseau autorisent : 445 (SMB), 139, 137‑138 (NetBIOS), 389/636 (LDAP si joint à l’AD). | Des règles dynamiques ou un IDS peuvent bloquer après n tentatives. |
| Résolution de noms | Tester l’accès via l’IP directe plutôt que le FQDN ; purger le cache DNS des clients ; ajouter une entrée hosts temporaire. | Si l’IP fonctionne mais pas le nom, l’origine est DNS ou la recherche NetBIOS. |
| Firmwares & pilotes | Mettre à jour le microprogramme du NAS, du switch et du routeur. | Correctifs de stabilité ou de compatibilité protocolaire, surtout après ajout d’un nouvel appareil. |
| Journaux & métriques | Examiner les logs système du NAS ; activer la journalisation détaillée SMB. | Les codes d’erreur (ex. déconnexion réseau, timeout LDAP) orientent précisément le diagnostic. |
| Redémarrage contrôlé | Redémarrer routeur, switch, puis NAS (dans cet ordre). | Réinitialise tables ARP/MAC et libère d’éventuels états anormaux. |
| Négociation Ethernet & EEE | Forcer temporairement 1 Gb/s full‑duplex, désactiver EEE/Green Ethernet. | Une négociation instable ou l’économie d’énergie peut provoquer des coupures de quelques secondes. |
| VLAN, LACP & port‑security | Vérifier tag VLAN, cohérence LACP (802.3ad) ou supprimer l’agrégation ; ajuster port‑security. | Un LACP mal appairé ou un port‑security strict entraîne des flaps et blocages temporaires. |
| SPN & Kerberos | Contrôler les SPN CIFS du compte machine NAS, corriger les doublons, synchroniser l’heure. | Des SPN en doublon et un décalage horaire > 5 min font échouer l’authentification de façon intermittente. |
| MTU & Jumbo Frames | Uniformiser MTU (1500 ou 9000) entre NAS, cartes, switch(es) et routeur. | Un MTU incohérent induit des pertes par fragmentation ou des timeouts « aléatoires ». |
Informations complémentaires utiles
- Synchronisation horaire : NAS et contrôleurs de domaine doivent être à moins de 5 minutes de décalage, sinon Kerberos refusera l’authentification.
- Version SMB : forcer SMB 2/3 côté NAS si l’OS client/serveur ne gère plus SMB 1.
- MTU & Jumbo Frames : un MTU incohérent entre NAS, switch et cartes réseau peut entraîner une perte aléatoire de paquets.
- Tests prolongés :
ping -n 600 <IP_NAS> # Windows ping -c 600 <IP_NAS> # Linux/macOSpour observer les coupures en continu sans dépendre du DNS. - Analyse temps réel : un filtre Wireshark sur la MAC du NAS (
eth.addr == xx:xx:xx:xx:xx:xx) révèle les resets TCP ou refus ICMP. - Plan de reprise : documenter la configuration réseau/AD du NAS et sauvegarder la conf avant tout changement.
Procédure express en 15 minutes
- Isoler le lien : câble neuf, autre port de switch, pas de multiprise Ethernet ni d’injecteur suspect. Si possible, brancher le NAS directement sur le routeur/pare‑feu.
- IP unique : depuis un poste Windows, exécuter :
arp -a | findstr /i <IP_NAS> nbtstat -A <IP_NAS> Get-SmbConnectionSi la MAC change ou si plusieurs hôtes répondent, suspecter un conflit IP/nom. - Tester sans ICMP (ICMP bloqué) :
Test-NetConnection -ComputerName <IP_NAS> -Port 445 -InformationLevel Detailed Test-NetConnection -ComputerName <FQDN_NAS> -Port 445La stabilité du port 445 valide l’accessibilité SMB, indépendamment du ping. - DNS ciblé : tester FQDN et IP. Si IP OK mais FQDN KO, purger :
ipconfig /flushdns ipconfig /registerdnspuis vérifier la présence des enregistrementsAetPTRdans le DNS d’entreprise. - Vérifier l’horloge : s’assurer que NAS et contrôleurs de domaine pointent vers la même source NTP et qu’ils sont synchronisés.
Diagnostics sans ICMP : alternatives au ping
Quand l’ICMP est filtré, validez la connectivité et la résolution avec des tests applicatifs :
- Test TCP vers SMB (Windows) :
Test-NetConnection -Port 445 - Test DNS (Windows) :
nslookup <FQDN_NAS> <IP_DNS> Resolve-DnsName <FQDN_NAS> -Server <IP_DNS> -DnsOnly - Traçage sans ICMP :
tracert -d <IP_NAS>outraceroute -T -p 445 <IP_NAS>(Linux/macOS) pour tracer sur TCP/445. - SMB côté client (Windows) :
Get-SmbClientConfiguration Get-SmbSession Get-SmbShare -CimSession <FQDN_NAS>
Vérifications Active Directory, Kerberos et SPN CIFS
Un NAS joint à l’AD utilise Kerberos/NTLM pour authentifier les sessions SMB. Trois points causent souvent des déconnexions brèves après une première réussite :
- Décalage horaire : Kerberos tolère environ ±5 minutes. Corriger les sources NTP (contrôleur de domaine de référence et NAS).
- SPN en doublon : si l’entrée CIFS du NAS existe sur un autre objet AD (ancien serveur, autre nom), des tickets Kerberos invalides provoquent des erreurs sporadiques.
setspn -Q cifs/<FQDN_NAS> setspn -Q cifs/<NETBIOS_NAS>En cas de doublon, supprimer l’entrée fautive sur l’objet AD qui n’est pas le NAS. - Politique SMB/NTLM : si SMB 1 est désactivé (recommandé), forcer SMB 2/3 côté NAS : désactiver SMB1 et activer SMB3, signer/chiffrer selon la politique GPO.
Sur poste Windows, ajuster temporairement pour diagnostiquer :Set-SmbClientConfiguration -EnableSecuritySignature $true Set-SmbClientConfiguration -EnableMultiChannel $true
DNS, DHCP et conflits d’adressage
Un symptôme « connecté/déconnecté toutes les 10‑30 s » pointe souvent vers un conflit IP ou un enregistrement DNS ambigu.
- Conflit IP : vérifier la table ARP du poste quand la coupure survient. Si la MAC observée pour
<IP_NAS>change, deux hôtes utilisent la même IP. - IP statique hors DHCP : attribuer au NAS une adresse fixe en dehors de la plage du serveur DHCP, mais dans le même sous‑réseau, avec passerelle/DNS corrects.
- Enregistrements DNS :
- Supprimer les anciennes entrées
A/PTRportant le même nom. - Vérifier la présence d’un seul enregistrement
Apour le FQDN. - Si le NAS met à jour dynamiquement le DNS, vérifier que son compte machine a les droits d’écriture sur sa zone.
- Supprimer les anciennes entrées
- Cache et TTL : purger les caches côté clients et serveurs. Un TTL incohérent peut faire alterner deux résolutions pendant quelques dizaines de secondes.
SMB, ports et sécurité réseau
Assurez‑vous que les flux nécessaires ne sont pas bloqués de façon intermittente par des ACL ou une détection d’intrusion (IDS/IPS).
| Service | Ports | Direction | Remarques |
|---|---|---|---|
| SMB/CIFS | TCP 445 | Clients ⇄ NAS | Port principal pour SMB 2/3. |
| NetBIOS | TCP 139, UDP 137‑138 | Clients ⇄ NAS | Uniquement si découverte/compatibilité héritée requise. |
| LDAP/LDAPS | TCP 389/636 | NAS ⇄ DC | Requis si joint à l’AD. |
| DNS | UDP/TCP 53 | NAS ⇄ DNS | Résolution de noms et enregistrements dynamiques. |
| NTP | UDP 123 | NAS ⇄ NTP | Synchronisation horaire pour Kerberos. |
Astuce : si un pare‑feu applique des politiques adaptatives (ex. blocage après plusieurs échecs), vous verrez des sessions SMB acceptées puis coupées ~20 s plus tard. Examinez les journaux de l’équipement de sécurité aux mêmes horodatages que les erreurs clients.
MTU, Jumbo Frames et performances
Un MTU incohérent est un classique des « débits en dents de scie » et des déconnexions brèves.
- Principe : toutes les interfaces sur le chemin (NAS, cartes clients, switch(es), routeur) doivent partager le même MTU utile (1500 par défaut, ou 9000 pour Jumbo).
- Test MTU :
# Windows (ne fragmente pas) ping <IP_NAS> -f -l 1472 # 1472 + 28 octets d'entête IP/ICMP = 1500 # Linux/macOS ping -M do -s 1472 <IP_NAS>Ajuster par paliers jusqu’à trouver la plus grande taille non fragmentée. - SMB Multi‑Channel : si activé, désactiver temporairement pour vérifier qu’un chemin ne « tombe » pas (carte/NIC offload défaillant).
Ethernet, EEE, LACP, VLAN et Spanning‑Tree
- Autonégociation et EEE : forcer 1 Gb/s full‑duplex et désactiver EEE sur le port du switch. Des bascules d’énergie peuvent couper le lien ~10‑30 s.
- Aggregation (LACP) : si le NAS a deux ports agrégés, vérifier que le port‑channel est configuré des deux côtés. À défaut, ne garder qu’un seul lien actif.
- VLAN tagué : s’assurer que le VLAN de production est autorisé/tagué de façon identique côté NAS et côté switch.
- Port‑security : si limité à 1 MAC et que l’agrégation présente plusieurs MAC, le port peut se bloquer périodiquement.
- Spanning‑Tree : activer portfast sur les ports d’accès. Une convergence STP peut ressembler à des coupures de ~20 s.
Surveillance, iperf et Wireshark
Mesurez pour trancher entre congestion, perte et coupure logique.
- iperf3 : lancer un serveur iperf3 sur un poste du réseau et un client depuis un autre poste proche du NAS. Cherchez des chutes périodiques corrélées à vos coupures SMB.
- Wireshark (sur un poste client) :
- Filtre par MAC :
eth.addr == xx:xx:xx:xx:xx:xx - Filtre SMB :
tcp.port == 445 - Signes à repérer : TCP RST après SMB NEGOTIATE, retransmissions massives, fenêtre zéro, refus ICMP « Fragmentation Needed ».
- Filtre par MAC :
Journalisation côté NAS et corrélation
Activez la journalisation étendue : module SMB, jointure AD, NTP, DNS. Exportez les journaux et corrélez les horodatages avec ceux des pare‑feux/switches et des journaux Windows (Microsoft‑Windows‑SMBClient/Connectivity).
Cas concrets et correctifs ciblés
Conflit d’adresse IP
Symptômes : accès OK, puis perte ~20 s, puis retour. L’ARP du poste montre une MAC qui change.
Correctifs : fixer une IP statique hors DHCP, réserver l’IP dans le DHCP si nécessaire, supprimer les baux en doublon, nettoyer les DNS (A/PTR).
SPN CIFS en doublon / problème Kerberos
Symptômes : accès au partage qui disparaît juste après ouverture de session ou lors de la négociation, événements d’échec d’auth Kerberos/NTLM.
Correctifs : supprimer les doublons SPN (setspn -Q cifs/<FQDN_NAS>), vérifier que l’objet machine du NAS possède uniquement les SPN requis, resynchroniser l’heure (w32tm /resync sur DC).
Négociation Ethernet instable (EEE/Green Ethernet)
Symptômes : coupures très brèves à périodicité stable (économie d’énergie), logs indiquant des liens up/down.
Correctifs : désactiver EEE sur le port et/ou le NAS, forcer la vitesse/duplex, changer de câble et de port.
LACP incohérent
Symptômes : la MAC du NAS « flotte » entre deux ports, déconnexions après bascule.
Correctifs : configurer un port‑channel LACP sur le switch et l’activer sur le NAS, ou désactiver l’agrégation et conserver une seule interface active pendant le diagnostic.
MTU incohérent
Symptômes : transferts qui démarrent puis se figent, erreurs « réseau non disponible ».
Correctifs : uniformiser MTU, désactiver Jumbo pendant les tests, rechercher les messages « Fragmentation Needed ».
Pas‑à‑pas détaillé (checklist pratico‑pratique)
- Physique : câble Cat6/6a testé, autre port, pas d’adaptateur USB/Ethernet douteux. Noter l’état lien (LED, logs).
- Adressage : IP fixe du NAS, masque, passerelle, DNS d’entreprise (pas de DNS public). Réserver l’IP.
- Nom & DNS : un seul enregistrement
Apour le FQDN du NAS, unPTRcorrect, aucune homonymie avec un ancien serveur. - Temps : NAS ⇄ NTP, DC ⇄ NTP identique. Décalage < 5 min.
- AD : jointure réussie, SPN CIFS unique, utilisateur/ACL corrects.
- SMB : forcer SMB 3 si possible, désactiver SMB 1, vérifier signature/chiffrement selon politique.
- Pare‑feu : flux 445/389/636/53/123 autorisés et stables. Pas de règle « auto‑quarantaine ».
- Switch : EEE désactivé, portfast activé, VLAN/tag cohérents, pas de storm‑control trop agressif.
- MTU : identique partout. Désactiver Jumbo pendant le diagnostic.
- Logs : collecter et corréler (NAS, switch, pare‑feu, Windows).
Scripts et commandes utiles
Windows (PowerShell)
# Connectivité SMB sans ICMP
Test-NetConnection -ComputerName <FQDN_NAS> -Port 445 -InformationLevel Detailed
# Résolution de noms
Resolve-DnsName -DnsOnly
ipconfig /flushdns
# SMB côté client
Get-SmbClientConfiguration
Get-SmbSession
# Détection de MTU pratique
ping -f -l 1472
# Vérification SPN CIFS
setspn -Q cifs/
setspn -Q cifs/Linux/macOS
# Ping sans fragmentation
ping -M do -s 1472 <IP_NAS>
# DNS
dig @
# Traceroute TCP vers 445
traceroute -T -p 445 Modèle d’analyse cause racine
Utilisez la grille ci‑dessous pour qualifier rapidement un incident :
| Signal observé | Cause probable | Test décisif | Remède |
|---|---|---|---|
| Accès OK puis coupure ~20 s | Conflit IP / STP / EEE | ARP (MAC change), logs port up/down | IP unique, désactiver EEE, activer portfast |
| FQDN KO, IP OK | DNS (A/PTR multiples) | Resolve-DnsName vs. accès par IP | Nettoyage DNS, TTL normalisé |
| Ouverture de session qui saute | Kerberos/SPN | setspn, dérive d’heure | SPN unique, NTP commun |
| Transfert qui fige | MTU / Jumbo | Ping DF, ICMP « Fragmentation Needed » | Uniformiser MTU, désactiver Jumbo |
| Partages visibles puis inaccessibles | Pare‑feu/IDS adaptatif | Journaux sécurité à l’horodatage | Assouplir règle, liste blanche NAS/DC |
Méthode de corrélation temporelle
Pour objectiver un incident intermittent :
- Lancer ping prolongé (ou
Test-NetConnectionen boucle) depuis 2 postes différents. - En parallèle, capturer avec Wireshark sur un poste et activer les logs étendus sur le NAS.
- Noter l’heure d’une coupure, puis vérifier : a) reset TCP dans la capture ; b) port‑down dans les logs du switch ; c) alarme du pare‑feu ; d) évènement d’auth AD.
Bonnes pratiques de durcissement après résolution
- Réactiver les mécanismes désactivés pendant le diagnostic (Multi‑Channel SMB, EEE si nécessaire, règles IDS) en vérifiant l’absence de régression.
- Documenter le plan d’adressage, réserver l’IP du NAS, consigner les SPN configurés.
- Surveiller proactivement (SNMP, journaux centralisés, alerte sur down/up de port, variations de latence).
- Mettre en place un test synthétique quotidien (script PowerShell vers TCP 445 et résolution DNS) avec horodatage.
Conclusion
En attaquant d’abord les fondamentaux (câblage, IP unique, firmwares, pare‑feu) puis en affinant via les journaux et des tests applicatifs (TCP 445, DNS, Kerberos, MTU), on isole dans la grande majorité des cas la cause d’une connectivité intermittente entre postes Windows et un NAS joint à Active Directory. Les coupures « 20 secondes » sont typiques d’un conflit IP, d’une négociation Ethernet capricieuse (EEE), ou d’un mécanisme réseau (LACP/STP/pare‑feu) qui bascule ou met en quarantaine. Une fois stabilisé, durcissez progressivement sans perdre la visibilité opérationnelle grâce à une supervision simple mais continue.
Note opérationnelle : si l’ICMP est filtré, gardez comme « thermomètre » une boucle Test-NetConnection vers 445 et un enregistrement centralisé des journaux. La corrélation temporelle reste l’arme la plus efficace contre l’aléa apparent.