OpenVPN na AWS (funciona no modo NAT, mas não funciona no modo Roteamento)

Question

Eu tenho um VPC totalmente novo (10.0.0.0/16) com 3 sub-redes públicas (apontando para um IGW) e 3 sub-redes privadas (com um GW NAT em cada uma). Implantei um dispositivo OpenVPN na sub-rede pública e configurei-o para usar o modo NAT ( Yes, using NATna configuração de roteamento). Também tenho uma instância de teste em uma das sub-redes privadas. Tanto a instância OpenVPN quanto a instância de teste possuem grupos SG com flexibilidade "generosa" (ou seja, tudo permitido entrada-saída.... para fins de teste). No OpenVPN eu configurei 10.0.0.0/16em Specify the private subnets to which all clients should be given access (one per line):campo.

No meu Mac (em uma rede doméstica 192.168.178.0/24), posso estabelecer um túnel e chegar facilmente à instância de teste. Tudo certo.

Agora quero mudar para o modo Rota.

• Mudei o modo de roteamento para Yes, using Routing. Desativei a verificação de origem/destino na instância do OpenVPN.
• Eu adicionei uma rotina estática a todas as 4 tabelas de roteamento na VPC (3 x as sub-redes privadas e 1 x a sub-rede pública) para dizer que o tráfego direcionado para 192.168.178.0/24(minha rede doméstica) deveria ir para a instância do OpenVPN (provavelmente isso não era necessário para a sub-rede pública).
• Adicionei 192.168.178.0/24ao Specify the private subnets to which all clients should be given access (one per line):campo (não tenho certeza se isso era obrigatório) além de 10.0.0.0/16.
• Reconfigurei as permissões do usuário que estou usando para fazer login Use Routinge especifiquei novamente as duas sub-redes acima (10. e 192.).

Ainda posso estabelecer o túnel. Posso acessar o IP interno da instância 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
$

Mas NÃO consigo acessar a instância de teste na sub-rede 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, se eu fizer ssh no meu servidor OpenVPN e tentar enrolar um NGINX na minha estação de trabalho local onde iniciei o túnel, não consigo alcançá-lo. Parece que a estação de trabalho pode acessar o servidor OpenVPN (veja o rastreamento acima para 10.0.4.223), mas o servidor OpenVPN não pode acessar a estação de trabalho (por alguns motivos).

Parece que o fluxo iniciado na estação de trabalho é capaz de encontrar uma rota de ida e volta para a instância do OpenVPN. No entanto, a rota é interrompida em algum lugar da estação de trabalho para a instância de teste (e vice-versa) E parece estar interrompida também quando iniciada da instância OpenVPN para a estação de trabalho (veja o curl).

Answer 1

Acabei descobrindo que o dispositivo OpenVPN Access Server não pode ser configurado para conectar-se novamente ao IP nativo do cliente na sub-rede local. No entanto, o cliente pode ser alcançado através do IP do túnel atribuído pela VPN. Este IP pode ser configurado estaticamente por usuário ou pode vir de um pool definido no dispositivo.

No meu caso configurei ambos (ver imagem).

É importante saber que estas são também as sub-redes que precisam ser usadas nas informações de roteamento. Ou seja, um IP que esteja na rede 10.0.0.0/16 pode alcançar o dispositivo cliente para um dos endereços 172.27 atribuídos e, portanto, são as redes 172.27 que precisam ser especificadas na tabela de roteamento (e NÃO a rede nativa local de o dispositivo cliente - 192.168.178.0/24 no meu exemplo).