Los clientes del hotspot del Pi no llegan a la LAN de casa por una VPN TUN

Los clientes locales de Wi-Fi y Ethernet se conectan al hotspot del Pi, toman una dirección de su ámbito DHCP y cargan páginas de internet sin queja. Esos mismos clientes luego agotan el tiempo cuando abren un recurso compartido de archivos o una interfaz web en la LAN de casa, mientras que el propio Pi llega a esa LAN por el túnel. Nada en la capa inalámbrica está roto. Lo que falta es un contrato enrutado: el prefijo del hotspot debe llevarse a la interfaz TUN, y algo en el lado de casa debe saber cómo enviar respuestas de vuelta. Ambas mitades deben existir antes de que un solo paquete pueda completar el viaje de ida y vuelta.

Tres conexiones con tres trabajos distintos

Un puente Ethernet de Linux reenvía tramas según la dirección MAC de destino. OpenVPN en modo TUN transporta paquetes IP y no tiene ninguna capa MAC, así que añadir un puente local nunca inscribe el túnel como puerto. La documentación del núcleo sobre TUN/TAP explica esa separación: un dispositivo TAP parece una interfaz Ethernet, uno TUN no. Un diseño que puentea dos puertos locales y luego enruta es un enrutador, digan lo que digan los nombres de las interfaces.

Esa distinción decide la propiedad. La subred de los clientes, su puerta de enlace predeterminada y la autoridad DHCP de ese ámbito pertenecen al plan local del Pi. Las difusiones DHCP de casa no cruzan un túnel enrutado, y ningún ajuste de puente lo cambia; apuntar los clientes a un servidor DHCP de casa es un diseño de relé aparte y deliberado, con sus propios modos de fallo.

Mantén también el módem fuera del puente de clientes. Una conexión PPP no es un dispositivo Ethernet con otra etiqueta, y la lógica documentada de ruta predeterminada de pppd se ejecuta tras la negociación IPCP y retira su ruta cuando ese enlace cae. Copiar una plantilla DHCP y renombrar cada usb0 a ppp0 no demuestra nada sobre puerta de enlace, métrica o ciclo de vida.

Elige los prefijos antes de editar cualquier configuración

Los prefijos solapados gastan más noches que las reglas de cortafuegos, porque un solapamiento envía la búsqueda de ruta a la interfaz equivocada incluso cuando el túnel está sano. Empieza listando lo que ya existe en el Pi y luego lee el resultado como cuatro grupos separados.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

El primer grupo es la dirección underlay que el operador dio al módem; debe quedar fuera de todo plan orientado a clientes. El segundo es la subred del túnel que eligió el servidor, a menudo una /24 privada propia. El tercero es el puente del hotspot, y el cuarto es el prefijo de casa que quieres alcanzar. En este recorrido el hotspot recibe 172.28.90.0/24 con el puente en 172.28.90.1, y la LAN de servicios de casa conserva 192.168.77.0/24, lo que evita las predeterminadas 192.168.1.0/24 y 10.0.0.0/24 que traen los enrutadores de consumo y el rango de operador 100.64.0.0/10.

Anuncia la dirección del puente como puerta de enlace en el ámbito DHCP del hotspot y nada más. Nunca entregues a los clientes del hotspot una dirección de casa como puerta de enlace; no tienen ningún camino a nivel de enlace hacia ese segmento.

Enruta cada dirección en el lado que la posee

El Pi necesita una ruta para el prefijo de casa a través del túnel. Los servidores en modo servidor normalmente empujan esa ruta, así que primero confirma que el reenvío está activo y que el núcleo resuelve una dirección de casa desde tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Si ip route get sigue informando de la interfaz underlay, detente ahí; nada más adelante en el camino puede reparar una búsqueda incorrecta.

