Cliente OpenVPN para toda a LAN en OpenWrt: a orde que funciona

Catro traballos independentes poñen toda a LAN dun router detrás dun só túnel. O dispositivo do túnel necesita un propietario, unha zona de firewall, un destino de tradución cara ao uplink e, se algúns clientes deben quedar fóra da VPN, encamiñamento por enderezo de orixe. Un túnel que conecta mentres non pasa nada adoita ter un deses catro elementos fóra. Traballar en orde de dependencia significa que un fallo ao final pertence ao paso que acabas de cambiar. Cada paso de abaixo remata con algo que podes observar, o que evita que o seguinte sexa unha suposición.

Decide que comparte o túnel

O router que reparte Wi-Fi e DHCP pode executar o cliente el mesmo. Iso pon cada dispositivo conectado detrás do túnel sen configuración por dispositivo, e é a disposición que queren a maioría dos sitios pequenos. É tamén a que ten o maior radio de impacto cando cae o túnel, porque cada dispositivo perde a súa ruta á vez. Nada na LAN conserva unha saída que funcione.

Un segundo router detrás do primeiro, executando o cliente coa súa propia subrede, limita o túnel aos seus propios dispositivos. É máis doado de retirar e máis doado de explicar a quen o herde. O custo é a alcanzabilidade entre os dous lados sen unha ruta nin unha redirección de porto.

De calquera xeito, fai distintas as subredes da LAN. Os rangos idénticos fan que un lado pareza conectado directamente, e o burato negro resultante parece unha avaría da VPN durante horas.

Dálle un propietario ao túnel

Declara o túnel como unha interface de rede cun nome, un dispositivo e ningún protocolo propio. O sistema de rede crea e xestiona entón o dispositivo, e todo o que está por debaixo refírese á interface polo nome e non polo dispositivo. Iso é o que lle permite á zona atopala.

Non crees o mesmo dispositivo en dous sitios. Un túnel feito á man xunto a unha interface declarada produce un dispositivo que existe pero non está nunha zona, ou un que desaparece ao recargar. Ambos parecen un fallo do cliente, e ningún produce un erro que nomee a causa real. Escolle o camiño declarativo e borra o manual.

Mantén o nome idéntico na configuración de rede, firewall e VPN. A zona lista as redes por nome, así que un erro de mecanografía deixa o túnel fóra de todas as zonas mentres a interface parece sa. Unha interface sa sen política é o estado máis difícil de detectar.

Ponlle zona e logo encamiña cara a ela

Unha zona de firewall é onde vive a política: entrada, saída, reenvío e masquerade. Un túnel que non está en ningunha zona réxese por valores por defecto que non escolliches, o que raramente é o que necesita un cliente de router. Os bloques de abaixo declaran a interface, sitúana nunha zona e permiten o tráfico da LAN cara a 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'

Nas versións anteriores a 21.02 a mesma liña de interface escríbese como option ifname, así que comproba que forma analiza o firmware instalado antes de pegar. O bloque de reenvío é o permiso que permite que o tráfico da LAN use o túnel. Sen el o dispositivo está activo, o cliente está conectado e ningún equipo da LAN chega ao túnel. Esa é a comunicación máis común de conectado pero sen internet nos clientes de router.

O masquerade na zona VPN colapsa cada enderezo da LAN no enderezo do túnel do router antes de que o paquete saia. Iso elimina a necesidade dunha ruta de retorno á túa subrede no outro lado.

Se o outro lado xa encamiña a túa LAN, desactivar o masquerade mantén visibles os enderezos de orixe e fai que os rexistros por cliente teñan sentido. Escolle unha opción e anota cal, porque as dúas escollas producen máis adiante preguntas de soporte distintas. Retirar o reenvío por defecto de LAN a WAN é unha decisión aparte coa súa propia consecuencia. Quítalo e o propio acceso a internet do router vaise con el.

Nomea o uplink real no NAT

Nos firmware onde a regra de tradución está escrita á man, a interface de saída é o campo que falla. Unha regra que nomea vlan2 non fai nada cando a sesión termina en ppp0. Unha regra sen ningunha interface pode traducir tráfico que debería ter quedado privado. Ningún dos dous erros se anuncia, porque o túnel segue funcionando.

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

Substitúe ppp0 nesa regra pola interface de ip route ou pola lista de interfaces activas, e despois observa o contador mentres un equipo da LAN carga unha páxina. Nun router cun só provedor, unha regra de masquerade para o uplink adoita abondar. Unha segunda regra para a interface do túnel non substitúe a primeira.

Despois engade as opcións do cliente que deciden que entra no túnel. Unha directiva redirect-gateway envía o tráfico de internet do cliente pola VPN, e sen ela o túnel só leva as rutas que empuxa o servidor. Comproba a táboa de rutas resultante antes de tocar o DNS.

Divide o Wi-Fi cunha segunda táboa

Unha táboa de rutas non pode levar dous destinos por defecto. Un segundo SSID que debe saltar o túnel precisa por iso a súa propia subrede e a súa propia táboa. Asigna ao SSID tunelizado o seu propio rango e logo encamiña só ese rango cara ao túnel cunha regra que selecciona a táboa.

Os paquetes de encamiñamento por políticas en OpenWrt expresan exactamente esa combinación. Facelo á man tamén funciona, cunha regra por orixe e unha táboa cuxo destino por defecto apunta ao dispositivo do túnel.

Comproba a división desde as dúas redes. Un cliente no SSID tunelizado debería presentar o enderezo de saída da VPN, e un cliente no SSID normal debería presentar o do provedor. Cando ambos parecen iguais, a regra coincide coa orixe incorrecta ou a táboa nunca se consulta. Proba tamén despois dunha reconexión, porque unha regra que depende do nome da interface rompe cando o dispositivo se renumera.

Sospeta do reloxo e da opción do dispositivo

A opción persist-tun mantén o dispositivo do túnel no seu sitio entre reinicios. Iso vai ben a un servidor e confunde a un cliente cuxo estado debería reconstruírse desde cero. Quítaa mentres diagnostiques un cliente de router, porque un dispositivo que sobrevive a unha negociación fallida agocha que paso se rompeu de verdade. Vólvea poñer cando o cliente se conecte de forma fiable, e non antes.

O reloxo é o outro fallo silencioso. Un router sen reloxo con batería arrinca na época, o que significa que as comprobacións de certificado fallan ata que NTP se pon ao día. Compara as marcas de tempo do rexistro coa hora real antes de tocar un certificado, porque un cliente que conecta un minuto despois do arranque adoita estar agardando pola sincronización horaria.