🔧 Support N2/N3 – Diagnostic & Dépannage Réseau

La gestion du support (Service Desk) est structurée (souvent selon le framework ITIL) en Niveaux (Tiers) pour organiser l'escalade et l'expertise.

L'objectif est de résoudre le ticket au niveau le plus bas (le plus rapide et le moins cher) possible.

Le Niveau 1 (N1) est le point de contact unique (SPOC) pour l'utilisateur. C'est le "visage" du support IT.

Responsabilités

• Enregistrement (Triage) : Créer le ticket (Outil ITSM), qualifier l'urgence et l'impact (Priorité).
• Diagnostic (Scripté) : Suivre des scripts (runbooks) ou une base de connaissances (FAQ).
  • Ex: "Mon imprimante ne marche pas" -> "Avez-vous redémarré ?", "Le câble est-il branché ?".
• Résolution (Incidents Connus) : Résoudre les problèmes simples et documentés (ex: "Reset mot de passe", "Installer Adobe Reader").
• Escalade (Escalation) : Si le problème n'est pas dans la FAQ ou n'est pas résolu en X minutes (SLA), le N1 escalade le ticket (avec les infos collectées) vers le N2.

Le Niveau 2 (N2) reçoit les tickets escaladés par le N1. Ce sont des techniciens avec une expertise plus approfondie (ex: Admin Système Junior, Technicien Réseau).

Responsabilités

• Diagnostic Avancé : Commence le "vrai" dépannage (voir Méthodologie OSI).
• Outils : Prise en main à distance (TeamViewer, RDP), Outils CLI (ipconfig, ping), Consoles d'admin (Active Directory, Console Switch).
• Résolution (Problèmes) : Gère les problèmes qui ne sont pas "scriptés" (ex: "Le PC de l'utilisateur ne reçoit pas d'IP du DHCP", "Le port du switch est down").
• Documentation : S'il résout un nouveau problème, il doit documenter la solution dans la Base de Connaissances (KB) pour que le N1 puisse le résoudre la prochaine fois ("Shift-Left").
• Escalade (N3) : Si le problème impacte l'infrastructure (ex: "Le serveur DHCP *entier* est down"), le N2 escalade au N3.

Le Niveau 3 (N3) est le dernier recours interne. Ce sont les experts (Ingénieurs, Architectes, Admins Séniors) qui ont conçu ou gèrent l'infrastructure.

Responsabilités

• Analyse de cause racine (RCA) : Gère les Problèmes (la *cause* sous-jacente) plutôt que les Incidents (les *symptômes*).
• Problèmes Inconnus : Résout les bugs non documentés, les pannes complexes d'infrastructure.
• Outils Avancés : Wireshark/tcpdump (Analyse de paquets), Logs (SIEM), Analyse de performance (SNMP, NetFlow).
• Changement (Change Management) : Implémente la solution permanente (ex: Patch, Reconfiguration du firewall, Migration de serveur).
• Escalade (N4) : Contacte le support constructeur (Cisco, Microsoft) s'il s'agit d'un bug produit.

ITSM (IT Service Management) est la gestion du support via un outil de Ticketing (Gestion des tickets). Le ticket est l'enregistrement central de l'incident.

Outils : GLPI, JIRA Service Desk, ServiceNow, EasyVista.

Cycle de Vie d'un Ticket (Simplifié)

Nouveau -> Assigné (N1) -> En Cours (Diag N1) -> Escaladé (N2) -> En Cours (Diag N2) -> En Attente (Feedback Client) -> Résolu -> Clôturé

Incident vs. Problème (ITIL)

C'est une distinction fondamentale pour le N2/N3.

• Incident : (N1/N2) Une interruption non planifiée. (ex: "L'imprimante est en panne").
  • Objectif : Résoudre (Workaround) le plus vite possible (ex: Redémarrer le spooler).
• Problème : (N2/N3) La cause racine (Root Cause) de plusieurs incidents. (ex: "Le driver de l'imprimante cause une fuite mémoire dans le spooler").
  • Objectif : Résoudre définitivement (ex: Tester et déployer un nouveau driver).

