VPN del móvil a casa: haga del cortafuegos su salida a internet

Conectar un móvil al túnel de casa y abrir un recurso compartido de la LAN demuestra que el túnel funciona. No demuestra que las peticiones de internet del móvil salgan por la casa. La diferencia entre ambos resultados es una política de reenvío más una ruta, no otra casilla en el móvil. Es también la diferencia que la mayoría supone que ya ha configurado.

Tres decisiones producen la ruta de salida: qué envía el móvil al túnel, adónde lo reenvía la puerta de enlace de casa y qué ocurre cuando el túnel no está. Cada una tiene un modo de fallo que, desde la pantalla del móvil, parece el de las demás.

Dos saltos, dos políticas

La conexión exterior termina en el receptor VPN de casa. El paquete interior es un objeto aparte que debe reenviarse a algún sitio, y reenviar es una decisión de cortafuegos distinta de aceptar el túnel en primer lugar.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

En un router doméstico típico, estas viven en conjuntos de reglas distintos. Aceptar el túnel es política de entrada en la interfaz VPN; enviar el tráfico del móvil a internet es política de reenvío más la traducción de origen que necesite el enlace ascendente. Un router que acepta el túnel y no reenvía nada produce un móvil que se muestra conectado y no carga ninguna página.

Si el servicio VPN se ejecuta en una máquina separada dentro de casa, añada un salto. Ahora el router ve tráfico que llega de esa máquina, así que sus reglas se aplican a la dirección del servidor y no a la dirección del túnel del móvil, y la traducción de origen puede hacer que cada móvil parezca un solo host.

El receptor no es el filtro

Decida dónde ocurre la aplicación mientras la información que necesita aún existe. En el router, la dirección del túnel del móvil es visible y puede compararse directamente. Tras una segunda traducción ya no está, y las reglas escritas para la dirección del móvil no coinciden con nada, en silencio.

Esta es la razón habitual de que una política funcione para el portátil y no para el móvil. El portátil se conecta directamente al router, el móvil se conecta a un servidor que reenvía a través del router, y solo el primer camino conserva la dirección que la regla espera. La regla no es incorrecta; está comparando un valor que ya no existe en ese punto.

Escriba la ruta con la dirección de origen tal como aparece en cada punto de aplicación. Ese único diagrama resuelve la mayoría de estos casos antes de editar cualquier regla.

Qué debe enviar realmente el móvil

Un móvil que solo recibe una ruta a la subred de casa solo envía el tráfico de esa subred al túnel. Todo lo demás sale por la red móvil, y por eso el recurso compartido funciona y las peticiones de internet nunca llegan a casa.

La cobertura de túnel completo es una decisión de enrutamiento del lado del cliente, y debe establecerse con el mecanismo que admite la plataforma, no suponerse a partir del perfil que se instala. Una vez establecida, la ruta de vuelta al propio servidor VPN debe quedar fuera del túnel, o el cliente no podrá mantener su propio transporte.

El DNS merece una decisión propia, porque es la parte más propensa a divergir del resto del tráfico. Una dirección de resolutor en el perfil es una sugerencia que los clientes tratan de forma distinta, y una aplicación con su propio resolutor cifrado puede seguir un camino completamente separado. Si la política de casa depende de que las consultas lleguen a un resolutor concreto, aplíquela donde el tráfico pasa realmente, o acepte que algunas consultas no lo harán. Una consulta que evita su resolutor nunca llega a una regla escrita para ella.

IPv6 pertenece al mismo párrafo que el DNS, no a un apéndice. Un túnel completo IPv4 no dice nada sobre el tráfico AAAA, y un móvil en una red móvil de doble pila usará de buen grado la ruta nativa para ello. Elija transporte o bloqueo explícitamente.

Qué puede ver el cortafuegos y qué no

La puerta de enlace puede actuar sobre lo que expone su punto de aplicación: direcciones, puertos, protocolo, interfaz y los metadatos de la conexión. Una petición HTTPS reenviada no entrega el cuerpo de la página ni la contraseña solo porque cruce el túnel de casa.

Vale la pena enunciar ese límite porque la frase «pásalo por el cortafuegos» implica más inspección de la que hace un router doméstico. Una regla de destino, una política de DNS y un proxy de capa de aplicación son tres controles distintos con tres costes de despliegue distintos.

No suponga que una función configurada para clientes de la LAN de casa se aplica a la interfaz VPN. La pertenencia a una zona es una elección de configuración, y una interfaz VPN que no está en la zona correcta no hereda ninguna de las reglas que probó desde el sofá.

Decida el estado desconectado

Cuando el túnel no está disponible, el móvil o vuelve a la red móvil o se niega a enviar el tráfico. Ambas son razonables, y solo una coincide con lo que la mayoría cree que ha configurado.

La vuelta atrás es cómoda y filtra por definición: el momento en que cae el túnel es el momento en que las peticiones salen por la ruta del operador. El bloqueo es más fuerte y hace que el móvil dependa de que la casa sea accesible, lo que supone un coste real de disponibilidad para quien viaja. Ninguno de los dos comportamientos es un error; ambos son productos, y usted elige entre ellos lo diga o no.

Pruebe la elección en lugar de suponerla. Detenga el servicio de casa y luego pruebe una petición desde el navegador del móvil y otra desde una aplicación que se ejecute en segundo plano. Volver a conectarse más tarde no deshace las peticiones que ya han salido.

Termine con dos comprobaciones controladas desde el propio móvil: una operación permitida que debe atravesar la casa y una denegación que la política de casa debe aplicar. Confirme que la puerta de enlace registró el flujo que esperaba, en la familia de direcciones que esperaba, tras reconectarse. Un móvil que muestra Conectado es el comienzo de esa verificación, nunca el final.