Sophos AP6 hors ligne : diagnostiquer le provisioning, les performances et le roaming

Deux niveaux indépendants peuvent être en panne sur un AP6 : le plan de gestion relie le point d’accès à Sophos Fusion (anciennement Sophos Central) et transporte l’état et la configuration. Le chemin de données client va du client Wi-Fi, via l’AP6, le switch et le VLAN, jusqu’à DHCP, DNS, la passerelle et les destinations autorisées. Un état Central vert ne valide pas le chemin de données ; un problème client ne prouve pas non plus une panne de la connexion cloud.

Parcours rapide : pour Offline, vérifiez d’abord l’alimentation, le lien, DHCP, DNS, l’heure et l’accès Internet/Central. Pour Pending, n’empilez pas les modifications : notez l’état et l’heure, stabilisez la connexion, puis observez l’avancement de la tâche. Si l’AP est en ligne et le SSID visible, contrôlez séparément l’IP client, le VLAN, DHCP, DNS et les règles. Pour les performances ou le roaming, reproduisez le test et ne changez qu’un paramètre à la fois.

Consultez auparavant les prérequis réseau AP6, la procédure d’onboarding et la gestion locale ou Central d’un AP6.

Préserver les preuves et limiter le risque

Notez le nom, le numéro de série, le modèle, le site, le port du switch, la source PoE, l’IP de gestion, le Config status, la dernière activité, le firmware, le profil et les SSID. Ajoutez le début du symptôme, les clients concernés et la dernière modification. Ne placez ni mots de passe, ni archives complètes, ni données client dans un ticket non protégé.

Ne modifiez pas simultanément VLAN, profil et paramètres radio, et ne commencez pas par une réinitialisation d’usine. Utilisez un AP pilote et un client de test connu. Une réinitialisation détruit le contexte de diagnostic.

Symptôme 1 : l’AP6 est Offline dans Central

Pour un AP6, Offline signifie que le point d’accès ne peut pas communiquer avec Sophos Fusion.

Alimentation et lien : vérifiez la classe PoE, le port et le lien. Une alimentation insuffisante peut désactiver les radios et déclencher un avertissement dans Central et l’interface locale. La classe PoE dépend du modèle AP6.
Adressage local : vérifiez le bail, le VLAN de gestion, la passerelle et DNS. Si l’interface locale est inaccessible, Sophos cite l’absence de DHCP, une alimentation insuffisante et STP actif sur l’uplink comme causes possibles.
Chemin Central : respectez les exigences réseau et de domaines. Sophos indique les ports sortants 443 (HTTPS), 80 (HTTP) et 123 (NTP).
Heure : ouvrez localement Management > Date and time et corrigez l’horloge.
Nouvelle observation : lorsque l’AP revient en ligne, attendez son état de configuration avant de tester les clients.

Tant que l’AP reste hors ligne, il est impossible de lancer dans Central une capture, Syslog ou une nouvelle collecte de journaux système : ces fonctions exigent un AP en ligne ou vert. Collectez alors les preuves du switch, de DHCP, DNS et de la passerelle, puis escaladez avec l’heure et le numéro de série.

Symptôme 2 : délai d’enregistrement dépassé ou provisioning Pending

Le message AP did not connect to cloud within the timeout indique que l’AP n’a pas atteint Central pendant la fenêtre affichée. Vérifiez le même chemin Central, les ports requis et l’heure de l’AP avant un nouvel enregistrement.

Pour Pending, séparez l’état de son effet :

Si l’AP est aussi hors ligne, restaurez d’abord le plan de gestion.
S’il est en ligne, notez la tâche, l’heure et la dernière modification. N’envoyez pas une seconde modification de profil, SSID ou radio.
Observez ensuite l’avancement de l’état et de la configuration attendue. Ne validez le chemin client qu’après cela.
Si l’état reste bloqué de façon reproductible, collectez les journaux système pendant que l’AP est vert et ouvrez un dossier de support au lieu de répéter les réinitialisations et enregistrements.

Pour un changement de SSID ou VLAN, suivez le pilote SSID et VLAN AP6 afin de distinguer le provisioning du réseau client en aval.

Symptôme 3 : AP en ligne, mais clients sans connexion

Contrôlez le chemin de données de l’intérieur vers l’extérieur :

