Diagnostic Connectivité

Localiser une défaillance de connectivité active sans modifier la configuration réseau. Collecter l'ensemble minimal d'évidences utiles, distinguer les observations des inférences, et arrêter quand le domaine de défaut est assez clair pour la prochaine action sûre.

Quand utiliser cette compétence

Utilisez ce flux de travail quand un endpoint macOS présente un symptôme actif tel que :

• une API, un site web, ou un service MCP qui expire ou se déconnecte ;
• des défaillances de résolution DNS ou une résolution de noms incohérente ;
• une perte de paquets, une latence, ou un trafic interactif instable ;
• une application qui semble hors ligne alors que le reste du trafic fonctionne ;
• une incertitude quant à savoir si le problème est local, upstream, ou au niveau du service.

Ceci est un flux de travail de diagnostic, non de remédiation. Ne modifiez pas l'état de l'interface, les paramètres DNS, la configuration VPN/firewall, ou l'état du service distant lors de l'établissement du domaine de défaut.

Flux de décision rapide

Progressez du symptôme vers la vérification discriminante la plus étroite :

symptôme
  -> évidences de lien local / LAN
  -> configuration et résolution DNS
  -> accessibilité de la destination
  -> qualité du chemin
  -> timing du service / application
  -> évaluation du domaine de défaut

Arrêtez tôt quand l'évidence est déjà suffisante. N'exécutez pas mécaniquement chaque sonde.

1. Définir le symptôme

Enregistrez l'application ou le processus affecté, le hostname ou l'URL de destination, quand la défaillance a commencé, si elle est continue ou intermittente, et si les destinations sans rapport fonctionnent toujours.

Si le symptôme est spécifique à l'application, conservez le hostname ou l'URL exact que l'application utilise. Tester un site public sans rapport peut établir la connectivité générale mais ne peut pas prouver que le service affecté est sain.

2. Vérifier les évidences de lien local / LAN

Quand disponible, exécutez un échantillon networkQuality délimité pour un signal large de réactivité et débit. Si networkQuality n'est pas disponible, continuez ; c'est optionnel.

Si une passerelle locale connue ou une cible sur le même LAN sont disponibles, comparez un court échantillon ping sur cette cible locale avec un court échantillon vers la destination distante. N'inventez pas une adresse de passerelle. Si aucune cible locale n'est connue, laissez le segment LAN non prouvé et continuez.

Motif utile :

ping -c 5 <cible-locale-connue>
ping -c 5 <destination>

3. Séparer la configuration DNS du comportement DNS

Inspectez l'état du résolveur système, particulièrement quand les VPNs, split DNS, ou les résolveurs limités pourraient être impliqués :

scutil --dns

Puis testez le nom de destination directement avec une requête DNS délimitée :

dig +time=2 +tries=1 <hostname>

Traitez-les comme des évidences différentes. scutil --dns affiche la configuration du résolveur ; dig montre le comportement des requêtes. Une résolution réussie ne prouve pas que le endpoint retourné est accessible.

4. Tester l'accessibilité et la qualité du chemin

Utilisez un court échantillon ping quand ICMP est un signal utile :

ping -c 5 <destination>

Si le hostname se résout, testez l'adresse retournée séparément uniquement quand cela aide à distinguer le comportement DNS d'une défaillance de chemin. Si la résolution échoue actuellement, utilisez une adresse uniquement si elle a été observée précédemment à partir d'évidences d'incident fiables ; autrement laissez l'accessibilité au niveau adresse inconnue.

Utilisez une traceroute numérique délimitée quand la visibilité du chemin réduirait l'incertitude :

traceroute -n -q 1 -m 20 <destination>

Un saut silencieux ou changeant est une observation, pas la preuve que le saut est cassé. Les routeurs peuvent filtrer ou limiter le trafic traceroute tout en transmettant normalement le trafic applicatif.

5. Inspecter l'activité réseau en direct de l'application affectée

Quand le problème est spécifique au processus, utilisez une capture nettop délimitée plutôt que de regarder indéfiniment :

nettop -n -L 3 -p <nom-du-processus-ou-pid>