Los dispositivos de casa no tienen ruta hacia 172.28.90.0/24, así que sus respuestas siguen la puerta de enlace predeterminada y mueren en el enrutador. Existen dos reparaciones admitidas. O añades una ruta estática en el enrutador de casa que apunte el prefijo del hotspot a la dirección LAN del servidor VPN, o, cuando el servidor es él mismo la puerta de enlace, registras el prefijo del cliente en la tabla de enrutamiento propia del servidor. En el modo multicliente de OpenVPN el directorio específico del cliente lleva esa asociación: un archivo con el nombre común del certificado del cliente, que contiene iroute 172.28.90.0 255.255.255.0 más la línea route correspondiente que la instala en el núcleo del servidor. Una ruta de núcleo supuesta en el servidor no es la misma declaración que decirle al servidor qué cliente posee el prefijo.

No muevas el servicio DHCP de la red de casa al servidor VPN para que esto funcione. Sustituir la puerta de enlace predeterminada de una casa entera es un cambio mucho mayor que añadir una ruta de retorno privada, y arrastra DNS, reservas de direcciones y cada dispositivo que ignora el nuevo arrendamiento hacia el fallo.

Abre el reenvío sin adivinar el cortafuegos

Que el reenvío esté activado no significa que el paquete tenga permiso para pasar. El tráfico del puente al túnel sigue chocando con las reglas de filtrado, y una política de reenvío predeterminada drop descarta el tráfico del hotspot mientras el tráfico propio del Pi sigue funcionando, lo que produce exactamente el síntoma dividido de arriba.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Busca una regla de aceptación de br0 a tun0 y la dirección de respuesta correspondiente, y una regla postrouting que pueda reescribir el origen. Si la política de la cadena es drop y ninguna regla coincide, añade las aceptaciones estrechas y vuelve a probar en lugar de girar la política a accept.

La traducción es una elección de política, no un requisito. El NAT de origen hacia la LAN de casa hace que cada cliente del hotspot parezca la dirección del túnel del Pi, lo que pierde la atribución por cliente en los registros de casa y rompe servicios que esperan el origen original. El enrutamiento sin NAT mantiene visibles las direcciones de los clientes pero depende de la ruta de retorno de arriba. Elige una y trata DNS e IPv6 de la misma forma, porque un camino IPv4 que funciona junto a un camino IPv6 roto sigue leyéndose como medio roto en un navegador.

Verifica el viaje de ida y vuelta y luego rómpelo a propósito

Prueba desde un cliente del hotspot, nunca desde el Pi, porque el tráfico propio del Pi evita tanto el camino de ida como el de vuelta. Observa ambas interfaces mientras un cliente intenta alcanzar un servicio de casa.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Lee las dos capturas juntas. Las peticiones en br0 que nunca aparecen en tun0 significan que el Pi no reenvía o que la ruta apunta a otro sitio. Las peticiones en tun0 sin respuestas significan que el lado de casa no tiene ruta de retorno o que el servidor filtró el paquete. Las respuestas en tun0 que nunca reaparecen en br0 significan que falta la regla de filtrado inversa, donde el túnel parece perfecto y el cliente sigue sin ver nada.

Luego rompe el camino deliberadamente. Baja la conexión del módem y vuelve a subirla y ejecuta de nuevo las comprobaciones de ruta y captura; una ruta que sobrevive al túnel pero desaparece al reconectar pertenece al perfil de conexión, no a un comando puntual. Confirma que el transporte del túnel sigue saliendo por el underlay y no por sí mismo, el bucle clásico cuando se acepta una ruta predeterminada empujada sin una ruta de host hacia el par.

Acepta el diseño solo cuando un cliente del hotspot pueda resolver un nombre de casa, abrir un servicio TCP y mantener una sesión viva durante una reconexión del módem. Si una aplicación requiere de verdad descubrimiento a nivel Ethernet en el segmento de casa, elige un diseño Layer 2 admitido en lugar de describir el puente local como puenteado y esperar a que aparezca la difusión.