La méthode de diagnostic la plus fiable est de suivre (logiquement) les couches du modèle OSI pour isoler la panne. "La panne est-elle L1, L2, L3... ?"

L7 (Application)
   ↑
L4 (Transport)
   ↑
L3 (Réseau)
   ↑
L2 (Liaison)
   ↑
L1 (Physique)  <-- (On commence ici)

L7 (Application)  <-- (On commence ici)
   │
   ▼
L4 (Transport)
   │
...

La question : "Y a-t-il un signal électrique/lumineux ?"

C'est la première étape. Ne jamais faire confiance à l'utilisateur quand il dit "oui, c'est branché".

Checklist L1

• LEDs (Lumières) :
  • LED sur la NIC (PC) : Est-elle allumée (Link) ? Clignote-t-elle (Activité) ? (Orange = 100 Mbps, Vert = 1 Gbps ?)
  • LED sur le Port du Switch : Même vérification.
• Câble :
  • Vérifier le branchement (clic) des deux côtés (PC et prise murale).
  • (N2) Tester le câble (Prise murale -> Patch Panel -> Switch) avec un Testeur de Câble (vérifie les 8 paires).
  • Le câble est-il endommagé (écrasé) ?
• Matériel :
  • L'appareil est-il allumé ? (PC, Switch, Routeur).
  • (Wi-Fi) Le Wi-Fi est-il activé (bouton physique sur le laptop) ?

La question : "Le PC peut-il parler à la Passerelle (Routeur) sur le LAN ?" (Nécessite accès au Switch).

Checklist L2 (Switch Manageable)

• Table MAC (show mac address-table) :
  • Le switch "voit-il" (apprend-il) l'adresse MAC du PC sur le bon port ?
  • Le switch "voit-il" la MAC du Routeur (Gateway) sur le port Trunk ?
  • (N3) Y a-t-il du "MAC Flapping" (MAC vue sur 2 ports) ? -> Indique une boucle L2.
• VLAN :
  • Le port du PC (ex: Fa0/1) est-il dans le bon VLAN "Access" ? (ex: switchport access vlan 10).
  • (N3) Le VLAN 10 est-il autorisé (allowed) sur le port Trunk qui mène au Routeur ?
• STP (show spanning-tree) :
  • (N3) Le port du PC est-il en état Forwarding ? (Si Blocking, voir PortFast).
  • (N3) Le port Trunk est-il Forwarding ? (Si Blocking -> Boucle détectée).

La question : "L'appareil a-t-il une adresse IP valide ?"

Windows (ipconfig)

C:\> ipconfig /all
...
Carte Ethernet :
   Description . . . . . . . . : Intel(R) ...
   Adresse physique (MAC)  . . : 00-1A-2B-3C-4D-5E
   DHCP activé . . . . . . . . : Oui
   Adresse IPv4. . . . . . . . : 192.168.1.50
   Masque de sous-réseau . . . : 255.255.255.0
   Passerelle par défaut . . . : 192.168.1.1
   Serveur DHCP. . . . . . . . : 192.168.1.1
   Serveurs DNS. . . . . . . . : 8.8.8.8
...

Checklist Diag (ipconfig)