Utilisez-le pour confirmer si le processus ouvre des connexions, quels endpoints il utilise, et si le trafic circule. L'absence d'activité visible peut signifier que l'application n'a jamais tenté la connexion ; ce n'est pas en soi une preuve du pourquoi.

6. Chronométrer le chemin de l'application

Pour HTTP(S), utilisez le timing des phases curl contre le endpoint affecté réel quand une requête en lecture seule sûre est disponible. Confirmez que le endpoint fourni dans l'incident est une URL http:// ou https:// complète, conservez son schéma original, et passez l'URL comme un seul argument entre guillemets plutôt que d'interpoler du texte arbitraire de l'incident dans la commande shell :

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  --connect-timeout 5 --max-time 15 '<url-http-ou-https-affectée>'

Interprétez les phases comparativement. Un temps-premier-octet élevé peut inclure le traitement serveur, donc ce n'est pas une preuve de latence réseau.

Règles d'évidences

Classifiez les conclusions comme l'une de :

• Observée — directement soutenue par la sortie de commande ou l'évidence fournie par l'utilisateur.
• Inférée — l'explication la plus probable après corrélation des observations.
• Inconnue — non établie par l'évidence actuelle.

Ne traitez jamais une seule sonde comme preuve de cause racine. En particulier :

• un ping échoué peut refléter un filtrage ICMP plutôt qu'une panne ;
• un ping réussi ne prouve pas qu'une application est saine ;
• les sauts traceroute non-réactifs ne prouvent pas une perte de paquets sur ces routeurs ;
• une résolution DNS réussie ne prouve pas l'accessibilité ;
• un temps HTTP premier-octet élevé peut être dominé par le traitement distant de l'application.

Quand les observations entrent en conflit, préférez inconclusive à une supposition confiante.

Évaluation du domaine de défaut

Retournez exactement une catégorie primaire :

• local-link/LAN — l'évidence se dégrade avant ou à la limite du réseau local ;
• DNS — la configuration du résolveur ou le comportement de recherche expliquent mieux la défaillance que l'évidence de chemin ;
• upstream-path — l'évidence locale est saine et l'évidence de chemin corrélée se dégrade au-delà du LAN ;
• remote-service/application — l'évidence de transport/chemin est assez saine alors que le comportement du service affecté ou du processus reste anormal ;
• inconclusive — l'évidence actuelle ne peut pas séparer les domaines de défaut restants.

Utilisez une confiance qualitative : low, medium, ou high. La confiance reflète la qualité et la corrélation des évidences, non la sévérité.

Format du résultat d'incident

Symptôme

Réitérez la défaillance active et la destination / application affectée.

Observations

Listez uniquement les mesures pertinentes, incluant l'évidence importante indisponible ou bloquée. Marquez clairement les observations, inférences, et inconnues.

Évaluation du domaine de défaut

Rapportez la catégorie, la confiance, et une brève explication liée aux évidences.

Prochaine vérification la plus sûre

Donnez une action diagnostique qui réduit le plus l'incertitude. Ne passez pas à des modifications de configuration sauf si l'utilisateur demande séparément une remédiation.

Sécurité et limites

Pendant le diagnostic, ne pas :

• modifier l'état de l'interface ou redémarrer les services réseau ;
• éditer la configuration du résolveur ou vider les caches DNS ;
• modifier les paramètres firewall ou VPN ;
• installer des paquets ou nécessiter Homebrew ;
• envoyer des requêtes changeant l'état vers les services distants ;
• exécuter des sondes infinies ou de haut volume quand un échantillon délimité répondrait à la question.

Les sondes partielles, l'ICMP bloqué, les VPNs, les portails captifs, les DNS limités, les proxies, les contrôles d'endpoint, et les défaillances transitoires sont des limitations d'évidence plutôt que des diagnostics.

Interprétation détaillée

Lisez references/details.md pour l'interprétation commande par commande, la gestion d'ambiguïté, les conseils de défaillance intermittente, et les exemples travaillés.

Compétences liées

• incident-runbook-templates - Transformer les incidents de connectivité récurrents en procédures de réponse reproductibles
• on-call-handoff-patterns - Préserver l'évidence de connectivité active à travers les passations de répondants
• postmortem-writing - Documenter les causes confirmées et les actions correctives après l'incident