Cómo comprobar el estado de IPv6 de un Mac tras desconectarse la VPN

Llegue a un sitio por IPv4 después de que caiga el túnel y no habrá demostrado nada sobre IPv6. macOS configura las dos familias por separado, por servicio de red, y un cliente VPN puede cambiar una sin tocar la otra. Recorra las tres capas en orden: configuración de la dirección, selección de ruta y, después, cualquier política que el cliente instale mientras está desconectado. Mantenga la red de acceso sin cambios mientras tanto, o comparará dos problemas distintos.

Empiece por la familia que realmente se rompió

Una página que carga por IPv4 le dice que la red física está viva. No dice nada sobre si el servicio tiene una dirección IPv6 global, si el prefijo sigue anunciándose o si algo filtra la familia. Confirme qué falló antes de elegir una herramienta, porque un nombre que resuelve a una dirección inalcanzable parece idéntico a un nombre que no resuelve en absoluto. Pregunte qué capa respondió mal y escriba la respuesta. Sin eso, cada paso posterior es una conjetura vestida de procedimiento.

Mantenga la misma red Wi-Fi y el mismo punto de acceso durante toda la comparación. Una red de cafetería que ayer ofrecía IPv6 no dice nada sobre la que tiene ahora.

Lea la dirección antes que la ruta

En Ajustes del Sistema, el panel TCP/IP del servicio activo muestra si IPv6 es automático, manual o solo local de enlace. Compare eso con lo que espera, recordando que una organización puede haber elegido la configuración manual a propósito. Después ejecute ifconfig y lea la interfaz en cuestión. Una dirección fe80:: por sí sola significa que la interfaz puede hablar con sus vecinos y nada más, así que la presencia local de enlace no es prueba de una ruta utilizable.

Busque también interfaces utun que el cliente haya dejado atrás. Un dispositivo de túnel obsoleto puede conservar una dirección y una ruta mucho después de que el cliente dejara de usarlo. Si hay uno, es un hallazgo de ciclo de vida para el propietario del cliente, no algo que borrar en el acto.

Lea la tabla de rutas para el destino que falla

Pregunte al núcleo por el destino que falló, no por la ruta predeterminada. route -n get 2001:db8::25 imprime la interfaz y la puerta de enlace elegidas para esa dirección, y netstat -rn -f inet6 muestra toda la tabla para comparar. Una ruta predeterminada le dice que existe una predeterminada; no le dice que este destino la use.

Mantenga el DNS en su propio compartimento. Un resolutor alcanzable por IPv4 puede seguir devolviendo registros AAAA, así que un fallo de consulta y un fallo de enrutamiento producen el mismo síntoma en el navegador.

Separe la política de bloqueo del cliente de un resto

Algunos clientes están diseñados para bloquear el tráfico mientras están desconectados, incluida la otra familia de direcciones, y ese comportamiento es una característica, no una falla.

Averigüe qué comportamiento documenta su cliente antes de tratar un bloqueo como daño. scutil --dns muestra los resolutores en vigor por servicio, que es donde se hace visible un resolutor instalado por el cliente o un ajuste de DNS con alcance. Después compruebe si se instalaron y quedaron reglas de filtro de paquetes. Un bloqueo esperado y una regla sobrante necesitan respuestas opuestas, y solo la documentación del propietario las separa.

Reúna pruebas y después cambie una cosa

Registre la versión del cliente, la versión de macOS, el servicio de red, la política desconectada prevista y la salida de direcciones y rutas en ambos lados de un ciclo de conexión y desconexión. Ese registro es lo que convierte una queja en un problema de ciclo de vida que alguien puede investigar. Después haga un solo cambio y vuelva a medir.

Resista el reinicio. Borrar interfaces virtuales, vaciar la tabla de rutas y desactivar IPv6 en toda la máquina destruyen el estado que necesitaba capturar, y pueden llevarse configuración no relacionada. Si el cliente tiene un flujo compatible de pausa, reparación o desinstalación, úselo, y siga el procedimiento del administrador donde la red esté gestionada. Una máquina que ya se reinició no le da nada al propietario con lo que trabajar, y suele reproducir la falla en la siguiente conexión.