Cliente OpenVPN para toda la LAN en OpenWrt: un orden que funciona

Cuatro tareas independientes ponen toda la LAN de un router detrás de un solo túnel. El dispositivo del túnel necesita un propietario, una zona de cortafuegos, un destino de traducción hacia el enlace ascendente y, si algunos clientes deben quedarse fuera de la VPN, enrutamiento por dirección de origen. A un túnel que conecta mientras nada pasa suele faltarle una de esas cuatro cosas. Trabajar en orden de dependencia significa que un fallo al final pertenece al paso que acaba de cambiar. Cada paso de abajo termina en algo que puede observar, y eso evita que el siguiente sea una conjetura.

Decida qué comparte el túnel

El router que reparte Wi-Fi y DHCP puede ejecutar el cliente por sí mismo. Eso pone cada dispositivo conectado detrás del túnel sin configuración por dispositivo, y es la disposición que quieren la mayoría de los sitios pequeños. También es la de mayor alcance cuando el túnel cae, porque todos los dispositivos pierden su ruta a la vez. Nada en la LAN conserva una ruta de salida que funcione.

Un segundo router detrás del primero, que ejecuta el cliente con su propia subred, limita el túnel a sus propios dispositivos. Es más fácil de quitar y más fácil de explicar a quien lo herede. El coste es la accesibilidad entre ambos lados sin una ruta ni una redirección de puerto.

En cualquier caso, haga las subredes de la LAN distintas. Los rangos idénticos hacen que un lado parezca conectado directamente, y el agujero negro resultante se lee como una avería de la VPN durante horas.

Dé un propietario al túnel

Declare el túnel como una interfaz de red con un nombre, un dispositivo y ningún protocolo propio. El sistema de red entonces crea y gestiona el dispositivo, y todo lo posterior se refiere a la interfaz por nombre en lugar de por dispositivo. Eso es lo que permite que la zona lo encuentre.

No cree el mismo dispositivo en dos sitios. Un túnel hecho a mano junto a una interfaz declarada produce un dispositivo que existe pero no está en ninguna zona, o uno que desaparece al recargar. Ambos parecen un fallo del cliente, y ninguno produce un error que nombre la causa real. Elija la vía declarativa y borre la manual.

Mantenga el nombre idéntico en la configuración de red, cortafuegos y VPN. La zona lista las redes por nombre, así que una errata deja el túnel fuera de toda zona mientras la interfaz parece sana. Una interfaz sana sin política es el estado más difícil de detectar.

Póngalo en una zona y luego reenvíe hacia ella

Una zona de cortafuegos es donde vive la política: input, output, forward y masquerade. Un túnel que no está en ninguna zona se rige por valores predeterminados que usted no eligió, y eso rara vez es lo que necesita un cliente de router. Los bloques de abajo declaran la interfaz, la colocan en una zona y permiten que el tráfico de la LAN entre en esa zona.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

En versiones anteriores a la 21.02 la misma línea de interfaz se escribe option ifname, así que compruebe qué forma analiza el firmware instalado antes de pegar. El bloque de reenvío es el permiso que deja que el tráfico de la LAN use el túnel. Sin él, el dispositivo está arriba, el cliente conectado y ningún equipo de la LAN llega al túnel. Ese es el informe más habitual de conectado pero sin internet en clientes de router.

El masquerade en la zona de la VPN colapsa cada dirección de la LAN en la dirección del túnel del router antes de que el paquete salga. Eso elimina la necesidad de una ruta de vuelta a su subred en el lado remoto.

Si el lado remoto ya enruta su LAN, desactivar el masquerade mantiene visibles las direcciones de origen y hace significativos los registros por cliente. Elija uno y anote cuál, porque las dos opciones producen más adelante preguntas de soporte distintas. Quitar el reenvío predeterminado de LAN a WAN es una decisión aparte con su propia consecuencia. Quítelo y el acceso a internet del propio router se va con él.

Nombre el enlace ascendente real en NAT

En firmware donde la regla de traducción está escrita a mano, el campo que falla es la interfaz de salida. Una regla que nombra vlan2 no hace nada cuando la sesión termina en ppp0. Una regla sin ninguna interfaz puede traducir tráfico que debería haber quedado privado. Ninguno de los dos errores se anuncia, porque el túnel sigue funcionando.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Sustituya ppp0 en esa regla por la interfaz de ip route o de la lista de interfaces en ejecución, y luego mire el contador mientras un equipo de la LAN carga una página. En un router de un solo proveedor, una regla de masquerade para el enlace ascendente suele bastar. Una segunda regla para la interfaz del túnel no sustituye a la primera.

Después añada las opciones del cliente que deciden qué entra en el túnel. Una directiva redirect-gateway envía el tráfico de internet del cliente por la VPN, y sin ella el túnel solo lleva las rutas que empuja el servidor. Compruebe la tabla de rutas resultante antes de tocar el DNS.

Divida el Wi-Fi con una segunda tabla

Una tabla de rutas no puede tener dos valores predeterminados. Por eso un segundo SSID que debe saltarse el túnel necesita su propia subred y su propia tabla. Asigne al SSID tunelizado su propio rango y luego enrute solo ese rango hacia el túnel con una regla que seleccione la tabla.

Los paquetes de enrutamiento por políticas de OpenWrt expresan exactamente esa combinación. Hacerlo a mano también funciona, con una regla de origen y una tabla cuyo valor predeterminado apunta al dispositivo del túnel.

Compruebe la división desde las dos redes. Un cliente en el SSID tunelizado debe mostrar la dirección de salida de la VPN, y un cliente en el SSID normal la del proveedor. Cuando ambos parecen iguales, la regla coincide con el origen equivocado o la tabla nunca se consulta. Pruebe también tras reconectar, porque una regla que depende del nombre de la interfaz se rompe cuando el dispositivo se renumera.

Sospeche del reloj y del flag del dispositivo

El flag persist-tun deja el dispositivo del túnel en su sitio entre reinicios. Eso conviene a un servidor y confunde a un cliente cuyo estado debería reconstruirse desde cero. Quítelo mientras diagnostica un cliente de router, porque un dispositivo que sobrevive a una negociación fallida oculta qué paso se rompió en realidad. Vuelva a ponerlo cuando el cliente conecte de forma fiable, y no antes.

El reloj es el otro fallo silencioso. Un router sin reloj con batería empieza en la época, lo que hace que las comprobaciones de certificado fallen hasta que NTP se ponga al día. Compare las marcas de tiempo del registro con la hora real antes de tocar un certificado, porque un cliente que conecta un minuto después del arranque suele estar esperando la sincronización de la hora.