Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Contrôler voyants, état du port et débit négocié. Un câble de longueur inhabituelle ou détérioré peut produire pertes, erreurs ou négociation dégradée. Comparer avec un câble court connu et un autre port, sans changer les deux en même temps. Une négociation à 100 Mbit/s sur des équipements gigabit peut orienter vers le câblage, mais ne prouve pas que le switch est défectueux.
Laisser l’autonégociation sauf besoin documenté et réglage cohérent aux deux extrémités. Forcer un seul côté peut créer un désaccord de duplex. Sur un switch administrable, relever erreurs CRC, abandons, changements de lien et événements STP. Une boucle Ethernet peut perturber tout le réseau : vérifier les liaisons redondantes avant d’accuser le fournisseur d’accès.
Vérifier ensuite adresse, route, résolution DNS puis port du service. Sous Windows, Test-NetConnection SERVEUR -Port 443 teste la connexion TCP ; cela ne valide pas le certificat ni le fonctionnement de l’application. Une réponse HTTP 403 indique généralement un service joignable qui refuse l’accès ; une expiration pointe vers une absence de réponse à analyser.
Comparer un accès local et un accès via le pare-feu. Relever la même heure sur client et serveur. Un test de débit sur un serveur public mélange réseau local, route opérateur et capacité du serveur distant ; pour tester le LAN, utiliser deux machines maîtrisées et un outil de mesure adapté.
Avec Wireshark ou l’outil de capture du pare-feu, choisir interface, hôte, protocole et durée limités. Lancer une seule tentative reproductible, arrêter la capture puis regarder requête et réponse. HTTPS masque normalement le contenu applicatif, mais les métadonnées restent utiles.
Une capture peut contenir identifiants non chiffrés, noms internes et données personnelles. La stocker dans un dossier protégé, limiter sa conservation et anonymiser avant tout partage. Obtenir l’autorisation pour un réseau de client ; ne pas capturer par curiosité le trafic des autres.
Compte rendu : topologie simplifiée, symptôme, période, mesures, changement unique, test après correction. Éviter de laisser des captures ou journaux détaillés actifs sans limite de taille.
| Étape | Contrôle | Si échec |
|---|---|---|
| Physique | Voyant, négociation, erreurs du port | Câble, prise, port, adaptateur |
| Ethernet/VLAN | MAC visible dans le bon VLAN | Appartenance, PVID, trunk et boucles |
| IPv4/IPv6 | Adresse et préfixe cohérents | DHCP, configuration fixe, annonces IPv6 |
| Routage | Passerelle et route vers la destination | Route manquante ou chevauchement VPN |
| DNS | Réponse du DNS explicitement interrogé | Zone, cache, filtrage, résolution interne |
| Transport | Port TCP cible / observation UDP | Pare-feu, NAT, service arrêté |
| TLS/application | Certificat, code HTTP, connexion métier | Proxy, certificat, backend, base ou authentification |
Sous Windows, ipconfig /all donne la configuration et le serveur DHCP. Resolve-DnsName wiki.example teste le nom ; ajouter -Server avec l’adresse du DNS attendu permet de comparer les réponses. Test-NetConnection wiki.example -Port 443 vérifie l’établissement TCP. Sous Linux, ip -br addr, ip route, getent hosts wiki.example et ss -lntup couvrent adresse, route, résolution système et ports locaux. Remplacer les noms d’exemple avant exécution.
Une adresse IPv4 automatique 169.254.x.x sur un poste prévu en DHCP suggère l’absence de bail utilisable. Ne pas lui donner une IP arbitraire avant d’avoir vérifié le VLAN et le serveur DHCP. Un câble négociant 100 Mb/s au lieu de 1 Gb/s peut avoir une paire défectueuse ; le forçage du duplex n’est pas une réparation universelle.
Définir source, destination, protocole et durée. Sur pfSense, choisir l’interface où le paquet est censé entrer, puis celle où il devrait sortir. Un paquet peut apparaître avec une autre adresse après NAT. Pour un test HTTP chiffré, la capture montre surtout transport et TLS ; elle ne révèle pas automatiquement le contenu applicatif.
Un filtre comme host 192.168.50.20 and port 443 limite une capture à un exemple de poste et de port. S’assurer que le filtre correspond à la question. Conserver les captures comme des données potentiellement sensibles et les supprimer selon la politique de conservation ; ne pas les joindre à un ticket public.
Le site marche en local mais pas en mobile : vérifier DNS public, IP publique réellement attribuée, CGNAT éventuel, redirection sur la box, règle WAN et serveur cible. Le site marche en mobile mais pas en local : examiner DNS interne et choix de split DNS avant d’activer de la réflexion NAT. Un VPN se connecte mais aucune application ne marche : vérifier AllowedIPs, routes retour, DNS et règles de l’interface VPN.
Débit lent : mesurer sur un transfert maîtrisé, dans les deux sens, et observer CPU, disque, erreurs de lien et congestion. Un test Internet ne mesure pas uniquement le LAN. Si le ping est bon au repos mais mauvais pendant un envoi, examiner saturation et files avant de modifier la puissance Wi-Fi.
Refaire exactement la requête initiale, relever les nouveaux résultats, puis tester un accès qui doit rester interdit. Retirer les règles temporaires et la journalisation trop bavarde. Écrire la cause confirmée, la modification et la preuve. Une panne intermittente nécessite un suivi ; un seul test réussi ne permet pas de conclure définitivement.