Los clientes VPN llegan al servidor pero no a la LAN: ¿qué solución?

El cliente hace ping a la dirección del túnel del servidor OpenVPN y obtiene respuesta, luego prueba un equipo de la LAN del servidor y no obtiene nada. Esa división acota mucho la avería: el túnel está arriba, el reenvío probablemente funciona y la respuesta sale por una puerta que no vuelve. Hay tres soluciones, y la correcta depende de lo que usted controle y de lo que esté dispuesto a ceder. Responda las tres preguntas siguientes en orden y la elección deja de ser cuestión de gusto.

Primero, confirmar qué dirección está rota

La petición llega a la interfaz del túnel con una dirección de origen del grupo VPN. El servidor la reenvía al equipo de la LAN, y ese equipo responde a la puerta de enlace que indique su propia tabla, normalmente el router de la LAN. Si el router no tiene ruta hacia el grupo, la respuesta muere allí o vaga hacia internet.

Pruebe ambas máquinas antes de editar una sola. Pregunte al servidor qué ruta tomaría su tabla hacia un cliente; pregunte al equipo de la LAN cómo llegaría a la misma dirección. La primera consulta suele apuntar al túnel y la segunda al router de la LAN, y esa diferencia es la avería en una línea. Dos consultas cuestan menos que una auditoría de cortafuegos y fijan la dirección del problema.

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

Si el equipo de la LAN ya apunta al servidor VPN, su problema es una regla de cortafuegos o un límite de MTU y no una ruta de retorno ausente. No añada una ruta para arreglar un filtro.

Pregunta uno: ¿puede editar el router de la LAN remota?

Cuando el router de la LAN es suyo, una ruta estática hacia el grupo VPN con la dirección LAN del servidor VPN como siguiente salto es la respuesta limpia. Mantiene intactas las direcciones de origen de los clientes, lo que importa cuando los equipos de la LAN registran, filtran o limitan por dirección. Tampoco necesita traducción en el servidor, así que el túnel sigue siendo una ruta pura. La obligación que crea es documental, porque el grupo, la ruta y la configuración del servidor deben coincidir.

Falla en silencio el día en que alguien cambia el grupo. Anote el valor una vez y trate una edición en cualquiera de los tres sitios como una edición en los tres.

Un NAS o un conmutador de capa 3 que aloja el servicio necesita la misma ruta, salvo que envíe todo por un router que la tenga. Revise el dispositivo que termina la subred, no solo el que mira a internet. Las redes pequeñas suelen tener tres aparatos con opinión sobre el enrutamiento.

Pregunta dos: ¿puede la LAN dejar de ver las direcciones de los clientes?

Cuando el router es de otra persona, traducir en el servidor VPN no necesita cooperación. El equipo de la LAN ve la dirección LAN del servidor, le responde y el servidor traduce de vuelta. Por eso se comportan así los appliances y los roles de acceso remoto basados en NAT.

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

El coste es la atribución: las direcciones por cliente desaparecen de los registros de la LAN. Cualquier lista de permitidos en el equipo de la LAN debe entonces nombrar al servidor en lugar del grupo.

Elija la traducción cuando la cooperación no esté disponible, no cuando resulte meramente incómoda. Esconde al cliente de toda investigación futura, incluidas aquellas en las que necesita saber qué portátil abrió una conexión. También puede romper protocolos que incrustan direcciones en la carga útil, porque la traducción vive en la cabecera. Ninguna opción es más avanzada; responden a preguntas distintas sobre la propiedad.

Pregunta tres: ¿es el propio servidor cliente de otro túnel?

Imagine la otra topología: el servidor VPN también marca a un proveedor comercial, así que tiene dos túneles y dos conjuntos de direcciones. El tráfico que reenvía para sus propios clientes sale por el proveedor, que no encaminará las respuestas de vuelta a las direcciones del grupo. Por eso desaparecen las respuestas aunque ambos túneles estén sanos.

La solución es enmascarar también el túnel saliente, para que el proveedor solo vea la dirección del túnel del servidor. La dirección inversa necesita su propia regla, porque el servidor que inicia una conexión hacia uno de sus propios clientes es un flujo distinto. Sin esa regla, el cliente responde a una dirección que no puede encaminar. Coloque la regla estrecha antes de cualquier enmascaramiento amplio para que gane la traducció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

Los equipos con varias interfaces añaden una avería relacionada que se ve idéntica desde el cliente. La respuesta sale por la interfaz de métrica más baja porque la dirección de origen se eligió en otra tabla. Compruebe el camino de vuelta con una consulta en lugar de suponer que el de ida lo implica.

Luego verifique ambos sentidos y ambos tamaños

Tras el cambio, haga ping del cliente a un equipo de la LAN y luego del equipo de la LAN al cliente. El segundo sentido es el que la gente omite, y es el que revela una regla de traducción incompleta. Anote ambos resultados con marca de tiempo para que una regresión posterior sea comparable.

Luego mueva datos reales, porque un ping pequeño que funciona mientras una transferencia grande se atasca es un síntoma de MTU. Esa avería aparece justo después de felicitarse por haber arreglado la ruta.

Por último, vuelva a probar tras un reinicio. Las órdenes de ruta y cortafuegos en caliente no sobreviven a él, y un arreglo que desaparece en el siguiente arranque será diagnosticado otra vez por alguien con menos contexto. Haga el cambio persistente como su sistema ya lo hace y reinicie una vez a propósito.