Início / server / Perguntas / 863032
Accepted
Itai Ganot
Asked: 2017-07-20 05:34:16 +0800 CST

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

  • 772

Criei uma VPC de teste na AWS para uma prova de conceito do OpenVPN.

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

Como cliente, consigo me conectar à rede VPN e ao sshservidor OpenVPN usando cada um de seus 3 ip's, mas o problema é que não consigo sshentrar no servidor membro na sub-rede principal da VPC.

A rede está 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)

Configurei o servidor OpenVPN assim: E:insira a descrição da imagem aqui insira a descrição da imagem aqui

Além disso, tentei usar o NAT, mas sem sucesso.

Quando executo tcpdumpa partir do servidor OVPN enquanto tento sshda máquina cliente para o servidor membro:

openvpnas@openvpnas2:~$ sudo tcpdump -i as0t1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on as0t1, link-type RAW (Raw IP), capture size 262144 bytes
11:21:52.668974 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [SEW], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758529356 ecr 0,sackOK,eol], length 0
11:21:53.681875 IP 172.16.201.131.59009 > 172.16.200.71.ssh: Flags [S], seq 2266158529, win 65535, options [mss 1252,nop,wscale 5,nop,nop,TS val 758530357 ecr 0,sackOK,eol], length 0

Eu posso ver que o servidor OVPN está tentando encaminhar os pacotes para o servidor membro, mas ao executar tcpdumpna interface do servidor membro, vejo que nenhum pacote chega.

Rotas no servidor OVPN:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    0.0.0.0         255.255.255.128 U     0      0        0 as0t0
172.16.201.128  0.0.0.0         255.255.255.128 U     0      0        0 as0t1

Rotas no servidor membro:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.200.1    0.0.0.0         UG    0      0        0 eth0
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.201.0    172.16.200.66   255.255.255.0   UG    0      0        0 eth0

Rotas no cliente (meu laptop), algumas delas foram adicionadas manualmente por mim:

netstat -nr | grep tun
172.16.200/24      172.16.201.134     UGSc            4        4   utun2
172.16.201/24      172.16.200.66      UGSc            1        2   utun2
172.16.201.134     172.16.201.134     UH              3        4   utun2

Interfaces de rede no servidor OVPN:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:fb:99:4a:67:04 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.66/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::fb:99ff:fe4a:6704/64 scope link
       valid_lft forever preferred_lft forever
3: pr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 36:ce:f1:ac:59:42 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::34ce:f1ff:feac:5942/64 scope link
       valid_lft forever preferred_lft forever
21: as0t0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.1/25 brd 172.16.201.127 scope global as0t0
       valid_lft forever preferred_lft forever
22: as0t1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 200
    link/none
    inet 172.16.201.129/25 brd 172.16.201.255 scope global as0t1
       valid_lft forever preferred_lft forever

Interface de rede no servidor membro:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:c5:62:3b:ef:02 brd ff:ff:ff:ff:ff:ff
    inet 172.16.200.71/24 brd 172.16.200.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c5:62ff:fe3b:ef02/64 scope link
       valid_lft forever preferred_lft forever

Mais alguns pontos:

pingdo meu cliente para o servidor membro:

$ ping 172.16.200.71
PING 172.16.200.71 (172.16.200.71): 56 data bytes
Request timeout for icmp_seq 0

pingdo meu cliente para o servidor OVPN (usando a sub-rede VPC Main):

$ ping 172.16.200.66
PING 172.16.200.66 (172.16.200.66): 56 data bytes
64 bytes from 172.16.200.66: icmp_seq=0 ttl=64 time=87.657 ms

pingdo meu cliente para o ip da VPN da OVPN também funciona.

A tabela de roteamento desta VPC na AWS: insira a descrição da imagem aqui

Estas são as minhas perguntas:

  1. Devo criar uma sub-rede de "172.16.201.0" (a sub-rede vpn) na VPC? (Eu tenho, mas não resolveu o problema... é apenas uma das coisas que tentei).

  2. Parece que está faltando alguma coisa, talvez na configuração na AWS, você pode tentar encontrar o meu problema?

linux

1 respostas

  1. Best Answer

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

    1. Como está, qualquer coisa que esteja na faixa CIDR 172.16.0.0/16 será roteada pela rota local, todo o resto 0.0.0.0/0 será enviado através do gateway da Internet. como sua sub-rede VPN está no intervalo 172.16.0.0/16, isso pode estar causando problemas. talvez:

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

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

    1. Você deu uma olhada nos grupos de segurança vinculados às suas instâncias do EC2? eles permitem o tráfego correto (neste caso SSH) que você deseja fluir para a instância do EC2
    2. Você já deu uma olhada nas Network ACLs que estão vinculadas à sua VPC e suas sub-redes, elas permitem o tráfego correto tanto de entrada quanto de saída?
    • 1

relate perguntas