Tengo una VPN de sitio a sitio configurada usando OpenVPN. El túnel parece funcionar bien (y puedo hacer ping de un extremo al otro), pero no puedo lograr que las redes de los dos extremos se vean.
Mi topología es la siguiente:
Net1 (192.168.13.0/24)
|
|
|
192.168.13.35
ens160
-----------
OVPN Client
-----------
tun0
10.13.10.2
|
|
10.13.10.1
tun0
-----------
OVPN Server
-----------
ens160
10.1.121.6
|
|
Net2 (10.1.121.0/26)
Puedo hacer ping desde el cliente al servidor:
srv# ping 10.13.10.2
PING 10.13.10.2 (10.13.10.2) 56(84) bytes of data.
64 bytes from 10.13.10.2: icmp_seq=1 ttl=64 time=5.46 ms
64 bytes from 10.13.10.2: icmp_seq=2 ttl=64 time=5.01 ms
Puedo pasar del cliente a Net1 (después de agregar las rutas apropiadas, por supuesto):
client#ping 10.1.121.8
PING 10.1.121.8 (10.1.121.8) 56(84) bytes of data.
64 bytes from 10.1.121.8: icmp_seq=1 ttl=63 time=48.0 ms
Sin embargo, no puedo hacer nada al revés (hacer ping a algo en la red del cliente -Net2- desde el servidor). Ni siquiera puedo acceder a la IP del cliente en Net2 desde el servidor:
server#ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
^C
--- 192.168.13.35 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2014ms
Tengo las rutas apropiadas:
server# ip route
default via 10.1.121.1 dev ens160 onlink
10.1.121.0/26 dev ens160 proto kernel scope link src 10.1.121.6
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.1
192.168.13.0/24 via 10.13.10.2 dev tun0
client# ip route
default via 192.168.13.1 dev ens160 onlink
10.1.121.0/24 via 10.13.10.1 dev tun0
10.13.10.0/24 dev tun0 proto kernel scope link src 10.13.10.2
192.168.13.0/24 dev ens160 proto kernel scope link src 192.168.13.35
IPTables no bloquea nada (todo está configurado en ACEPTAR):
client# iptables -L -vn
Chain INPUT (policy ACCEPT 56 packets, 3839 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 40 packets, 4343 bytes)
pkts bytes target prot opt in out source destination
server# iptables -L -vn
Chain INPUT (policy ACCEPT 736 packets, 75398 bytes)
pkts bytes target prot opt in out source destination
2 168 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 4 packets, 236 bytes)
pkts bytes target prot opt in out source destination
1 84 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 449 packets, 43393 bytes)
pkts bytes target prot opt in out source destination
Si ejecuto un tcpdump en la interfaz del túnel, veo que los paquetes ICMP salen del cliente, pero no los veo entrantes al servidor:
server# ping 192.168.13.35
PING 192.168.13.35 (192.168.13.35) 56(84) bytes of data.
16:57:40.262004 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 1, length 64
16:57:41.269165 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 2, length 64
16:57:42.277154 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 3, length 64
16:57:43.285163 IP 10.13.10.1 > 192.168.13.35: ICMP echo request, id 1562, seq 4, length 64
client# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
Ambos puntos finales son Ubuntu 16.04 Server LTS (x64, instalado principalmente con los valores predeterminados).
Pensé que sabía un poco sobre las redes Linux, pero... parece que estaba equivocado :). No tengo idea de por qué esto no funciona y me he quedado sin ideas sobre cosas que podría probar. Puede alguien señalarme hacia la dirección correcta?
¡Gracias!
Respuesta1
Es posible que te estés perdiendo el iroute. Además de impulsar rutas, necesitaría iroutearchivos de configuración. Aquí está el extracto de la página de manual de OpenVPN.
--red de ruta [máscara de red]
Generar una ruta interna a un cliente específico. El parámetro de máscara de red, si se omite, el valor predeterminado es 255.255.255.255. Esta directiva se puede utilizar para enrutar una subred fija desde el servidor a un cliente en particular, independientemente de dónde se conecte el cliente. Recuerde que también debe agregar la ruta a la tabla de enrutamiento del sistema (por ejemplo, usando la directiva --route). La razón por la que se necesitan dos rutas es que la directiva --route enruta el paquete desde el kernel a OpenVPN. Una vez en OpenVPN, la directiva --iroute se dirige al cliente específico. Esta opción debe especificarse en un archivo de configuración de instancia de cliente usando --client-config-dir o generada dinámicamente usando un script --client-connect. La directiva --iroute también tiene una interacción importante con --push "ruta...". --iroute esencialmente define una subred que es propiedad de un cliente en particular (a este cliente lo llamaremos A). Si desea que otros clientes puedan acceder a la subred de A, puede utilizar --push "route..." junto con --client-to-client para efectuar esto. Para que todos los clientes vean la subred de A, OpenVPN debe enviar esta ruta a todos los clientes EXCEPTO A, ya que la subred ya es propiedad de A. OpenVPN logra esto al no enviar una ruta a un cliente si coincide con uno de los clientes. iroutes.
Necesitaría entradas de configuración como las que se muestran a continuación en los respectivos clientes y servidores.
ruta 192.168.3.0 255.255.255.0
Además, es posible que deba verificar CCD si tiene varias redes detrás de varios clientes.
directorio-configuración-cliente
Esta directiva establece un directorio de configuración del cliente, que el servidor OpenVPN escaneará en cada conexión entrante, buscando un archivo de configuración específico del cliente (consulte la página del manual para obtener más información). Los archivos de este directorio se pueden actualizar sobre la marcha, sin necesidad de reiniciar el servidor. Tenga en cuenta que los cambios en este directorio solo tendrán efecto para las conexiones nuevas, no para las conexiones existentes. Si desea que un cambio en el archivo de configuración específico del cliente tenga efecto inmediato en un cliente actualmente conectado (o uno que se ha desconectado, pero donde el servidor no ha agotado el tiempo de espera de su objeto de instancia), elimine el objeto de instancia del cliente mediante el comando interfaz (descrita a continuación). Esto hará que el cliente se vuelva a conectar y use el nuevo archivo client-config-dir
Respuesta2
La respuesta de Fossil era justo lo que necesitaba y ya la acepté. Solo me gustaría agregar información para otras personas que puedan tener el mismo problema. Porque la pregunta se ha hecho antes en serverfault, pero las respuestas no mencionan a iroute (un ejemplo), o tener sólo enlaces inactivos (comoÉste)
Entonces... primero que nada, encontré una buena explicación de iroute (y por qué es necesaria)aquí. Pero como acabo de mencionar el riesgo de que los enlaces mueran, también intentaré mencionar las ideas más importantes a continuación.
Parece que las rutas del kernel no son suficientes para que el tráfico pase por un túnel OpenVPN. Si desea llegar a una LAN que está detrás de un cliente OpenVPN, también necesita una ruta interna OpenVPN (iroute). Esto se agrega usando una declaración client-configuration-dir en server.conf y agregando las declaraciones iroute en los archivos de configuración ubicados dentro de ese subdirectorio.
En mi caso también necesitaba:
#Inside server.conf
client-configuration-dir my-config-dir
#Inside my-config-dir/client1 (same name as the client!)
#Tell OpenVPN that 192.168.13.0/24 is reachable via client1
iroute 192.168.13.0 255.255.255.0
Esto también plantea una cuestión interesante: si OpenVPN no puede funcionar utilizando sólo rutas del kernel, a primera vista parece imposible ejecutar un protocolo de enrutamiento sobre los túneles ovpn. ¿Alguien consiguió que funcionara una solución de este tipo (ovpn+rip/ospf)?