Client OpenVPN per a tota la LAN a OpenWrt: un ordre que funciona

Quatre feines independents posen tota la LAN d’un router darrere d’un sol túnel. El dispositiu del túnel necessita un propietari, una zona de tallafoc, un objectiu de traducció cap a l’enllaç ascendent i, si alguns clients han de quedar fora de la VPN, encaminament per adreça d’origen. Un túnel que connecta mentre no hi passa res normalment té un d’aquests quatre elements a faltar. Treballar en ordre de dependència vol dir que una fallada al final pertany al pas que acabeu de canviar. Cada pas d’aquí sota acaba en una cosa que podeu observar, i això evita que el següent sigui una conjectura.

Decidiu què comparteix el túnel

El router que reparteix Wi-Fi i DHCP pot executar el client ell mateix. Això posa cada dispositiu connectat darrere del túnel sense cap configuració per dispositiu, i és la disposició que volen la majoria de llocs petits. També és la que té l’abast més ampli quan el túnel cau, perquè cada dispositiu perd el seu camí alhora. Res a la LAN no conserva una ruta de sortida que funcioni.

Un segon router darrere del primer, que executa el client amb la seva pròpia subxarxa, limita el túnel als seus propis dispositius. És més fàcil de treure i més fàcil d’explicar a qui l’hereti. El cost és l’abast entre els dos costats sense una ruta ni una redirecció de port.

De qualsevol manera, feu les subxarxes de la LAN diferents. Els rangs idèntics fan que un costat sembli connectat directament, i el forat negre que en resulta sembla una avaria de la VPN durant hores.

Doneu un propietari al túnel

Declareu el túnel com una interfície de xarxa amb un nom, un dispositiu i cap protocol propi. Llavors el sistema de xarxa crea i gestiona el dispositiu, i tot el que hi ha més avall es refereix a la interfície pel nom, no pel dispositiu. Això és el que permet que la zona el trobi.

No creeu el mateix dispositiu en dos llocs. Un túnel fet a mà al costat d’una interfície declarada produeix un dispositiu que existeix però no és a cap zona, o un que desapareix en recarregar. Tots dos semblen un client fallit, i cap dels dos no genera cap error que anomeni la causa real. Trieu el camí declaratiu i esborreu el manual.

Mantingueu el nom idèntic a la configuració de xarxa, tallafoc i VPN. La zona llista les xarxes pel nom, així que una errata deixa el túnel fora de totes les zones mentre la interfície sembla sana. Una interfície sana sense política és l’estat més difícil de detectar.

Poseu-lo en una zona i després encamineu-hi

Una zona de tallafoc és on viu la política: input, output, forward i masquerade. Un túnel que no és a cap zona es regeix per valors per defecte que no heu triat, cosa que poques vegades és el que necessita un client de router. Els blocs de sota declaren la interfície, la posen en una zona i permeten que el trànsit de la LAN entri en aquesta 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 versions anteriors a la 21.02 la mateixa línia d’interfície s’escriu option ifname, així que comproveu quina forma analitza el firmware instal·lat abans d’enganxar. El bloc de reenviament és el permís que permet que el trànsit de la LAN faci servir el túnel. Sense això, el dispositiu està aixecat, el client connectat i cap host de la LAN arriba al túnel. Aquest és l’informe més habitual de connectat però sense internet en clients de router.

El masquerade a la zona de la VPN col·lapsa cada adreça de la LAN en l’adreça del túnel del router abans que el paquet surti. Això elimina la necessitat d’una ruta de tornada a la vostra subxarxa a l’altre costat.

Si l’altre costat ja encamina la vostra LAN, desactivar el masquerade manté visibles les adreces d’origen i fa que els registres per client tinguin sentit. Trieu-ne un i anoteu quin, perquè les dues opcions generen preguntes de suport diferents més endavant. Treure el reenviament per defecte de LAN a WAN és una decisió separada amb la seva pròpia conseqüència. Traieu-lo i l’accés a internet del propi router se’n va amb ell.

Anomeneu l’enllaç ascendent real al NAT

En firmware on la regla de traducció s’escriu a mà, el camp que falla és la interfície de sortida. Una regla que anomena vlan2 no fa res quan la sessió acaba a ppp0. Una regla sense cap interfície pot traduir trànsit que hauria d’haver quedat privat. Cap dels dos errors no s’anuncia, perquè el túnel continua funcionant.

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

Substituïu ppp0 d’aquesta regla per la interfície de ip route o de la llista d’interfícies en execució, i després mireu el comptador mentre un host de la LAN carrega una pàgina. En un router d’un sol proveïdor, una regla de masquerade per a l’enllaç ascendent normalment n’hi ha prou. Una segona regla per a la interfície del túnel no substitueix la primera.

Després afegiu les opcions del client que decideixen què entra al túnel. Una directiva redirect-gateway envia el trànsit d’internet del client per la VPN, i sense això el túnel només porta les rutes que empeny el servidor. Comproveu la taula d’encaminament resultant abans de tocar el DNS.

Partiu el Wi-Fi amb una segona taula

Una taula d’encaminament no pot tenir dos valors per defecte. Per tant, un segon SSID que ha de saltar-se el túnel necessita la seva pròpia subxarxa i la seva pròpia taula. Assigneu a l’SSID tunelitzat el seu propi rang i després encamineu només aquell rang cap al túnel amb una regla que seleccioni la taula.

Els paquets d’encaminament per política d’OpenWrt expressen exactament aquesta combinació. Fer-ho a mà també funciona, amb una regla d’origen i una taula el valor per defecte de la qual apunta al dispositiu del túnel.

Comproveu la partició des de les dues xarxes. Un client a l’SSID tunelitzat ha de mostrar l’adreça de sortida de la VPN, i un client a l’SSID normal ha de mostrar la del proveïdor. Quan tots dos semblen iguals, la regla coincideix amb l’origen equivocat o la taula no es consulta mai. Proveu-ho també després de reconnectar, perquè una regla que depèn del nom de la interfície es trenca quan el dispositiu es renumera.

Sospiteu del rellotge i del flag del dispositiu

El flag persist-tun deixa el dispositiu del túnel al seu lloc entre reinicis. Això convé a un servidor i confon un client l’estat del qual s’hauria de reconstruir des de zero. Traieu-lo mentre diagnostiqueu un client de router, perquè un dispositiu que sobreviu a una negociació fallida amaga quin pas s’ha trencat realment. Torneu-lo a posar quan el client connecti de manera fiable, i no abans.

El rellotge és l’altra fallada silenciosa. Un router sense rellotge amb bateria comença a l’època, cosa que fa que les comprovacions de certificat fallin fins que el NTP s’actualitzi. Compareu les marques de temps del registre amb l’hora real abans de tocar un certificat, perquè un client que connecta un minut després de l’arrencada normalment espera la sincronització de l’hora.