Tempo limite com o OpenVPN

Question

Eu configurei o OpenVPN usando estas instruções com o objetivo de se conectar ao mundo externo usando um endereço IP da AWS em vez do IP atribuído pelo ISP.

A conexão é bem-sucedida. Quando eu faço ping (do cliente), por exemplo, google.com, enquanto conectado à VPN, recebo

Pinging google.com [172.217.9.174] with 32 bytes of data:
Reply from 172.217.9.174: bytes=32 time=122ms TTL=45
Reply from 172.217.9.174: bytes=32 time=262ms TTL=45
Reply from 172.217.9.174: bytes=32 time=119ms TTL=45
Reply from 172.217.9.174: bytes=32 time=121ms TTL=45

comparado com os pings um pouco mais rápidos quando não estiver usando a conexão VPN

Pinging google.com [172.217.6.174] with 32 bytes of data:
Reply from 172.217.6.174: bytes=32 time=84ms TTL=52
Reply from 172.217.6.174: bytes=32 time=85ms TTL=52
Reply from 172.217.6.174: bytes=32 time=89ms TTL=52
Reply from 172.217.6.174: bytes=32 time=82ms TTL=52

No entanto, quando tento carregar um website (por exemplo, cnn.com) em um navegador no cliente, a carga quase sempre atinge o tempo limite.

Eu tentei adicionar

sndbuf 0
rcvbuf 0

para a configuração do OpenVPN no cliente e no servidor, mesmo resultado.

O cliente é o Windows 10 e o servidor Ubuntu 16.04 em execução em uma instância do AWS Nano. top não mostra nenhuma carga significativa no servidor durante uma tentativa de conexão.

A conexão do cliente é de 300 Mbps para baixo / 30 Mbps para cima.

O que mais posso tentar para alcançar velocidades utilizáveis em relação ao OpenVPN?

    

Answer 1

Não posso comentar devido à minha atual falta de reputação.

Primeiro, em qual zona de disponibilidade você configurou sua instância do EC2 na AWS? Estou assumindo um mais próximo de você? Você está executando um VPC no AWS? Ambas introduzem muitas outras variáveis que podem contribuir para um fraco desempenho da rede.

Minha suspeita seria de que o t2.nano não é suficientemente robusto para uma configuração do OpenVPN. As instruções que você seguiu especificamente dizem usar um t2.micro. Tem sido minha experiência que t2.nano tem desempenho de rede ridiculamente ruim, embora t2.micro não seja muito melhor.

Assim, minha resolução sugerida seria aumentar a instância para um t2.micro, ou até mesmo um t2.medium (temporariamente) para descartar o desempenho da rede no terreno da AWS.

Aqui estão mais informações sobre o desempenho da rede EC2

Aqui estão outras leituras sobre EC2 vCPU / desempenho de memória

Como o problema acima não resolve o problema, minha próxima suspeita seria um possível problema com divisão de túnel . Seu cliente está forçando todo o tráfego através do seu túnel? Você pode verificar isso emitindo route PRINT ou tracert google.com . Se estiver usando a opção route , você deverá ver todo o tráfego sendo direcionado para o túnel. Se estiver usando a opção tracert , você deverá ver seu segundo ou terceiro salto percorrendo sua VPN.

Dado que uma das duas opções acima mostra o roteamento de tráfego através da VPN, então você sabe que o tunelamento dividido está desativado. Isso não significa, no entanto, que o DNS funcionará como esperado. Tente executar nslookup google.com 8.8.8.8 . Isso força os servidores DNS públicos do Google (8.8.8.8) a fazer a resolução de nomes de domínio em vez de sua rede local ou DNS dentro da AWS. Agora, emita nslookup google.com 192.168.1.1 , substituindo 192.168.1.1 pelo endereço IP do seu gateway local (geralmente seu roteador). Se isso funcionar, a última opção é SSH na instância do EC2 e emite apenas nslookup google.com .

Se, depois de realizar todos os itens acima, você ainda tiver esse problema, responda com as descobertas adicionais que você realizou ao executar as etapas acima.