OpenVPN en AWS (funciona en modo NAT pero no en modo de enrutamiento)

Question

Tengo una VPC nueva (10.0.0.0/16) con 3 subredes públicas (que apuntan a una IGW) y 3 subredes privadas (con una NAT GW en cada una). Implementé un dispositivo OpenVPN en la subred pública y lo configuré para usar el modo NAT ( Yes, using NATen la configuración de enrutamiento). También tengo una instancia de prueba en una de las subredes privadas. Tanto la instancia de OpenVPN como la instancia de prueba tienen grupos SG con una flexibilidad "generosa" (es decir, todo lo que se permite entrar y salir... para fines de prueba). En OpenVPN lo he configurado 10.0.0.0/16en el Specify the private subnets to which all clients should be given access (one per line):campo.

Desde mi Mac (en una red doméstica 192.168.178.0/24) puedo establecer un túnel y acceder fácilmente a la instancia de prueba. Todo está bien.

Ahora quiero cambiar al modo Ruta.

• Cambié el modo de enrutamiento a Yes, using Routing. Deshabilité la verificación de origen/destino en la instancia de OpenVPN.
• Agregué una ruta estática a las 4 tablas de enrutamiento en la VPC (3 x las subredes privadas y 1 x la subred pública) para decir que el tráfico dirigido a 192.168.178.0/24(mi red doméstica) debe ir a la instancia de OpenVPN (probablemente esto no fue necesario para la subred pública).
• Agregué 192.168.178.0/24al Specify the private subnets to which all clients should be given access (one per line):campo (no estoy seguro si era necesario) además de 10.0.0.0/16.
• He reconfigurado los permisos de usuario para el usuario que estoy usando para iniciar sesión Use Routingy he especificado nuevamente las dos subredes anteriores (10. y 192.).

Todavía puedo establecer el túnel. Puedo alcanzar la IP interna de la instancia de OpenVPN:

$ traceroute 10.0.4.223          
traceroute to 10.0.4.223 (10.0.4.223), 64 hops max, 52 byte packets
 1  10.0.4.223 (10.0.4.223)  178.345 ms  174.470 ms  173.680 ms
$

Pero NO puedo acceder a la instancia de prueba en la subred privada:

$ traceroute 10.0.165.139
traceroute to 10.0.165.139 (10.0.165.139), 64 hops max, 52 byte packets
 1  172.27.232.1 (172.27.232.1)  194.976 ms  177.014 ms  174.402 ms
 2  * * *
 3  * * *
 4  * * *
^C
$

Curiosamente, si entro a mi servidor OpenVPN e intento rizar un NGINX en mi estación de trabajo local donde inicié el túnel, no puedo alcanzarlo. Parece que la estación de trabajo puede llegar al servidor OpenVPN (consulte el seguimiento anterior 10.0.4.223) pero el servidor OpenVPN no puede llegar a la estación de trabajo (por algunas razones).

Parece que el flujo iniciado desde la estación de trabajo es capaz de encontrar una ruta hacia (y desde) la instancia de OpenVPN. Sin embargo, la ruta se interrumpe en algún lugar desde la estación de trabajo hasta la instancia de prueba (y viceversa) Y parece romperse también cuando se inicia desde la instancia de OpenVPN a la estación de trabajo (consulte el rizo).

Answer 1

Finalmente descubrí que el dispositivo OpenVPN Access Server no se puede configurar para volver a conectarse a la IP nativa del cliente en la subred local. Sin embargo, se puede llegar al cliente a través de la IP del túnel asignada por la VPN. Esta IP se puede configurar estáticamente por usuario o puede provenir de un grupo definido en el dispositivo.

En mi caso he configurado ambos (ver imagen).

Es importante saber que estas son también las subredes que deben usarse en la información de enrutamiento. Es decir, una IP que se encuentra en la red 10.0.0.0/16 puede llegar al dispositivo cliente a una de las direcciones 172.27 asignadas y, por lo tanto, son las redes 172.27 las que deben especificarse en la tabla de enrutamiento (y NO la red nativa local de el dispositivo cliente: 192.168.178.0/24 en mi ejemplo).