Eu tenho um novo VPC (10.0.0.0/16) com 3 sub-redes públicas (apontando para um IGW) e 3 sub-redes privadas (com um NAT GW em cada). Eu implantei um dispositivo OpenVPN na sub-rede pública e o configurei para usar o modo NAT ( Yes, using NAT
na 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-teste possuem grupos SG com flexibilidade "generosa" (ou seja, tudo permitido dentro-fora... para propósitos de teste). No OpenVPN eu configurei 10.0.0.0/16
no Specify the private subnets to which all clients should be given access (one per line):
campo.
Do 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 eu quero mudar para o modo Rota.
- Eu mudei o modo de roteamento para
Yes, using Routing
. Desativei a verificação de origem/destino na instância OpenVPN. - Adicionei uma rotina estática a todas as 4 tabelas de roteamento no 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) deve ir para a instância OpenVPN (provavelmente isso não foi necessário para a sub-rede pública). - Eu adicionei
192.168.178.0/24
aoSpecify the private subnets to which all clients should be given access (one per line):
campo (não tenho certeza se isso era necessário), além de10.0.0.0/16
. - Eu reconfigurei as permissões de usuário para o usuário que estou usando para fazer login
Use Routing
e especificando 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 ssh em meu servidor OpenVPN e tento enrolar um NGINX em 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 (consulte 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 para (e voltar) para a instância do OpenVPN. No entanto, a rota quebra em algum lugar da estação de trabalho para a instância de teste (e vice-versa) E parece estar quebrando também quando iniciada da instância OpenVPN para a estação de trabalho (consulte o curl).
Acabei descobrindo que o dispositivo OpenVPN Access Server não pode ser configurado para se conectar de volta 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. Esse IP pode ser configurado estaticamente por usuário ou pode vir de um pool definido no dispositivo.
No meu caso, configurei os dois (veja a foto).
É importante saber que esta é (são) também as sub-redes que precisam ser usadas nas informações de roteamento. Ou seja, um IP que fica 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).