Le SSID attendu est-il visible et l’authentification réussit-elle ?
Quelles adresse IP, masque, passerelle et valeurs DNS reçoit le client ?
Le VLAN prévu est-il autorisé sur le port de l’AP et chaque uplink ?
Le client atteint-il DHCP, puis la passerelle et DNS, puis exactement les destinations autorisées ?
Le même test fonctionne-t-il sur un SSID de référence inchangé ou un second AP ?

Ne changez que la première étape dont la panne est démontrée. L’état en ligne dans Central confirme la gestion, pas DHCP, DNS, le VLAN ou les règles du chemin client.

Choisir l’outil de diagnostic adapté

Sous My Products > Wireless > Diagnostics, Central propose Events, Audit logs, Packet capture, Syslog, System logs et Support settings.

System logs : Central collecte les journaux complets d’un AP6 et fournit un fichier .GZ. Collect logs n’est disponible qu’avec un état vert.
Packet capture : pour AP6, la capture Central enregistre les paquets reçus sur les ports LAN filaires et exige un état vert. Utilisez l’interface locale de l’AP pour une capture WLAN. Lancez-la juste avant le test, notez client et heure, puis arrêtez-la.
Syslog : Central ne le configure que pour les AP en ligne. Le serveur doit être joignable et répondre à ICMP, sinon l’AP n’envoie pas de paquets UDP. Le port par défaut est UDP 514 ; Sophos recommande au maximum deux AP par serveur afin de ne pas mélanger les données.
Support settings : n’activez Remote Login que pour une durée adaptée : 5 heures, 1, 7, 14 ou 30 jours. Le désactiver révoque immédiatement l’accès du support Sophos.

Documentez le début et la fin de chaque collecte. Pour la configuration détaillée, l’interprétation et l’arrêt sécurisé, suivez la procédure de diagnostic AP6 consacrée aux journaux et aux captures de paquets. Captures et journaux peuvent contenir des données sensibles ; supprimez-les après le dossier selon votre politique de conservation.

Symptôme 4 : mauvaises performances, VoIP ou roaming

Définissez un test reproductible : client, SSID, AP de départ et d’arrivée, parcours, heure, application et résultat. Mesurez aux mêmes endroits et ne modifiez qu’un paramètre. Vérifiez aussi si le défaut existe sur le chemin filaire ou seulement sur un AP, une bande ou un client.

Pour des appels VoIP médiocres ou interrompus, Sophos indique trois contrôles AP6 dans Central :

Régler Guard interval du profil affecté sur Normal GI (0.8 µs) ou plus.
Régler Sip station idle timeout sur 300 ou plus.
Désactiver Airtime fairness sur les AP transportant la VoIP, car cette option peut causer délai, jitter et déconnexions.

Guard interval et Sip station idle timeout s’appliquent à tout le profil. Avant de modifier l’une de ces valeurs, vérifiez que le profil affecté ne contient que l’AP pilote ; sinon, créez et affectez un profil dédié uniquement au pilote. Ces modifications sont propres à la VoIP et ne doivent pas être déployées ensemble. Notez chaque valeur initiale, répétez le même appel et parcours après une seule modification, puis restaurez la valeur précédente si le résultat se dégrade.

Pour un problème de roaming, marquez le lieu et l’heure exacts de l’interruption et comparez au moins deux passages. Vérifiez si la connexion tombe seulement entre AP ou aussi à l’arrêt. Traitez Offline ou Pending sur le plan de gestion ; analysez une coupure client reproductible avec les données du client, les journaux AP et une capture limitée dans le temps. Vous évitez ainsi de modifier la radio alors que DHCP, DNS ou l’uplink filaire est en cause.

Validation et retour sûr

La correction n’est confirmée que si l’AP reste en ligne, qu’aucune tâche pertinente ne reste bloquée et qu’un client réussit plusieurs fois l’authentification, reçoit la bonne configuration IP et atteint passerelle, DNS et destinations autorisées. Pour performances et roaming, documentez le même parcours avant et après une seule modification.

En cas d’échec du pilote, restaurez uniquement la dernière valeur de profil, SSID ou radio d’après l’état initial. Attendez l’état Central et répétez le test. Arrêtez capture et Syslog, puis désactivez Remote Login dès que le support n’en a plus besoin. Réinitialisation, nouvel enregistrement et changements réseau simultanés sont des étapes d’escalade, pas le premier retour.