Sophos AP6 sin conexión: diagnosticar aprovisionamiento, rendimiento y roaming

En un AP6 pueden fallar dos niveles independientes: el plano de gestión conecta el punto de acceso con Sophos Fusion (antes Sophos Central) y transporta estado y configuración. La ruta de datos del cliente va desde el cliente Wi-Fi, pasando por AP6, switch y VLAN, hasta DHCP, DNS, gateway y destinos permitidos. Un estado verde en Central no demuestra la ruta de datos; un problema del cliente tampoco demuestra un fallo de la conexión cloud.

Ruta rápida: con Offline, compruebe primero alimentación, enlace, DHCP, DNS, hora y acceso a Internet/Central. Con Pending, no acumule cambios: anote estado y hora, estabilice la conexión y observe el avance de la tarea. Si el AP está online y el SSID visible, revise por separado IP del cliente, VLAN, DHCP, DNS y reglas. Para rendimiento o roaming, use una prueba reproducible y cambie un solo parámetro cada vez.

Antes consulte los requisitos de red de AP6, el proceso de incorporación y la gestión local o con Central.

Conservar evidencias y limitar el riesgo

Anote nombre, número de serie, modelo, sitio, puerto de switch, fuente PoE, IP de gestión, Config status, última actividad, firmware, perfil y SSID. Registre también inicio del síntoma, clientes afectados y último cambio. No incluya contraseñas, archivos completos ni datos del cliente en tickets sin protección.

No cambie a la vez VLAN, perfil y parámetros de radio ni empiece con un restablecimiento de fábrica. Use un AP piloto y un cliente conocido. El restablecimiento destruye contexto de diagnóstico.

Síntoma 1: AP6 aparece Offline en Central

Para AP6, Offline significa que el punto de acceso no puede comunicarse con Sophos Fusion.

1. Alimentación y enlace: compruebe clase PoE, puerto y enlace. Una alimentación insuficiente puede apagar las radios y genera un aviso en Central y la interfaz local. La clase PoE depende del modelo AP6.
2. Direccionamiento local: revise concesión, VLAN de gestión, gateway y DNS. Si tampoco se accede a la interfaz local, Sophos cita DHCP ausente, potencia insuficiente y STP activo en el uplink como causas posibles.
3. Ruta a Central: cumpla los requisitos de red y dominios. Sophos indica los puertos salientes 443 (HTTPS), 80 (HTTP) y 123 (NTP).
4. Hora: abra localmente Management > Date and time y corrija el reloj del AP.
5. Vuelva a observar: cuando el AP esté online, espere su estado de configuración antes de probar clientes.

Mientras siga offline no se pueden iniciar desde Central capturas, Syslog ni una nueva recopilación de registros del sistema: requieren un AP online o verde. Reúna evidencias de switch, DHCP, DNS y gateway y escale con hora y número de serie.

Síntoma 2: caduca el registro o el aprovisionamiento queda Pending

AP did not connect to cloud within the timeout indica que el AP no alcanzó Central durante la ventana mostrada. Revise la misma ruta, los puertos y la hora antes de volver a registrarlo.

Con Pending, separe estado y efecto:

• Si el AP también está offline, restaure primero el plano de gestión.
• Si está online, anote tarea, hora y último cambio. No envíe un segundo cambio de perfil, SSID o radio.
• Observe después si avanzan el estado y la configuración prevista. Solo entonces conecte un cliente y valide la ruta de datos.
• Si el estado sigue bloqueado de forma reproducible, recopile registros del sistema mientras el AP esté verde y abra un caso de soporte en vez de repetir restablecimientos y registros.

Para cambios de SSID y VLAN siga el piloto de SSID y VLAN para AP6, de modo que el aprovisionamiento quede separado de la red cliente posterior.

Síntoma 3: AP online pero clientes sin conectividad

Revise la ruta desde dentro hacia fuera:

