¿La VPN del móvil cubre el portátil en su punto de acceso?

El navegador del móvil informa de una dirección en otro país y el portátil conectado a su punto de acceso sigue informando del operador móvil. Ninguna de las dos observaciones es errónea, y la contradicción que ve la gente viene de suponer que compartir una conexión a internet también comparte un túnel. Tres condiciones deciden si el tráfico del dispositivo enlazado entra en la VPN del móvil, y solo una de ellas tiene que ver con los ajustes del móvil. Repásalas antes de buscar una función para compartir que puede que no exista.

Qué reenvía realmente el punto de acceso

El anclaje da al portátil una ruta a internet a través de la interfaz móvil del teléfono. El teléfono reenvía esos paquetes y, en el caso habitual, traduce las direcciones del portátil cuando salen. Eso es una función de reenvío, y reenviar no es lo mismo que capturar el tráfico dentro de un túnel.

Si los paquetes reenviados entran después en la VPN del móvil depende de cómo la aplicación VPN instaló sus rutas y reglas. Una aplicación que solo captura el tráfico originado en el teléfono no verá los paquetes que el núcleo reenvía en nombre de un cliente enlazado.

Por eso las dos observaciones conviven con tanta facilidad. El navegador del propio móvil usa el túnel, los paquetes del portátil toman la ruta de reenvío y nada de lo que muestra cualquiera de las dos pantallas le miente. Los dos dispositivos simplemente no hacen la misma pregunta a la misma interfaz. En cuanto vea esa separación, la queja “por qué mi portátil no está protegido” se convierte en una cuestión de diseño y no en un fallo.

Primera condición: qué túnel ejecuta el móvil

Empiece por identificar el alcance de la VPN en el teléfono. Un túnel para todo el dispositivo, un túnel por aplicación y un proxy solo para el navegador son tres cosas distintas, y solo el primero tiene alguna posibilidad de cubrir el tráfico reenviado. Mire la descripción del proveedor sobre lo que captura la aplicación, no el icono de la barra de estado.

Después compruebe qué dice el proveedor sobre el anclaje. Algunos documentan explícitamente que el tráfico normal del punto de acceso queda fuera del túnel, que es la respuesta honesta para un servicio de consumo que nunca prometió ser un enrutador. La guía de Proton VPN para el punto de acceso en Android es un ejemplo publicado de esa distinción; la documentación de su propio proveedor es la que importa para su dispositivo.

Un icono de VPN en la barra de estado le dice que el teléfono tiene un túnel. No le dice qué interfaces cubre ese túnel, y en ese hueco vive la mayor parte de la confusión.

Segunda condición: si el anclaje está incluido

Incluso un túnel para todo el dispositivo puede excluir por diseño el tráfico reenviado, porque las reglas de enrutamiento de la aplicación se escribieron para paquetes generados localmente. Incluir clientes enlazados suele exigir que el proveedor lo admita explícitamente, o un dispositivo con root y reglas personalizadas que la mayoría de la gente no debería intentar.

Pasar de Wi-Fi a USB no cambia esto. El subsistema de anclaje admite varios transportes, pero el transporte no es la decisión de enrutamiento. Un cable hace el enlace más estable y no hace nada por la cobertura del túnel, y por eso el consejo de “usa solo USB” responde a una pregunta distinta de la que se hace.

Las recetas antiguas que vacían las reglas del cortafuegos y suponen nombres de interfaz concretos no son instrucciones portables. Se escribieron para un dispositivo concreto, una ROM concreta y un año concreto, y aplicarlas a un teléfono actual es más probable que rompa el anclaje a que extienda un túnel.

Tercera condición: qué identidad necesita el destino

Esta es la condición que suele resolver el diseño, y no tiene nada que ver con los puntos de acceso. Si el portátil tiene que llegar a la red de un empleador, la identidad que importa pertenece al portátil, y una VPN de consumo en el teléfono no puede proporcionarla.

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

Ejecute esos comandos en el portátil, no en el teléfono, porque la pregunta es qué ve el destino desde el dispositivo que le importa. Una dirección pública informada por el teléfono responde a una pregunta sobre el teléfono.

Incluso un resultado coincidente desde el portátil es una prueba limitada. La resolución de nombres, otras aplicaciones y el comportamiento cuando falla el túnel pertenecen al dispositivo cuya cobertura está probando, y una sola petición HTTP no caracteriza nada de eso. Pruebe la aplicación que realmente le importa y vuelva a probarla con el túnel desconectado a propósito.

Qué hacer en su lugar, por orden de esfuerzo

La respuesta correcta más barata es ejecutar la VPN en el portátil. Conéctelo al punto de acceso, deje que el teléfono proporcione la conexión móvil subyacente y establezca el túnel desde el dispositivo que necesita la identidad. Esto funciona con las VPN de empresa, que es el caso que más importa.

Si el dispositivo no puede ejecutar ningún cliente VPN, busque una pasarela para compartir admitida explícitamente o un enrutador de viaje que termine el túnel. Lea su documentación para la plataforma real en lugar de suponer que una función de punto de acceso es esa pasarela.

Si ninguno de los dos es posible, acepte la limitación en lugar de sortearla con una receta que no puede mantener. La VPN del móvil cubre el móvil; el portátil necesita su propio camino, y saberlo de antemano vale más que una tarde de experimentos con interfaces. Documente el acuerdo para que la siguiente persona no lo redescubra durante un incidente. Una línea en la wiki del equipo es suficiente.