Abrir el puerto VPN no hace que los clientes lleguen a la LAN

El túnel se levanta, el cliente se autentica y la LAN detrás de la puerta de enlace sigue invisible. La regla que debía corregirlo permite el puerto VPN y funciona exactamente como está escrita, porque esa regla gobierna los paquetes dirigidos a la propia puerta de enlace. El tráfico del cliente hacia un host detrás de la puerta de enlace tiene otro destino y otra cadena. Un inicio de sesión correcto no cambia cuál de las dos cadenas consulta el núcleo.

Dos cadenas, dos destinos distintos

El destino de un paquete lo decide hacia dónde va, no cómo llegó. El tráfico dirigido a una dirección de la puerta de enlace se entrega localmente y se evalúa con las reglas de entrada. El tráfico que la puerta de enlace reenvía se evalúa con las reglas de reenvío. La misma interfaz de túnel puede producir ambos tipos de paquete, por eso una sola regla no puede cubrir las dos tareas.

Todo el mito en una frase: permitir el escucha no dice nada sobre permitir la red que hay detrás. Son dos decisiones separadas con pruebas separadas, y un nombre de interfaz en ambas no las fusiona.

Qué admite realmente la regla del escucha

Los paquetes del escucha terminan en el proceso VPN, y eso es lo que permite establecer el túnel. La página de administración de la puerta de enlace y una respuesta de diagnóstico local también usan la ruta de entrada del propio host, por eso una prueba hacia la puerta de enlace funciona mientras todo lo que está detrás falla. Ambos resultados son correctos y ninguno trata de la LAN.

Cuando el proceso desencapsula el tráfico del cliente para otro destino, el paquete entra en la ruta de reenvío y necesita permiso allí. La autenticación correcta resuelve quién es el cliente; no resuelve a dónde puede ir. Las dos preguntas tienen dueños distintos, registros distintos y mensajes de error distintos.

Pruebe desde un cliente, nunca desde la puerta de enlace

Una prueba generada en la puerta de enlace sigue la ruta de salida del propio host y puede pasar mientras la ruta reenviada está cerrada. Empiece la prueba desde el cliente y observe ambos extremos del flujo.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Si la petición aparece en tun0 y nada llega al destino, el paquete se descarta tras la llegada, lo que apunta a las reglas de reenvío o al filtrado propio del destino. Si no aparece nada en tun0, el cliente ni siquiera la envía al túnel, y el problema es el enrutamiento en el cliente y no la política en la puerta de enlace. Compárelo con una petición que sale correctamente y no devuelve nada, que es el caso de la ruta de retorno.

El reenvío necesita tres cosas, no una

El reenvío del núcleo debe estar activado, una regla de filtro debe aceptar el flujo y el destino debe ser alcanzable con un camino para que vuelva la respuesta. Si falta una de las tres, el silencio es el mismo desde el punto de vista del cliente.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lea las tres salidas juntas. Un cero en la primera hace irrelevantes las otras dos, y una política de descarte por defecto en la segunda descarta los paquetes del cliente mientras el tráfico propio de la puerta de enlace sigue funcionando. La tercera salida muestra por qué la regla del escucha nunca fue el problema.

Mantenga los dos conjuntos de reglas separados en la documentación

Escriba la regla del escucha y la regla del servicio reenviado en líneas separadas, con dueños y motivos separados. Cuando cambia el puerto VPN o se publica un servicio nuevo, esa separación evita que un cambio amplíe en silencio el otro.

En lugar de tratar cada par autenticado como un miembro de confianza de la LAN, use reglas estrechas para los rangos de clientes y los servicios que las necesitan. Las notas de reenvío de StrongSwan describen el lado de ruta de retorno y de traducción de la misma frontera, que es otra tercera decisión.

Por último, mantenga las capas rectas cuando se rechaza a un usuario. Si la petición llega al host y la aplicación rechaza la cuenta, repare el permiso de la aplicación en esa capa; ampliar el reenvío no puede proporcionar una credencial de compartición de archivos y ampliará el acceso para todos los demás que se conecten correctamente.