Comparte una conexión VPN con cada dispositivo de tu LAN

Un portátil sostiene el túnel, el resto de la casa quiere el mismo acceso, y el primer intento es apuntarlo todo a la máquina conectada. Falla por motivos que no tienen nada que ver con la VPN: el host receptor debe reenviar el paquete, reescribir su origen y asegurarse de que las respuestas encuentren el camino de vuelta. Si falta una de las tres, el portátil conectado sigue funcionando mientras todos los demás dispositivos agotan el tiempo. La solución es un diseño de enrutamiento, no un ajuste del cliente.

Por qué falla apuntar los dispositivos al host

Un host que recibe un paquete dirigido a una red remota se convierte en router en ese momento, tanto si alguien lo configuró como tal como si no. El reenvío está desactivado por defecto en Linux y en Windows salvo que alguna función lo active. La traducción importa porque el lado remoto debe saber dónde enviar las respuestas, y una dirección privada de LAN no le dice nada. La ruta de vuelta es la tercera pieza, y es la que la gente olvida cuando el primer ping parece funcionar.

Diagnostica en ese orden en lugar de cambiar ajustes al azar. Cada pieza ausente produce un síntoma algo distinto.

Activa el reenvío y la traducción en el host

Dos cambios en el host conectado cubren las dos primeras piezas: activa el reenvío de IPv4 y traduce el tráfico de la LAN a la interfaz del túnel.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Guarda el valor de sysctl en un archivo bajo /etc/sysctl.d y vuelve a comprobar la regla masquerade tras un reinicio, ya que los frontends de cortafuegos pueden vaciar cadenas personalizadas. En Windows la función de compartición hace los dos pasos, pero también readdresa el adaptador de LAN a una subred fija y borra su puerta de enlace, lo que rompe el direccionamiento estático y la redirección de puertos. Restaura el camino del router hasta el host en su nueva dirección antes de concluir que la compartición falló. Después observa cómo aumentan los contadores de reglas mientras un segundo dispositivo envía tráfico.

Dale a la LAN una ruta que sobreviva a los reinicios

Los demás dispositivos necesitan una ruta hacia el prefijo remoto, y las dos formas de proporcionarla difieren en alcance.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Apuntar la puerta de enlace predeterminada de un cliente al host envía todo su tráfico a través del host, incluida la impresión local y el uso compartido de archivos, así que cosas no relacionadas se detienen cuando el host duerme. Añadir una ruta específica en el router para el prefijo remoto es más estrecho: solo los destinos detrás del túnel van a la máquina conectada, y el resto de la LAN sigue funcionando. Las subredes anteriores son ejemplos, así que sustitúyelas por tus propios rangos de LAN y túnel. En cualquier caso, prueba desde un segundo dispositivo con el túnel activo y luego inactivo.

Vigila la MTU antes de culpar al túnel

Los túneles reducen el tamaño útil del paquete, y el segundo dispositivo no tiene ni idea. Las transferencias grandes y los handshakes TLS se atascan mientras las peticiones pequeñas funcionan.

ping -M do -s 1400 10.8.0.5

Una respuesta demuestra que ese tamaño cruza la ruta sin fragmentar; un tiempo de espera significa que la sobrecarga de encapsulación empujó el paquete más allá de la MTU del túnel. Baja la MTU en la interfaz de compartición o limita el tamaño máximo de segmento en el reenviador, y luego repite la misma prueba. Prueba primero el mismo tamaño en el lado de la LAN, porque un fallo local apunta a la LAN y no al túnel. Anota el tamaño que funciona, ya que un cambio posterior de proveedor o de túnel puede moverlo.

Para un solo dispositivo extra basta con la compartición del host. Para un hogar, pon la ruta en el router. Cuando el acceso debe sobrevivir a que el portátil se vaya contigo, el túnel mismo pertenece a una puerta de enlace dedicada.