Accés a la LAN amb OpenVPN trencat? Comprova zones, rutes i camí de tornada

El túnel informa d'una connexió correcta, la pàgina pròpia del router es carrega, i la unitat de xarxa cap a una màquina del darrere encara caduca. Res d'aquesta combinació no és contradictori: el router respon com a ell mateix, i arribar a qualsevol cosa del darrere és una altra decisió presa en un altre lloc. Feu les comprovacions de sota en ordre i atureu-vos a la primera fallada, perquè cadascuna es recolza en l'anterior. Quan les quatre passen, la fallada és per sobre del túnel, no dins.

Quin filtre veu un paquet destinat a la LAN

Un paquet adreçat al router es consumeix localment; un paquet adreçat a un equip del darrere s'ha de reenviar, i els tallafocs jutgen aquests dos casos per separat. Per tant, el permís per arribar al router no diu res sobre el permís per travessar-lo. El firmware que amaga els seus conjunts de regles encara implementa tots dos, normalment com un selector que ofereix la LAN, internet o tots dos. Si el selector deixa fora la LAN, cap comprovació posterior no importarà.

OpenWrt fa inspeccionable aquesta divisió, i la distinció val una lectura. La zona que acaba el túnel necessita una regla de reenviament cap a la zona LAN, mentre que una regla d'entrada només regeix els serveis del propi router. Una pàgina d'administració que funciona al costat d'una LAN morta és el resultat habitual d'aquesta regla de reenviament absent.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Mireu l'objectiu de reenviament de la zona que porta el túnel: accept és el que necessita l'escala, i reject explica cada temps d'espera de sota. Dues opcions veïnes produeixen el mateix símptoma, així que descarteu-les mentre sou aquí. L'aïllament sense fil amaga els equips cablejats dels clients sense fil, i un router que tracta els equips LAN inactius com a fora de línia pot descartar les respostes fins i tot després que el reenviament funcioni.

Per què un túnel dividit necessita el prefix empès

Un client que envia tot el trànsit pel túnel ja té el prefix LAN per la seva ruta per defecte, així que no cal afegir res. El túnel dividit és el cas que necessita el prefix declarat explícitament, perquè res més a la configuració no el menciona. Afegiu la directiva a la configuració del servidor i recarregueu el servei.

push "route 192.168.50.0 255.255.255.0"

Els perfils que contenen route-nopull ignoren les rutes empeses, així que el mateix prefix pertany al fitxer del client. En qualsevol cas, confirmeu que l'entrada ha arribat en lloc de suposar-ho, perquè una substitució silenciosa sembla idèntica a un problema de tallafocs.

ip route show | grep 192.168.50

Un parell de lloc a lloc demana més que una empenta. El servidor ha d'aprendre quins prefixos hi ha darrere d'aquest parell, cosa que fa una línia iroute al seu fitxer client-config-dir, i la seva pròpia taula necessita una ruta coincident cap al túnel.

La resposta necessita una adreça a la qual pugui arribar

Reenviar la petició és només la meitat d'un intercanvi, perquè l'equip LAN ha de respondre a una adreça del conjunt del túnel. Els routers petits solen arreglar-ho traduint l'origen a la zona del túnel, de manera que la resposta s'adreça al router i no necessita configuració enlloc més. Traieu aquesta traducció i l'equip necessita la seva pròpia ruta cap al conjunt, que obté gratis quan el router és la seva passarel·la per defecte. Un equip amb adreça fixada a mà i una altra passarel·la respon per aquesta passarel·la, i el client veu com la sessió s'obre i després s'encalla.

tcpdump -ni tun0 host 192.168.50.20

Executeu-ho al router mentre el client repeteix la petició, i llegiu la destinació de la resposta, no la petició. Una resposta adreçada al conjunt significa que el camí de tornada funciona i que la fallada és més endins. Cap resposta significa que l'equip mai va acceptar el paquet, cosa que us torna al conjunt de regles.

Una escala que acaba al lloc correcte

Quatre comprovacions localitzen la capa, i cadascuna és una sola ordre en lloc d'un judici. Executeu-les en ordre i atureu-vos a la primera fallada. L'ordre importa més que les ordres, perquè un pas posterior que passa amaga la raó per la qual un d'anterior va fallar.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Els noms van al final de l'escala, mai al començament. Un recurs compartit que respon com a 192.168.50.20 però no com a nas.local apunta a la resolució o a un sufix de cerca, i les edicions del tallafocs no poden canviar cap de les dues.

Anoteu el primer pas fallit i després doneu als ports de servei la seva pròpia passada, perquè un oient i un permís d'equip són requisits separats. Compartir fitxers, escriptori remot i fluxos de càmera necessiten tots dos, i un tallafocs de l'equip que confia en la subxarxa LAN però no en el conjunt del túnel descarta el client mentre el ping encara funciona. Quan totes les comprovacions passen i l'aplicació encara falla, la fallada és per sobre del túnel: un servei lligat a una interfície o un proxy configurat al client.