El cliente VPN enrutado llega al servidor pero no a los equipos de la LAN

El túnel se levanta, el cliente hace ping al servidor VPN y un recurso compartido en una máquina a un salto de distancia nunca responde. Nada en la configuración del cliente lo explica, porque la petición sí salió del cliente y sí llegó. Lo que falló es el viaje de vuelta, y el dispositivo que falló suele ser la puerta de enlace de la LAN y no el host VPN. Rastrear el paquete de respuesta explica toda esta clase de síntomas.

Siga la respuesta, no la petición

El servidor VPN descifra el paquete del cliente y lo reenvía a la LAN con la dirección del cliente todavía en el campo de origen. El host de destino responde a esa dirección, y ahora su propia tabla de rutas lo decide todo. Su puerta de enlace predeterminada no sabe nada del grupo del túnel, así que la respuesta sale hacia el proveedor de internet y se descarta en algún punto de ese camino.

En el cliente el síntoma es un tiempo de espera silencioso: sin rechazo, sin reinicio, solo nada. La exploración de un recurso compartido se cuelga, el ping informa de que no hay respuesta y los registros del servidor parecen sanos porque el servidor hizo su trabajo.

Ponga la ruta de vuelta donde miran los equipos

Cada equipo de la LAN consulta su puerta de enlace predeterminada, así que la puerta de enlace es el único dispositivo que necesita saber dónde vive el grupo del túnel. Añada allí una ruta estática y cada equipo hereda el camino correcto sin que se le toque.

Si la puerta de enlace reparte su propia dirección como opción DHCP, distribuya la ruta de esa forma para que las máquinas nuevas la tomen automáticamente. De lo contrario, la ruta vive en un archivo de configuración y desaparece en la siguiente reconstrucción.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Por qué el NAT de origen parece repararlo

Enmascarar el grupo de clientes detrás de la dirección del servidor VPN elimina el problema al eliminar la dirección del cliente del paquete. Las respuestas vuelven entonces al servidor, que ya sabe cómo llegar al túnel, y todo funciona. El coste es que los equipos internos ya no pueden ver quién es el cliente, y cada conexión parece originarse en una sola máquina.

Ese intercambio a veces es correcto, por ejemplo cuando a un dispositivo de un proveedor no se le puede dar una ruta estática. Haga la regla no más amplia que el grupo actual, porque una regla escrita para un /24 deja de coincidir el día en que el grupo se renumera a un /16, y la primera señal es un lote de clientes nuevos que se conectan y no llegan a nada.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

El camino en la nube necesita tres ajustes

En una VPC la misma laguna vuelve con otra forma, porque la subred no tiene ninguna ruta para el rango de clientes. La tabla de rutas necesita una entrada para el grupo del túnel que apunte a la interfaz de red de la instancia, y la interfaz necesita desactivada la comprobación de origen y destino para que la plataforma acepte paquetes cuyo origen no es su propia dirección. Los grupos de seguridad y las ACL de red también deben admitir el grupo en ambos sentidos.

Cada omisión produce un fallo parcial distinto. Omita la entrada de la tabla de rutas y las instancias privadas responden en una subred que no puede llevar la respuesta de vuelta al grupo. Con la comprobación aún activa, la plataforma descarta la respuesta después de que la instancia ya la haya enviado. Sin la regla del grupo de seguridad, la petición misma nunca llega, y el cliente ve el tiempo de espera una capa antes.

Ejecute las comprobaciones en este orden

Confirme el reenvío y la política de filtrado antes de culpar al enrutamiento, porque un equipo que no reenviará falla de la misma manera silenciosa. Después lea el ajuste efectivo de ruta inversa en la interfaz que lleva el túnel, ya que un filtro estricto puede descartar respuestas que llegan desde una dirección inesperada.

Termine con una captura tomada en el equipo de la LAN mientras el cliente le hace ping. Una petición que llega sin respuesta correspondiente demuestra el camino de vuelta, y una petición que nunca llega devuelve la culpa al servidor o al túnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

La comprobación de origen y destino está documentada en la guía de la interfaz de red elástica. Configúrela en la interfaz que realmente lleva el tráfico del túnel, no en un adaptador no relacionado conectado a la misma instancia.