Os clientes VPN chegan ao servidor pero non á LAN: que solución?

O cliente fai ping ao enderezo do túnel do servidor OpenVPN e obtén resposta, despois proba un equipo da LAN do servidor e non obtén nada. Esa división acouta moito a avaría: o túnel está ergueito, o reenvío probablemente funciona e a resposta sae por unha porta que non volve. Hai tres solucións, e a correcta depende do que controle e do que estea disposto a ceder. Responda as tres preguntas seguintes en orde e a escolla deixa de ser cuestión de gusto.

Primeiro, confirme que dirección está rota

A petición chega á interface do túnel cun enderezo de orixe do grupo VPN. O servidor reenvíaa ao equipo da LAN, e ese equipo responde á pasarela que indique a súa propia táboa, normalmente o encamiñador da LAN. Se o encamiñador non ten ruta cara ao grupo, a resposta mor alí ou vaga cara a internet.

Probe as dúas máquinas antes de editar unha. Pregunte ao servidor que ruta tomaría a súa táboa cara a un cliente; pregunte ao equipo da LAN como chegaría ao mesmo enderezo. A primeira consulta adoita apuntar ao túnel e a segunda ao encamiñador da LAN, e esa diferenza é a avaría nunha liña. Dúas consultas custan menos que unha auditoría de devasas e fixan a dirección do problema.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Se o equipo da LAN xa apunta ao servidor VPN, o problema é unha regra de devasas ou un límite de MTU, non un camiño de retorno ausente. Non engada unha ruta para arranxar un filtro.

Pregunta un: pode editar o encamiñador da LAN remota?

Cando o encamiñador da LAN é seu, unha ruta estática cara ao grupo VPN co enderezo LAN do servidor VPN como seguinte salto é a resposta limpa. Mantén intactos os enderezos de orixe dos clientes, o que importa cando os equipos da LAN rexistran, filtran ou limitan por enderezo. Tampouco necesita tradución no servidor, así que o túnel segue sendo un camiño puro de encamiñamento. A obriga que crea é documental, porque o grupo, a ruta e a configuración do servidor deben coincidir.

Falla en silencio o día que alguén cambia o grupo. Anote o valor unha vez e trate unha edición en calquera dos tres sitios como unha edición nos tres.

Un NAS ou un conmutador de capa 3 que aloxa o servizo necesita a mesma ruta, agás que o envíe todo por un encamiñador que a teña. Revise o dispositivo que remata a subrede, non só o que mira a internet. As redes pequenas adoitan ter tres aparellos con opinión sobre o encamiñamento.

Pregunta dous: pode a LAN deixar de ver os enderezos dos clientes?

Cando o encamiñador é doutra persoa, traducir no servidor VPN non necesita cooperación. O equipo da LAN ve o enderezo LAN do servidor, respóndelle, e o servidor traduce de volta. Por iso se comportan así os aparellos e os roles de acceso remoto baseados en NAT.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

O custo é a atribución: os enderezos por cliente desaparecen dos rexistros da LAN. Calquera lista de permitidos no equipo da LAN debe entón nomear o servidor en lugar do grupo.

Escolla a tradución cando a cooperación non estea dispoñible, non cando resulte só incómoda. Agocha o cliente de toda investigación futura, tamén das que precisa saber que portátil abriu unha conexión. Tamén pode romper protocolos que incrustan enderezos na carga útil, porque a tradución vive na cabeceira. Ningunha das dúas opcións é máis avanzada; responden preguntas distintas sobre a propiedade.

Pregunta tres: é o servidor mesmo cliente doutro túnel?

Imagine a outra topoloxía: o servidor VPN tamén marca un provedor comercial, así que ten dous túneles e dous conxuntos de enderezos. O tráfico que reenvía para os seus propios clientes sae polo provedor, que non encamiñará as respostas cara aos enderezos do grupo. Por iso desaparecen as respostas aínda que os dous túneles estean sans.

A solución é enmascarar tamén o túnel de saída, para que o provedor só vexa o enderezo do túnel do servidor. A dirección inversa necesita a súa propia regra, porque o servidor que inicia unha conexión cara a un dos seus clientes é un fluxo distinto. Sen esa regra, o cliente responde a un enderezo que non pode encamiñar. Poña a regra estreita antes de calquera enmascaramento amplo para que gañe a tradución específica.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Os equipos con varias interfaces engaden unha avaría relacionada que se ve idéntica desde o cliente. A resposta sae pola interface de métrica máis baixa porque o enderezo de orixe se escolleu noutra táboa. Comprobe o camiño de volta cunha consulta en lugar de supoñer que o de ida o implica.

Despois verifique as dúas direccións e os dous tamaños

Tras o cambio, faga ping do cliente a un equipo da LAN e logo do equipo da LAN ao cliente. A segunda dirección é a que a xente omite, e é a que revela unha regra de tradución incompleta. Anote os dous resultados con marca de tempo para que unha regresión posterior sexa comparable.

Despois mova datos reais, porque un ping pequeno que funciona mentres unha transferencia grande se atasca é un síntoma de MTU. Esa avaría aparece xusto despois de se felicitar por arranxar a ruta.

Por último, probe de novo tras un reinicio. As ordes de ruta e devasas en quente non sobreviven, e unha solución que desaparece no seguinte arranque será diagnosticada outra vez por alguén con menos contexto. Faga o cambio persistente como o seu sistema xa fai, e reinicie unha vez a propósito.