Não é possível conectar-se a um servidor membro em uma rede vpn ou vice-versa, mas por quê?

Question

Eu criei um teste VPC na AWS para uma prova de conceito do OpenVPN.

Neste VPC eu almocei um servidor membro linux e um AMI de servidor OpenVPN do AWS Marketplace, instalei e configurei ele.

Como cliente, posso me conectar à rede VPN e a ssh no servidor OpenVPN usando cada um de seus 3 ip's, mas o problema é que não consigo ssh no servidor membro no Sub-rede principal do VPC.

A rede é totalmente estabelecida entre o servidor OpenVPN e o servidor membro.

Os detalhes são:

VPC CIDR: 172.16.0.0/16
VPC Main Subnet CIDR: 172.16.200.0/24 
VPN CIDR: 172.16.201.0/24

OVPN server: 
Main Subnet interface: 172.16.200.66
VPN Server interface: 172.16.201.1
VPN Client interface: 172.16.201.129

Member server:
Main Subnet interface: 172.16.200.71

My Client IP: 172.16.201.131-134 (disconnected a few times)

Eu configurei o servidor OpenVPN assim: E:

Alémdisso,tenteiusaroNAT,massemsucesso.

QuandoexecutotcpdumpdoservidorOVPNaotentarsshdamáquinaclienteparaoservidorintegrante:

openvpnas@openvpnas2:~$sudotcpdump-ias0t1tcpdump:verboseoutputsuppressed,use-vor-vvforfullprotocoldecodelisteningonas0t1,link-typeRAW(RawIP),capturesize262144bytes11:21:52.668974IP172.16.201.131.59009>172.16.200.71.ssh:Flags[SEW],seq2266158529,win65535,options[mss1252,nop,wscale5,nop,nop,TSval758529356ecr0,sackOK,eol],length011:21:53.681875IP172.16.201.131.59009>172.16.200.71.ssh:Flags[S],seq2266158529,win65535,options[mss1252,nop,wscale5,nop,nop,TSval758530357ecr0,sackOK,eol],length0

EupossoverqueoservidorOVPNestátentandoencaminharospacotesparaoservidormembro,masaoexecutartcpdumpnainterfacedoservidormembro,vejoquenenhumpacotechega.

RotasnoservidorOVPN:

$route-nKernelIProutingtableDestinationGatewayGenmaskFlagsMetricRefUseIface0.0.0.0172.16.200.10.0.0.0UG000eth0172.16.200.00.0.0.0255.255.255.0U000eth0172.16.201.00.0.0.0255.255.255.128U000as0t0172.16.201.1280.0.0.0255.255.255.128U000as0t1

Rotasnoservidormembro:

$route-nKernelIProutingtableDestinationGatewayGenmaskFlagsMetricRefUseIface0.0.0.0172.16.200.10.0.0.0UG000eth0172.16.200.00.0.0.0255.255.255.0U000eth0172.16.201.0172.16.200.66255.255.255.0UG000eth0

Rotasnocliente(meulaptop),algumasdelasforamadicionadasmanualmentepormim:

netstat-nr|greptun172.16.200/24172.16.201.134UGSc44utun2172.16.201/24172.16.200.66UGSc12utun2172.16.201.134172.16.201.134UH34utun2

InterfacesderedenoservidorOVPN:

2:eth0:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu9001qdiscpfifo_faststateUPgroupdefaultqlen1000link/ether02:fb:99:4a:67:04brdff:ff:ff:ff:ff:ffinet172.16.200.66/24brd172.16.200.255scopeglobaleth0valid_lftforeverpreferred_lftforeverinet6fe80::fb:99ff:fe4a:6704/64scopelinkvalid_lftforeverpreferred_lftforever3:pr0:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500qdiscnoqueuestateUNKNOWNgroupdefaultqlen1000link/ether36:ce:f1:ac:59:42brdff:ff:ff:ff:ff:ffinet6fe80::34ce:f1ff:feac:5942/64scopelinkvalid_lftforeverpreferred_lftforever21:as0t0:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>mtu1500qdiscpfifo_faststateUNKNOWNgroupdefaultqlen200link/noneinet172.16.201.1/25brd172.16.201.127scopeglobalas0t0valid_lftforeverpreferred_lftforever22:as0t1:<POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>mtu1500qdiscpfifo_faststateUNKNOWNgroupdefaultqlen200link/noneinet172.16.201.129/25brd172.16.201.255scopeglobalas0t1valid_lftforeverpreferred_lftforever

Interfacederedenoservidorintegrante:

2:eth0:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu9001qdiscpfifo_faststateUPgroupdefaultqlen1000link/ether02:c5:62:3b:ef:02brdff:ff:ff:ff:ff:ffinet172.16.200.71/24brd172.16.200.255scopeglobaleth0valid_lftforeverpreferred_lftforeverinet6fe80::c5:62ff:fe3b:ef02/64scopelinkvalid_lftforeverpreferred_lftforever

Maisalgunspontos:

pingdomeuclienteparaoservidorintegrante:

$ping172.16.200.71PING172.16.200.71(172.16.200.71):56databytesRequesttimeoutforicmp_seq0

pingdomeuclienteparaoservidorOVPN(usandoasub-redeprincipaldoVPC):

$ping172.16.200.66PING172.16.200.66(172.16.200.66):56databytes64bytesfrom172.16.200.66:icmp_seq=0ttl=64time=87.657ms

pingdomeuclienteparaovpnipdaOVPNtambémfunciona.

AtabeladeroteamentodesteVPCnoAWS:

Estassãoasminhasperguntas:

1. Devocriarumasub-redede"172.16.201.0" (a sub-rede vpn) no VPC? (Eu tenho, mas não resolveu o problema ... é apenas uma das coisas que eu tentei).

2. Parece que estou perdendo alguma coisa, talvez na configuração da AWS, você pode tentar encontrar meu problema?

Answer 1

Eu posso pensar em 3 coisas que você pode dar uma olhada

1. Como está, qualquer coisa que esteja no intervalo 172.16.0.0/16 CIDR será roteada embora a rota local todo o restante 0.0.0.0/0 seja enviada através do gateway da Internet. porque sua sub-rede VPN cai no intervalo 172.16.0.0/16, isso pode estar causando problemas. pode ser:

a. escolha um intervalo de endereços diferente para sua sub-rede VPN

b. verifique se há uma rota na tabela de rotas que direciona o tráfego para essa sub-rede por meio do dispositivo VPN

1. Você viu os grupos de segurança vinculados a suas instâncias do EC2? eles permitem o tráfego correto (neste caso, SSH) que você deseja fluir para a instância EC2
2. Você viu as ACLs de rede vinculadas a sua VPC e suas sub-redes? Elas permitem o tráfego correto de entrada e saída?