Los usuarios remotos no llegan al segundo sitio a través del concentrador VPN

Un usuario remoto se conecta al concentrador, llega al servidor de archivos de la propia LAN del concentrador y todo parece sano. Luego abre un recurso compartido en 10.20.0.50 en la sede central, al que el concentrador llega por un túnel independiente entre sedes, y se agota el tiempo. Ambos túneles están activos y ambos contadores suben, así que ningún túnel está roto. Cruzar el concentrador son tres decisiones de enrutamiento en tres dispositivos, y un túnel solo transporta los prefijos para los que se construyó. Este es el orden que compruebo, y el comando que muestra si cada paso es cierto.

El tránsito necesita tres consultas, no un solo túnel

Cada dispositivo hace su propia coincidencia de prefijo más largo y la olvida. El portátil debe enviar 10.20.0.50 al túnel en lugar de a su router local. El concentrador debe tomar un paquete que llegó por la interfaz de acceso remoto y entregarlo a la interfaz entre sedes. La sede central debe enviar una respuesta para la dirección del usuario de vuelta por el túnel. Que falle cualquiera de las tres cosas se ve igual en el navegador: silencio.

Por eso probar cada túnel por separado demuestra tan poco. Hacer ping a la dirección LAN del concentrador ejercita la primera decisión, y hacer ping al concentrador desde la sede central ejercita la tercera. El paquete que falla tiene el grupo de usuarios como origen y el segundo sitio como destino, así que anote esos prefijos primero. Aquí el grupo es 10.80.0.0/24, la LAN del concentrador es 10.10.0.0/24 y la sede central es 10.20.0.0/24.

Empuje el prefijo remoto al cliente remoto

En un OpenVPN servidor de acceso remoto el cliente aprende las rutas al conectarse. Sin un push, un cliente con túnel dividido envía 10.20.0.50 a su propia puerta de enlace y el paquete nunca entra en el túnel.

push "route 10.20.0.0 255.255.255.0"

Una ruta empujada se aplica cuando el cliente se conecta, así que un usuario que sigue en línea no ve nada hasta que se reconecta. Compruébelo en el cliente: ip route get 10.20.0.50 en Linux, route print en Windows. La salida debe nombrar la interfaz del túnel.

El push no ayuda al concentrador. Es un mensaje al cliente, no una ruta en el servidor ni un permiso para reenviar, así que un concentrador con la línea push perfecta sigue descartando el flujo un salto después. Es la razón habitual por la que la gente concluye que el push falló.

Dé al concentrador una ruta de salida real

El concentrador necesita su propio siguiente salto para el prefijo de la sede central. En un túnel enrutado es una ruta ordinaria por la interfaz entre sedes, y un solo comando muestra tanto la ruta elegida como el origen elegido:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Cuando el tramo entre sedes es a su vez OpenVPN, la ruta puede vivir en esa configuración con la dirección de túnel del par como puerta de enlace: route 10.20.0.0 255.255.255.0 172.30.0.2. La puerta de enlace no es opcional. Si la omite, el siguiente salto cae en un valor por defecto de la implementación, que difiere entre un cliente de un solo par y un concentrador con varios pares.

El IPsec basado en políticas es distinto: el núcleo del concentrador envía el paquete a su puerta de enlace LAN habitual y la política lo captura a la salida, así que una ruta de túnel o no hace nada o desvía el tráfico más allá de la política. Vigile el origen en el comando anterior, porque 10.10.0.1 en lugar de la dirección del grupo significa que el núcleo eligió una dirección que el lado remoto rechazará. iroute tampoco es la respuesta; le dice al servidor qué cliente posee una subred detrás de su propio túnel, no adónde enviar el tráfico de un tercer sitio.

Extienda el lado remoto al grupo de usuarios

La sede central ya cubre la LAN del concentrador, 10.10.0.0/24. El grupo de usuarios es un segundo prefijo y también debe estar en los selectores, o ninguna política cubre una respuesta dirigida a 10.80.0.25. Cada par nombra el mismo par de conjuntos de prefijos desde su lado:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

El local_ts de un dispositivo es el remote_ts del otro. Copie el bloque del concentrador en la sede central y el par queda invertido, así que la child SA nunca sube.

La sintaxis más antigua de ipsec.conf usa un leftsubnet separado por comas. La asociación de seguridad en curso conserva los selectores que negoció, así que restablezca el túnel tras la edición. Un selector cambiado a las 10:00 y probado contra una SA levantada a las 09:40 sigue fallando, mientras el archivo de configuración parece correcto todo el tiempo.

Luego compruebe el último salto. ip route get 10.80.0.25 en el extremo remoto debe apuntar al túnel. Si el servicio usa un router LAN como puerta de enlace por defecto, ese router también necesita la ruta de vuelta, o la respuesta muere allí. Ejecutar tcpdump -ni eth1 host 10.80.0.25 en ese segmento muestra si la respuesta salió del extremo.

Permita el flujo en el concentrador

El reenvío debe estar activado y el camino permitido. Acote las reglas a los dos prefijos en lugar de aceptar todo entre las interfaces.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

El filtrado de ruta inversa es el fallo silencioso al lado: con los dos tramos en interfaces distintas, rp_filter=1 puede descartar la respuesta mientras el contador de la regla de aceptación nunca se mueve. Compare iptables -vnL FORWARD antes y después de un intento. Una regla que nunca incrementa no se alcanza, así que mire una capa más abajo en lugar de reescribirla.

Si solo un grupo necesita tránsito, ponga la ruta en un archivo por cliente bajo client-config-dir en lugar de ampliar el push global. El NAT de origen en el concentrador también elimina la necesidad de una ruta de vuelta remota, pero oculta la dirección del usuario, así que los registros del sitio remoto y las reglas basadas en direcciones dejan de distinguir a los usuarios.

Compruebe desde el cliente y luego revierta en orden inverso

Pruebe un puerto TCP, no solo ICMP, porque un ping puede pasar mientras el servicio sigue bloqueado. nc -vz 10.20.0.50 445 y traceroute -n 10.20.0.50 desde el cliente muestran si el segundo salto es la dirección de túnel del concentrador. En el concentrador, tcpdump -ni tun0 host 10.20.0.50 y el mismo filtro en la interfaz entre sedes: una petición en ambas sin respuesta en ninguna mueve el problema al lado remoto.

Luego pruebe algo que deba seguir bloqueado. Si también responde un equipo que el grupo nunca debería alcanzar, ha abierto más que el tránsito y debería estrechar las reglas. Un concentrador que reenvía todo a cada rama pasa la primera prueba y falla la segunda.

Mantenga una lista de reversión, porque cambiaron cuatro objetos y tres son fáciles de olvidar: la ruta empujada, la ruta del concentrador, los selectores y las reglas del cortafuegos. Deshaga en orden inverso, restablezca la SA y haga que un usuario se reconecte. Una reversión parcial deja una ruta apuntando a un túnel que ya no coincide, lo que es más difícil de leer que el silencio original. El manual de OpenVPN 2.6 documenta push, route y iroute para su versión.