Acceso á LAN con OpenVPN roto? Comproba zonas, rutas e camiño de volta

O túnel informa dunha conexión correcta, a páxina do propio router carga, e a unidade de rede cara a unha máquina detrás del segue esgotando o tempo. Nada desa combinación é contradictorio: o router responde como el mesmo, e chegar a algo detrás é outra decisión tomada noutro lugar. Segue as comprobacións de abaixo en orde e detente no primeiro fallo, porque cada unha se apoia na anterior. Cando as catro pasan, o fallo está por riba do túnel e non dentro.

Que filtro ve un paquete destinado á LAN

Un paquete dirixido ao router consómese localmente; un paquete dirixido a un host detrás del debe reenviarse, e os cortalumes xulgan eses dous casos por separado. Polo tanto, o permiso para chegar ao router non di nada sobre o permiso para cruzalo. O firmware que oculta os seus conxuntos de regras segue implementando ambos, normalmente como un selector que ofrece a LAN, internet ou ambos. Se o selector deixa fóra a LAN, ningunha comprobación posterior importará.

OpenWrt fai inspeccionable esa división, e a distinción merece unha lectura. A zona que remata o túnel necesita unha regra de reenvío cara á zona LAN, mentres que unha regra de entrada só goberna servizos do propio router. Unha páxina de administración que funciona xunto a unha LAN morta é o resultado habitual desa regra de reenvío ausente.

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

Mira o destino de reenvío da zona que leva o túnel: accept é o que necesita a escaleira, e reject explica cada tempo de espera de abaixo. Dous axustes veciños producen o mesmo síntoma, así que descártaos mentres estás aquí. O illamento sen fíos oculta os hosts con cable aos clientes sen fíos, e un router que trata os hosts LAN inactivos como desconectados pode descartar as respostas mesmo despois de que o reenvío funcione.

Por que un túnel dividido necesita o prefixo empurrado

Un cliente que envía todo o tráfico polo túnel xa ten o prefixo LAN mediante a súa ruta por defecto, así que non hai nada que engadir. O túnel dividido é o caso que necesita o prefixo declarado explicitamente, porque nada máis na configuración o menciona. Engade a directiva á configuración do servidor e recarga o servizo.

push "route 192.168.50.0 255.255.255.0"

Os perfís que conteñen route-nopull ignoran as rutas empurradas, así que o mesmo prefixo pertence ao ficheiro do cliente. En calquera caso, confirma que a entrada chegou en lugar de supoñelo, porque unha substitución silenciosa parece idéntica a un problema de cortalumes.

ip route show | grep 192.168.50

Un par de sitio a sitio pide máis que un empurrón. O servidor debe aprender que prefixos hai detrás dese par, o que fai unha liña iroute no seu ficheiro client-config-dir, e a súa propia táboa necesita unha ruta coincidente cara ao túnel.

A resposta necesita un enderezo ao que poida chegar

Reenviar a petición é só a metade dun intercambio, porque o host da LAN debe responder a un enderezo do conxunto do túnel. Os routers pequenos adoitan arranxalo traducindo a orixe na zona do túnel, de modo que a resposta se dirixe ao router e non necesita configuración noutro sitio. Quita esa tradución e o host necesita a súa propia ruta ao conxunto, que obtén de balde cando o router é a súa porta de enlace predeterminada. Un host con enderezo fixado a man e outra porta de enlace responde por esa porta, e o cliente ve abrirse unha sesión e despois atascarse.

tcpdump -ni tun0 host 192.168.50.20

Executa iso no router mentres o cliente repite a petición, e le o destino da resposta en lugar da petición. Unha resposta dirixida ao conxunto significa que o camiño de volta funciona e que o fallo está máis dentro. Ningunha resposta significa que o host nunca aceptou o paquete, o que te devolve ao conxunto de regras.

Unha escaleira que remata no sitio correcto

Catro comprobacións localizan a capa, e cada unha é un só comando en lugar dun xuízo. Execútaas en orde e detente no primeiro fallo. A orde importa máis que os comandos, porque un paso posterior que pasa oculta a razón pola que fallou un anterior.

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

Os nomes van ao final da escaleira, nunca ao principio. Un recurso compartido que responde como 192.168.50.20 pero non como nas.local apunta á resolución ou a un sufixo de busca, e as edicións do cortalumes non poden cambiar ningún dos dous.

Anota o primeiro paso fallido e despois dálle aos portos de servizo a súa propia pasada, porque un oínte e un permiso de host son requisitos separados. Compartir ficheiros, escritorio remoto e fluxos de cámara necesitan ambos, e un cortalumes do host que confía na subrede LAN pero non no conxunto do túnel descarta o cliente mentres o ping aínda funciona. Cando todas as comprobacións pasan e a aplicación segue fallando, o fallo está por riba do túnel: un servizo ligado a unha interface ou un proxy configurado no cliente.