• Adresse IP 169.254.x.x ? -> Échec DHCP (APIPA). Le PC n'a pas pu contacter le serveur DHCP.
• Adresse IP 192.168.1.50 ? -> OK.
• Masque 255.255.255.0 ? -> OK. (Cohérent avec l'IP).
• Passerelle 192.168.1.1 ? -> OK. (Adresse du Routeur).
• Serveurs DNS 8.8.8.8 ? -> OK. (Nécessaire pour L7).

Une fois l'IP validée, ping (ICMP) est utilisé pour tester la connectivité L3 "par étapes" (du plus proche au plus loin).

Méthodologie "Ping"

Problème : "Je n'accède pas à google.com"

1. (Soi-même)
C:\> ping 127.0.0.1
   -> (Teste si la stack TCP/IP locale fonctionne).
   (Échec = Problème OS/Driver).

2. (Son IP)
C:\> ping 192.168.1.50
   -> (Teste si la NIC est fonctionnelle).

3. (La Passerelle)
C:\> ping 192.168.1.1
   -> (Teste la connexion L2/L3 avec le Routeur/Gateway).
   (Échec = Problème L2 : VLAN, Switch, ARP).

4. (Internet - IP)
C:\> ping 8.8.8.8 (DNS Google)
   -> (Teste la connectivité WAN/Internet. Le Routage/NAT fonctionne).
   (Échec = Problème Routeur/FAI).

5. (Internet - Nom)
C:\> ping google.com
   -> (Teste la résolution DNS (L7)).
   (Échec = Problème DNS. Voir 'nslookup').

La question : "Où s'arrête la connexion ?"

tracert (Windows) ou traceroute (Linux/Mac) est l'outil L3 qui montre chaque "saut" (hop) de routeur entre vous et la destination. (Voir guide TCP/IP pour le fonctionnement ICMP/TTL).

Exemple d'Analyse (Panne chez le FAI)

C:\> tracert 8.8.8.8

  1    <1 ms    <1 ms    <1 ms  192.168.1.1  (Mon Routeur)
                               [OK. LAN = OK]
  
  2     8 ms     7 ms     8 ms  10.10.0.1    (FAI - Nœud A)
                               [OK. Connexion FAI = OK]

  3     * * * (Délai d'attente dépassé)
                               [PANNE. Le Nœud A ne joint pas le Nœud B]
  
  4     * * * (Délai d'attente dépassé)

(Le problème n'est pas chez moi, il est chez le FAI).

Analyse de Latence

tracert montre aussi la latence à chaque saut. Si la latence "explose" (ex: 200ms) à un saut spécifique, cela indique une congestion sur ce routeur.

La question : "Qu'est-ce qui écoute (Listening) ? Qui est connecté (Established) ?"

Ces outils affichent l'état des Sockets (IP:Port) sur la machine locale.

C:\> netstat -ano | findstr "80"

  Proto  Adr. locale         Adr. distante       État         PID
  TCP    0.0.0.0:80          0.0.0.0:0           LISTENING    1234
  TCP    192.168.1.50:80     10.20.30.40:56789   ESTABLISHED  1234
(PID 1234 (Nginx) écoute bien sur le port 80)

# (t=tcp, u=udp, l=listening, p=process, n=numeric)
$ ss -tulpn

State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port
LISTEN   0        128      0.0.0.0:22           0.0.0.0:*
LISTEN   0        511      0.0.0.0:80           0.0.0.0:*

La question : "Le firewall (réseau ou hôte) bloque-t-il ce port ?"

ping (ICMP) peut réussir, mais HTTP (TCP 80) peut être bloqué. Ces outils testent la connexion TCP (le 3-Way Handshake).

telnet (Client)

(Doit souvent être installé sur Windows).

# Test de connexion
C:\> telnet 192.168.1.100 80

(Si l'écran devient noir/vide) -> RÉUSSITE !
(Le TCP Handshake (SYN, SYN-ACK, ACK) a fonctionné).

(Si "Connexion..." puis "Impossible de se connecter...") -> ÉCHEC.
(Le port est fermé, filtré (Firewall), ou le service est down).

nc (Netcat) (Linux)

Le "couteau suisse" du réseau. Plus puissant que telnet.

# -z (Zero-I/O) : Scanner (ne pas envoyer de données)
# -v (Verbose)
$ nc -zv 192.168.1.100 80
Connection to 192.168.1.100 80 port [tcp/http] succeeded!

$ nc -zv 192.168.1.100 81
nc: connect to 192.168.1.100 port 81 (tcp) failed: Connection refused

Le Problème : ping 8.8.8.8 (L3) fonctionne, mais ping google.com (L7) échoue.

Diagnostic : C'est une panne DNS (Couche 7).

nslookup (Windows/Linux)

C:\> nslookup google.com
Serveur :   dns.google
Address:   8.8.8.8
...
Réponse : 142.250.179.196
(-> DNS OK)

C:\> nslookup google.com
Serveur :   (Serveur DHCP Interne)
Address:   192.168.1.1
*** 192.168.1.1 ne trouve pas google.com: Non-existent domain.
(-> Panne du DNS Interne/FAI)

dig (Linux/Mac)

Plus verbeux, préféré par les Admins.

$ dig google.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1234
;; ANSWER SECTION:
google.com.             180     IN      A       142.250.186.78
(-> OK)

$ dig google.com @1.1.1.1  (Interroge Cloudflare)
$ dig google.com MX       (Demande les records Mail)
$ dig google.com +trace   (Suit la hiérarchie Root->TLD->Auth)

La question : "Le port 443 est ouvert (telnet OK), mais le site affiche 'Erreur 500'. Est-ce le réseau ou l'application ?"

curl (Client URL) est un outil CLI (L7) pour effectuer des requêtes HTTP/S et voir la réponse (Headers et Body).

Diagnostic des Headers HTTP

# -I (HEAD) : Demande juste les en-têtes (Headers)
# -v (Verbose) : Montre la négociation SSL/TLS
$ curl -Iv https://www.google.com

* Trying 142.250.186.78:443...
* Connected to www.google.com (142.250.186.78) port 443
* ALPN: offers h2
* TLSv1.3 (OUT), TLS handshake... (Négociation SSL OK)
* ... (Certificat OK)
> HEAD / HTTP/2
> Host: www.google.com
>
< HTTP/2 301 (Redirection Permanente)
< location: https://google.com/
< ...
(-> Diagnostic : Le site répond 301, ce n'est pas une panne réseau)

Diagnostic (Proxy, Erreur 503)

C:\> curl -Iv http://mon-serveur-local
< HTTP/1.1 503 Service Unavailable
< Server: nginx/1.22
(-> Diagnostic : Le Load Balancer Nginx est UP,
    mais les serveurs back-end (PHP) sont DOWN).

L'outil N3 ultime. Wireshark est un analyseur de protocole (Sniffer) avec une interface graphique (GUI).

Il capture chaque paquet (L2-L7) qui passe sur une interface réseau (ex: eth0) et vous permet de les inspecter en détail (fichier .pcap).

Usage (Diagnostic)

Quand tous les autres outils (ping, curl) échouent, Wireshark donne la vérité absolue.

• "L'application ne répond pas." -> Wireshark montre-t-il des [TCP RST] (Reset) ?
• "C'est lent." -> Wireshark montre-t-il des [TCP Retransmission] ou [TCP ZeroWindow] ? (Indique une perte de paquet ou un buffer saturé).
• "DHCP échoue." -> Wireshark montre-t-il le DISCOVER, mais jamais l'OFFER ? (Indique un problème de Relais ou de Serveur).

Filtres d'Affichage (Display Filters)

(Les filtres de capture (BPF) sont différents, voir tcpdump)

ip.addr == 192.168.1.50   (Trafic de/vers cette IP)
ip.addr == 1.1.1.1 && ip.addr == 8.8.8.8 (Conversations)
tcp.port == 443           (Trafic HTTPS)
dns                       (Trafic DNS)
http                      (Trafic HTTP (non-crypté))
tcp.flags.syn == 1 && tcp.flags.ack == 0 (Seulement les SYN)

tcpdump est l'équivalent CLI (Ligne de Commande) de Wireshark. Il est utilisé sur les serveurs (Linux) ou routeurs qui n'ont pas d'interface graphique.

Usage

Il est surtout utilisé pour capturer le trafic (dans un fichier .pcap) pour une analyse ultérieure dans Wireshark (sur votre PC).

Filtres BPF (Berkeley Packet Filter)

tcpdump utilise des filtres de capture (très efficaces) pour ne pas enregistrer tout le trafic.

# 1. Écouter sur une interface (verbeux)
$ tcpdump -i eth0

# 2. Écouter (verbeux, sans résolution DNS)
$ tcpdump -i eth0 -n

# 3. Filtrer par Hôte
$ tcpdump -i eth0 host 192.168.1.50

# 4. Filtrer par Port
$ tcpdump -i eth0 port 443

# 5. Combiner (Hôte ET Port)
$ tcpdump -i eth0 host 192.168.1.50 and port 443

# 6. Capturer dans un fichier (pour Wireshark)
# -w (write) -s 0 (snapshot 0 = paquet complet)
$ tcpdump -i eth0 -s 0 -w capture.pcap host 192.168.1.50
(Appuyer sur Ctrl+C pour arrêter)