¿Puede un cliente VPN itinerante alojar un servicio para la oficina?

El portátil de la oficina puede conectarse desde casa y aun así ofrecer algo que la oficina necesita, pero solo cuando coinciden tres decisiones separadas. El túnel es transporte, la dirección interna es el destino y la política decide quién puede llamar. Tratar cualquiera de ellas como la respuesta completa produce la queja conocida: el host responde a los pings pero la aplicación nunca se conecta. Los papeles no son iguales, y la diferencia está exactamente donde vive el trabajo de diseño.

La dirección de la conexión no dice nada sobre la dirección del servicio

Cuando un cliente inicia un túnel, abre un camino que ambas direcciones pueden usar una vez que existe. Si una conexión nueva puede entrar desde el concentrador hacia ese cliente es una cuestión de política de la puerta de enlace, no una propiedad de quien se conectó. En un concentrador OpenVPN enrutado, por ejemplo, el servidor necesita una ruta hacia la dirección interna del cliente y un reenvío que permita la relación entre pares.

Imagina un sistema de inventario que consulta a un agente en portátiles itinerantes, o a un desarrollador que necesita una API de prueba desde una estación de trabajo en casa. Ambos quieren que el lado de la oficina inicie la conversación, que es lo contrario del patrón habitual cliente-servidor.

Los productos de acceso remoto alojados varían en este punto, y la variación no es un error. Algunas VPN de servicio gestionado bloquean deliberadamente las conexiones no solicitadas hacia los clientes conectados porque su modelo es cliente-a-recurso, no recurso-a-cliente. Lee la arquitectura documentada del producto antes de prometer a un colega que su portátil puede actuar como servidor.

Sigue el camino de vuelta antes de abrir un puerto

El camino tiene tres partes: una ruta en la puerta de enlace que apunta a la dirección interna del cliente, una política que permite al solicitante concreto y un servicio que escucha en el objetivo. Cada parte falla de forma distinta, por eso «la VPN está activa» casi no dice nada.

La buena noticia es que el camino interno no necesita una redirección de puerto en el router de casa del cliente. Ese es el sentido de publicar el servicio en la dirección del túnel en lugar de la dirección WAN de casa, donde la exposición y las reglas NAT serían completamente distintas. Un router doméstico también puede negarse a hacer hairpin de una conexión que llega de la oficina, así que la ruta WAN falla por motivos ajenos a tu VPN. Mantener el tráfico dentro del túnel evita ambos problemas a la vez.

Comprueba también el lado del objetivo. Un servicio vinculado solo a 127.0.0.1 no puede aceptar una conexión que llegue por la interfaz del túnel, por correctas que sean las rutas de la puerta de enlace. Una regla de cortafuegos del host que permita el puerto solo desde la subred local también descartará el tráfico de la oficina, y esa regla es independiente de la política VPN que hay encima.

Los nombres y las direcciones son decisiones de diseño

Una dirección dentro del túnel no es automáticamente un nombre. Un registro DNS privado que controlas es más claro que esperar que un protocolo de descubrimiento cruce el túnel, porque la resolución de nombres por multicast de enlace local se queda en el segmento local y no se convierte en DNS entre subredes.

La estabilidad de la dirección importa igual. Si los clientes VPN toman direcciones de un grupo con concesiones cortas, la dirección interna del portátil cambia entre sesiones y cada marcador, ámbito de cortafuegos y comprobación de monitorización construidos sobre ella se rompen en silencio. Usa una reserva o una ruta documentada de actualización dinámica.

Acuerda el nombre con quien posee la identidad VPN, para que el registro, la asignación de dirección y la política de acceso cambien juntos en lugar de en tres tiques separados.

Prueba el servicio, no la pertenencia

Desde el objetivo, confirma qué escucha y en qué dirección, y después confirma la visión de la puerta de enlace del camino de vuelta:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Ahora prueba desde el lado de la oficina con una petición real en lugar de un eco. Un curl correcto contra el servicio demuestra la ruta, la política y el oyente a la vez, mientras que un ping correcto solo demuestra que se permite ICMP. Si la petición falla, retrocede por las tres partes en lugar de ampliar el cortafuegos y esperar.

La disponibilidad pertenece a la misma conversación. Un portátil duerme, itinerante entre redes y se desconecta al final del día. Un servicio que debe responder a cualquier hora pertenece a un host siempre encendido, mientras que un servicio de mejor esfuerzo puede quedarse en el cliente con esa limitación escrita.

Publica el recurso deliberadamente, con un nombre, una lista de solicitantes permitidos y un propietario, y el dispositivo remoto se convierte en un servicio compatible en lugar de un servidor accidental.