Llegar a un dispositivo de casa mediante una VPN de acceso remoto: cinco puertas

Una VPN comercial de salida a internet oculta su dirección; no le conecta con su propia casa. Llegar al NAS o a la impresora de una red doméstica necesita una puerta de enlace en esa red y un cliente que construya un túnel hacia ella. Después el paquete debe superar cinco comprobaciones, y cualquiera de ellas que falle se ve igual desde fuera.

Puerta 1: el cliente debe seleccionar el túnel

Compruebe que el prefijo de destino realmente se enruta hacia el túnel en el cliente. Un perfil de túnel dividido que solo empuja la subred propia de la VPN enviará 192.168.x.x directamente por la interfaz local, donde no va a ninguna parte. Mire la tabla de enrutamiento del cliente, no el nombre del perfil.

Es el fallo más habitual con clientes de teléfono, que a menudo por defecto solo envían DNS o solo un prefijo. Si falta la ruta, el handshake puede ser perfecto y el dispositivo seguir siendo inalcanzable.

Confirme que la dirección del pool del cliente y la subred de casa no se solapan antes de continuar.

Puerta 2: la puerta de enlace debe reenviar

La VPN termina en un host que debe reenviar el paquete descifrado a la LAN. Eso requiere el reenvío IP activado y una política de cortafuegos que permita el flujo de la interfaz VPN a la interfaz LAN. En un aparato enrutador suele venir integrado; en una máquina Linux con strongSwan o WireGuard son dos ajustes que la gente olvida. Compruebe ambos antes de probar el servicio, porque cualquiera de los dos por sí solo produce el mismo tiempo de espera.

Pruebe con una captura en la interfaz LAN, porque un paquete que nunca aparece allí se descartó o nunca se reenvió.

Es un fallo distinto del de un servicio que rechaza la conexión, y la distinción ahorra mucho tiempo. Mantenga el permiso estrecho, limitado al servicio y al pool de la VPN en lugar de toda la subred.

Puerta 3: la ruta de respuesta lo decide todo

El destino responde a la dirección de origen que vio, que es o bien la dirección del pool del cliente o bien la puerta de enlace, según si traduce. Si la puerta de enlace predeterminada del destino es el enrutador de casa y ese enrutador no tiene ruta hacia el pool de la VPN, la respuesta sale por internet y muere. Es la clásica conexión unidireccional.

Existen dos soluciones legítimas: añadir una ruta para el pool en la puerta de enlace LAN, o hacer source-NAT en la puerta de enlace VPN para que el destino solo vea nunca la dirección de la puerta de enlace. La segunda es más fácil y pierde la identidad original del origen.

Elija una deliberadamente y anote cuál, porque las reglas del cortafuegos y los registros dependen de ello. La guía de reenvío de strongSwan recorre el lado Linux de esa decisión.

Puerta 4: nombres y solapamiento de prefijos

Los nombres de descubrimiento locales no cruzan una frontera enrutada, así que un dispositivo que dentro de la casa aparece con un nombre amigable puede ser invisible por el túnel. Proporcione DNS para la zona privada o documente la dirección. Cualquier nombre que use debe resolverse a algo que el cliente remoto pueda enrutar. Por eso un dispositivo puede ser accesible por dirección e invisible por nombre al mismo tiempo.

Los prefijos solapados son la otra trampa: si el pool del cliente es 192.168.1.0/24 y la red de casa también, el cliente trata el destino como local y nunca lo envía por el túnel.

Renumere un lado, o use un pool de un rango que nunca encontrará en casa.

Puerta 5: pruebe desde fuera de casa

Una prueba desde la cocina no demuestra nada, porque el tráfico puede no salir nunca de la LAN. Conéctese desde un punto de acceso móvil u otra red y recorra las puertas en orden: ruta en el cliente, captura en la interfaz LAN, respuesta del servicio, captura de la respuesta y resolución de nombres. La primera puerta que no produzca pruebas es donde está el trabajo.

Si el servicio responde pero el nombre no, tiene un problema de DNS y no un problema de túnel.

Guarde la configuración que funciona en una nota con el pool, la ruta y la elección de NAT, porque el próximo cambio de enrutador restablecerá las tres cosas.