Un cliente nuevo atascado en obtener IP no es un fallo de la VPN

Un teléfono se une al punto de acceso, se queda en «Obteniendo dirección IP» y acaba rindiéndose. La conclusión natural es que la VPN del teléfono interfiere con el DNS, así que la gente empieza a editar resolutores y reglas añadidas. Esa es la etapa equivocada. El cliente nunca recibió una dirección local, y sin una no tiene puerta de enlace, ni resolutor, ni nada que reenviar, así que ningún ajuste de VPN en el teléfono anfitrión puede explicar el fallo. La asociación, la asignación de dirección local y el reenvío son tres etapas separadas, y solo la última implica el túnel.

Las tres etapas, y en cuál estás

Primero viene la asociación: el cliente se une a la red inalámbrica del punto de acceso. Una contraseña incorrecta, un desajuste de WPA3 o un problema de compatibilidad de radio fallan aquí, y el cliente normalmente lo dice. Segundo viene la asignación de dirección: para IPv4 el cliente pide un arrendamiento y recibe una dirección más ajustes locales de puerta de enlace, mientras que IPv6 normalmente usa anuncios de enrutador en lugar de DHCP, como describe la documentación de AOSP sobre tethering. Tercero viene el acceso hacia fuera: el teléfono anfitrión reenvía el tráfico permitido a la ruta ascendente que haya elegido, que puede ser o no su túnel.

El texto del cliente te dice la etapa. Atascado en obtener una dirección es la segunda etapa, antes de que salga ningún paquete hacia internet. Conectado, con dirección, pero sin que cargue nada es la tercera etapa, donde importan el enrutamiento, los nombres y la cobertura del túnel. Diagnosticar la tercera etapa mientras el cliente está atascado en la segunda es cómo un problema de arrendamiento de cinco minutos se convierte en una tarde de ediciones de DNS.

El mito: una VPN enrutada convierte el DHCP local en una petición remota

Un túnel enrutado mueve paquetes IP para los destinos que selecciona. Un descubrimiento DHCP es una difusión en el propio segmento del punto de acceso, y el servicio de tethering del teléfono responde localmente, por eso el cliente puede obtener una dirección mientras el túnel está activo. Solo un diseño puente o retransmitido deliberadamente envía ese intercambio a otro sitio, y eso es otra disposición con otra firma de fallo.

Así que «el servidor VPN no responde al DHCP» no es un diagnóstico, es un error de modelo. El intermediario local está en el teléfono. Si deja de responder, las razones son locales: el servicio de tethering, el límite de clientes, el conjunto de arrendamientos o un cliente que nunca completó bien la asociación. Nada de eso vive en el lado remoto del túnel.

Qué demuestra en realidad que un cliente existente funcione

Si un portátil que ya estaba conectado sigue funcionando mientras el teléfono nuevo no, el punto de acceso y la ruta ascendente están vivos en general. Esa comparación es útil y no es prueba de qué componente tiene la culpa, porque el cliente que funciona puede simplemente retener un arrendamiento de antes del cambio y renovarlo en silencio.

Merece la pena comprobar dos límites locales mientras estás allí. El punto de acceso sirve un conjunto finito de arrendamientos y un límite configurable de clientes, así que un dispositivo que se unió y se durmió puede retener una dirección mientras uno nuevo espera. Y un cliente que recuerda una configuración estática de otra red no pedirá ningún arrendamiento, lo que desde fuera parece idéntico y se corrige en el cliente, no en el teléfono.

Mantén la comparación local y reversible

En un dispositivo donde la política lo permita, compara una unión de cliente nuevo con el túnel inactivo y luego activo, manteniendo el punto de acceso y el cliente sin cambios por lo demás. Anota las versiones del teléfono y del cliente, el perfil seleccionado y la etapa exacta que falló. En un teléfono gestionado, solicita la comparación aprobada en lugar de desactivar la aplicación para obtener una prueba más limpia.

Un fallo de arrendamiento consistente y dependiente del túnel es una evidencia útil sobre política local o una interacción de implementación. No es una licencia para vaciar cada regla de reenvío y NAT del dispositivo. Esas reglas protegen tráfico no relacionado, y una aceptación amplia de reenvío no explica por qué un servicio DHCP local dejó de responder.

Tampoco tapes un arrendamiento ausente con una dirección estática supuesta. Una configuración estática deliberada necesita la subred real, la puerta de enlace, el plan de asignación y una comprobación de colisiones. Cambiar el DNS del cliente no aporta nada de eso, y deja al siguiente dispositivo con el mismo fallo.

Qué no demuestra un arrendamiento

Obtener una dirección demuestra la admisión a la red local, no la protección por el túnel del teléfono. Una vez que el cliente tiene un arrendamiento, evalúa la ruta descendente por sí sola: ¿el tráfico del cliente pasa realmente por el teléfono, se resuelven las consultas donde esperas y la dirección exterior coincide con la salida que pretendías? Son preguntas de la tercera etapa y merecen su propia prueba en lugar de plegarse en la unión.

Trabaja las etapas en orden y el fallo deja de moverse. Un cliente atascado en obtener una dirección es una cuestión local de tethering; un cliente con dirección y sin páginas es una cuestión de reenvío o de nombres; un cliente con páginas y la salida equivocada es una cuestión de cobertura del túnel. Mantenerlos separados es la mayor parte de la depuración.