1. ¿Se ve el SSID previsto y funciona la autenticación Wi-Fi?
2. ¿Qué dirección IP, máscara, gateway y DNS recibe el cliente?
3. ¿Está permitida la VLAN prevista en el puerto del AP y cada uplink?
4. ¿Alcanza el cliente DHCP, después gateway y DNS y finalmente exactamente los destinos permitidos?
5. ¿Funciona la misma prueba en un SSID de referencia sin cambios o en otro AP?

Cambie solo la primera etapa que se demuestre defectuosa. El estado online en Central confirma la gestión, no DHCP, DNS, VLAN ni reglas de la ruta cliente.

Elegir la herramienta de diagnóstico adecuada

En My Products > Wireless > Diagnostics, Central ofrece Events, Audit logs, Packet capture, Syslog, System logs y Support settings.

• System logs: Central recopila registros completos de AP6 y ofrece un archivo .GZ. Collect logs solo está disponible con estado verde.
• Packet capture: para AP6, la captura Central registra paquetes recibidos en los puertos LAN cableados y exige estado verde. Use la interfaz local del AP para una captura WLAN. Iníciela justo antes de la prueba, anote cliente y hora y deténgala después.
• Syslog: Central solo lo configura para AP online. El servidor debe ser alcanzable y responder a ICMP o el AP no enviará paquetes UDP. El valor predeterminado es UDP 514; Sophos recomienda no más de dos AP por servidor para no mezclar datos.
• Support settings: active Remote Login solo durante un periodo adecuado: 5 horas, 1, 7, 14 o 30 días. Al desactivarlo se revoca inmediatamente el acceso de Sophos Support.

Documente el inicio y el final de cada captura. Para conocer la configuración detallada, la interpretación y la detención segura, consulte el procedimiento de diagnóstico de AP6 para registros y capturas de paquetes. Las capturas y los registros pueden contener datos sensibles y deben eliminarse tras el caso según su política de conservación.

Síntoma 4: bajo rendimiento, VoIP o roaming

Defina una prueba reproducible: cliente, SSID, AP inicial y final, recorrido, hora, aplicación y resultado. Mida en los mismos puntos y cambie un solo parámetro. Compruebe también si el fallo aparece en la ruta cableada o solo en un AP, banda o cliente.

Para llamadas VoIP deficientes o interrumpidas, Sophos indica tres comprobaciones AP6 en Central:

• Ajustar Guard interval del perfil asignado a Normal GI (0.8 µs) o más.
• Ajustar Sip station idle timeout a 300 o más.
• Desactivar Airtime fairness en los AP con VoIP porque puede causar demora, jitter y desconexiones.

Guard interval y Sip station idle timeout se aplican a todo el perfil. Antes de cambiar cualquiera de ellos, verifique que el perfil asignado contiene únicamente el AP piloto; de lo contrario, cree y asigne un perfil dedicado solo al piloto. Son cambios específicos de VoIP y no se despliegan juntos. Anote cada valor anterior, repita la misma llamada y recorrido tras un solo cambio y restaure el valor anterior si empeora.

Para un problema de roaming, marque lugar y hora exactos del corte y compare al menos dos recorridos. Compruebe si falla solo al cambiar de AP o también sin moverse. Trate Offline o Pending en el plano de gestión; investigue un corte cliente reproducible con datos del cliente, registros del AP y una captura limitada. Así evitará cambiar la radio cuando falla DHCP, DNS o el uplink cableado.

Validación y vuelta atrás segura

La corrección solo queda confirmada si el AP permanece online, ninguna tarea relevante sigue bloqueada y un cliente completa varias veces autenticación, configuración IP y acceso a gateway, DNS y destinos permitidos. Para rendimiento y roaming documente el mismo recorrido antes y después de un solo cambio.

Si falla el piloto, restaure únicamente el último valor de perfil, SSID o radio según la línea base. Espere el estado de Central y repita la prueba. Detenga captura y Syslog y desactive Remote Login cuando soporte ya no lo necesite. Restablecer, registrar de nuevo y cambiar la red simultáneamente son pasos de escalado, no la primera vuelta atrás.