La VPN funciona con Wi-Fi pero no con datos móviles: por qué

Empiece por una comparación, no por una conclusión: el mismo teléfono, el mismo perfil, dos redes. Si el túnel falla en una y funciona en la otra, la diferencia está en algún punto del camino y no en las credenciales. Anote qué tipo de fallo obtiene, porque un rechazo antes del inicio de sesión y una conexión que no transporta nada son problemas distintos. Todo lo que sigue presupone esa prueba, hecha cambiando solo la red.

Una VPN necesita la conexión subyacente; no la sustituye y no puede obligar a un operador a transportar lo que el operador se niega a transportar.

Mantenga el teléfono fijo y cambie solo la red

Cambiar la red y el servidor al mismo tiempo deja dos causas posibles y ninguna forma de separarlas. Compare el mismo punto final primero con Wi-Fi y después con datos móviles, y anote el síntoma exacto cada vez. Un fallo antes de la autenticación apunta a la accesibilidad, un rechazo de credenciales apunta a la cuenta, y un túnel conectado que no transporta nada apunta al enrutamiento o al DNS. Solo el primero tiene que ver realmente con la red.

Un rechazo explícito al iniciar sesión también pertenece a las comprobaciones de autenticación, aunque solo aparezca en una red. Algunos operadores y redes de invitados interceptan el tráfico de formas que producen errores engañosos.

Qué puede ver y cobrar la red de acceso

El operador que transporta el túnel observa la conexión misma: el tiempo, el volumen y la dirección del punto final de la VPN. Cifrar la carga útil no oculta esas propiedades, y eso vale igual en un enlace Wi-Fi doméstico que en datos móviles. Lo que cambia una VPN es quién puede ver qué, y la respuesta es distinta en cada salto. Anótelo salto a salto en lugar de describir la conexión como privada en general.

Los cargos son la otra diferencia práctica. La encapsulación, las señales de mantenimiento y los reintentos consumen bytes, y las aplicaciones pueden reanudar una transferencia tras un traspaso. También existe Wi-Fi doméstico con límite, así que revise los contadores del dispositivo y la tarifa en lugar de suponer que ninguna de las dos redes es ilimitada.

Inicios de sesión del portal y restricciones del operador

Hay que satisfacer un portal cautivo antes de que el túnel pueda llegar a cualquier sitio. Volver a conectar la VPN no admitirá un dispositivo que la red no ha autorizado, y una política de siempre conectado puede dejar el portal inaccesible. Complete primero el inicio de sesión por el flujo normal del navegador y luego levante el túnel. Si una política gestionada impide ese orden, siga el proceso documentado del operador o del administrador.

Las restricciones del operador son la otra variable: algunos caminos solo transportan ciertos protocolos, algunos traducen direcciones de forma agresiva y algunos tratan una familia de direcciones de manera distinta de la otra. La comparación reduce el fallo al camino sin identificar qué mecanismo es el responsable.

El traspaso no es lo mismo que reconectar

Una vez que cada red funciona por sí sola, observe un traspaso real. El cliente puede detectar el cambio y reconectar, o puede mantener una sesión que ahora está muerta. Las aplicaciones que ya se usan se recuperan de forma distinta a las que se abren tras el cambio, así que un icono de túnel persistente prueba poco. Pruebe la aplicación que de verdad le importa durante la transición y anote si se recupera sin intervención manual.

Si el túnel solo falla tras estar inactivo, una señal de mantenimiento puede resolver un caso de estado de NAT. No repara una señal débil ni arregla todos los traspasos. Distinga la inactividad del movimiento antes de cambiar ajustes.

Anote la red, la etapa del fallo y el comportamiento durante un traspaso. Esas tres cosas separan un problema de camino de un problema de cliente.