Obtuve el siguiente escenario:
un servidor ubuntu 20.04 lts, por simplicidad llamado Un servidor con las siguientes interfaces de red:
- bucle invertido
- enp1s0 (wan) PUBLIC-IP/23
- enp8s0 (lan) 10.9.96.3/20
- ppp0 (l2tp) 192.168.42.1
con esta tabla de enrutamiento (las rutas públicas se omiten intencionalmente):
- 10.9.96.0/20 dev enp8s0 proto kernel alcance enlace src 10.9.96.3
- 192.168.1.0/24 vía 192.168.42.10 dev ppp0
- 192.168.42.10 dev ppp0 proto kernel alcance enlace src 192.168.42.1
Hay un cliente VPN remoto conectado con la IP 192.168.42.10.
Este cliente es un enrutador MikroTik que proporciona la red LAN remota 192.168.1.0/24.
Usando la ruta estática que agregué (192.168.1.0/24 a través de 192.168.42.10 dev ppp0), puedo comunicarme con los dispositivos 192.168.1.0/24.
otro servidor ubuntu 20.04 lts, por simplicidad llamado servidor B con las siguientes interfaces de red:
- bucle invertido
- enp1s0 (wan) PUBLIC-IP/23
- enp8s0 (lan) 10.9.96.4/20
y esta tabla de enrutamiento (las rutas públicas se omiten intencionalmente):
- 10.9.96.0/20 dev enp8s0 proto kernel alcance enlace src 10.9.96.4
Básicamente necesito acceder a dispositivos 192.168.1.0/24 desde el servidor B pero no puedo hacerlo funcionar.
También intenté agregar una ruta estática: 192.168.1.0/24 a través de 10.9.96.3 dev enp8s0
dentro de este servidor sin éxito, veo paquetes destinados a 192.168.1.X que llegan al servidor A pero luego no se reenvían a ppp0 interfaz, supongo (así que también probé algunas reglas de iptables)
¿Cómo arreglar este problema?
El firewall está deshabilitado en ambos servidores.
Respuesta1
NOTA: En esta respuesta, la red 100.64.10.0/23representa la red pública. No es particularmente relevante, pero existe solo para hacer que la configuración de red de estos nodos virtuales coincida con lo que describió en su pregunta.
Su problema es que los hosts de la red 192.168.1.0/24 no saben cómo llegar a la red 10.9.96.0/20.
Según lo que nos mostró en su pregunta, la tabla de enrutamiento en el enrutador microtik (192.168.42.10/192.168.1.1) probablemente se vea así:
192.168.1.0/24 dev h1-eth0 proto kernel scope link src 192.168.1.1
192.168.42.0/24 dev h1-eth1 proto kernel scope link src 192.168.42.10
Y la tabla de enrutamiento en el servidor A se parece a:
default via 100.64.10.1 dev serverA-eth0
10.9.96.0/20 dev serverA-eth1 proto kernel scope link src 10.9.96.3
100.64.10.0/23 dev serverA-eth0 proto kernel scope link src 100.64.10.10
192.168.1.0/24 via 192.168.42.10 dev serverA-eth2
192.168.42.0/24 dev serverA-eth2 proto kernel scope link src 192.168.42.1
En serverA, cuando haces ping a una dirección en la 192.168.1.0/24red, tu dirección de origen es 192.168.42.1. El router microtik tiene ruta para esa red, así que todo genial.
Si serverBtiene una tabla de enrutamiento como esta:
default via 100.64.10.1 dev serverB-eth0
10.9.96.0/20 dev serverB-eth1 proto kernel scope link src 10.9.96.4
100.64.10.0/23 dev serverB-eth0 proto kernel scope link src 100.64.10.20
192.168.1.0/24 via 10.9.96.3 dev serverB-eth1
Luego, cuando intente conectarse a una dirección de la 192.168.1.0/24red, su dirección de origen será 10.9.96.4. El enrutador microtik no sabe cómo llegar a esa dirección (o intenta responder a través de la puerta de enlace predeterminada, lo cual es inapropiado).
La solución es agregar una ruta al enrutador microtik como esta:
ip route add 10.9.96.0/20 via 192.168.42.1
Ahora:
- El servidor B puede hacer ping al enrutador microtik porque el enrutador microtik tiene una ruta válida de regreso al servidor B
- El servidor B puede hacer pingotrohosts en la
192.168.1.0/24red porque esos hosts usan el enrutador microtik (192.168.1.1) como su puerta de enlace predeterminada... y como se estableció en el punto anterior, el enrutador tiene una ruta adecuada.
Probé todo esto en un entorno de red simulado creado usandomininet; puedes encontrar la configuraciónaquísi tienes curiosidad.