No se puede hacer ping a la subred detrás del servidor OpenVPN

Aquí está mi infraestructura:

dns of mydomain.com:
  vpn A 90.90.90.1
  vpn A 90.90.90.2

client vpn config:
  client
  dev tun
  proto udp
  nobind
  remote vpn.mydomain.com 1394

server1
  net.ipv4.ip_forward = 1
  iptables:
    FORWARD defaults to ACCEPT
  vpn config:
    dev tun
    topology subnet
    port 1394
    proto udp
    server 10.10.1.0 255.255.255.0
    push "route 10.90.90.0 255.255.255.0"
  interfaces:
    ifpub: 90.90.90.1/24
    ifpriv: 10.90.90.1/24
    ifvpn: 10.10.1.1/24
  routes:
    10.10.1.0/24 src 10.10.1.1 dev ifvpn
    10.10.2.0/24 via 10.90.90.2 dev ifpriv

server2
  net.ipv4.ip_forward = 1
  iptables:
    FORWARD defaults to ACCEPT
  vpn config:
    dev tun
    topology subnet
    port 1394
    proto udp
    server 10.10.2.0 255.255.255.0
    push "route 10.90.90.0 255.255.255.0"
  interfaces:
    ifpub: 90.90.90.2/24
    ifpriv: 10.90.90.2/24
    ifvpn: 10.10.2.1/24
  routes:
    10.10.1.0/24 via 10.90.90.1 dev ifpriv
    10.10.2.0/24 src 10.10.2.1 dev ifvpn

El problema es que desde mi cliente puedo hacer ping al servidor OpenVPN al que estoy conectado, pero no al otro servidor en la subred 10.90.90.0/24.

tcpdumpmuestra que la solicitud de ICMP va de ifvpna ifpriven el mismo servidor pero luego el paquete de solicitud de ICMP nunca va más allá.

Agregar el registro a iptables también me muestra que el paquete de solicitud ICMP pasa al estado POSTROUTING sin caerse, pero luego el paquete nunca llegó a su destino, y no sé qué sucede aquí, no tengo soluciones.

Sabía que puedo enmascarar mis paquetes, pero no quiero porque no se recomienda ( https://community.openvpn.net/openvpn/wiki/NatHack ), o será mi última solución.

— Víctor
fuente

Probé el truco de la mascarada y funciona. iptables -t nat -A POSTROUTING -s 10.10.1.0/24 -o ifpriv -j MASQUERADEen el servidor 1, por ejemplo, y ahora puedo hacer ping a la ip privada del servidor 2 desde mi cliente. Pero como se describe en la página de NatHack

The authorities would see all the telephone calls as coming from you. It would be better if everyone got their own phone, so the calls could be routed directly.

. Entonces el problema todavía está aquí ...

— Victor

IIRC OpenVPN necesita una configuración especial además del enrutamiento para acceder a una subred completa. Veré si puedo encontrar los detalles.

— dirkt

Creo que debe permitir la entrada de iptables en el servidor2 para que el ping llegue al servidor2.

— Gohu

He probado para agregar PREROUTING log en server2 pero no veo venir nada. Supuse que PREROUTING es la primera cadena en la que entraría el paquete como se describe en esta imagen i.stack.imgur.com/4wdkF.png ?

— Victor

Desenterrado : necesita iroute en algunas topologías, pero eso no parece aplicarse aquí. Si te entiendo correctamente, las ifprivinterfaces en ambos servidores están conectadas por LAN, y ves un paquete saliente en ifprivel servidor 1, pero nunca entra ifpriven el servidor 2, ¿es correcto? Pregunta estúpida: ¿Puedes hacer ping al servidor 2 desde el servidor 1 directamente?

— dirkt

Si el servidor remoto "expone una subred", debe tener un ccddirectorio que contenga archivos con iroutedirectivas, como se describe cuidadosamente en la documentación de OpenVPN. También debe tener routedirectivas enviadas a los clientes.

Cuando todo funciona correctamente:

El cliente envía el ping.
El sistema operativo del cliente tiene un comando de enrutamiento que envía este tráfico al servidor local de OpenVPN.
La ccdinformación le dice a OpenVPN a qué control remoto conectado debe enviar el tráfico para su entrega.
El tráfico emerge en este control remoto y continúa hacia su destino.
Para el viaje de regreso, el sistema remoto también debe tener una ruta del sistema operativo que envíe el tráfico de regreso a su servidor OpenVPN.

— Mike Robinson
fuente

Ok, gracias, lo intentaré. ¿Dónde está la documentación que estabas describiendo? Estaba usando este: openvpn.net/index.php/open-source/documentation/…

— Victor