Como soluciono problemas de perda de pacotes na minha conexão VPN?

Resolução

Verifique a utilização de recursos

O alto uso de CPU, memória ou largura de banda de rede contribui para a perda de pacotes. Monitore as métricas de utilização de CPU, NetworkIn, NetworkOut, NetworkPacketsIn e NetworkPacketsOut do Amazon CloudWatch. Verifique a utilização de recursos nos hosts de origem e de destino.

Verifique se há problemas de rede

Para verificar a perda ou latência de pacotes ICMP ou TCP, instale a ferramenta de rede mtr na máquina on-premises local. Também instale mtr em uma instância do Amazon Elastic Compute Cloud (Amazon EC2).

Para o Amazon Linux, execute o seguinte comando:

sudo yum install mtr

Para o Ubuntu, execute o seguinte comando:

sudo apt-get install mtr

Para Windows, use o WinMTR do SourceForge.

Observação: O WinMTR não suporta MTR baseado em TCP.

Verifique se há perda de pacotes dentro do túnel VPN da AWS. Teste a conexão do host on-premises que está usando o túnel para o endereço IP privado da sua instância do Amazon EC2. Além disso, teste a conexão do gateway do cliente on-premises com o endereço IP público de cada túnel. Se você não conseguir usar o mtr no dispositivo de gateway do cliente, use um host com a mesma conexão à internet do dispositivo de gateway do cliente.

Importante: Obtenha resultados do mtr em ambas as direções. O caminho entre os nós em uma rede de endereços TCP e IP pode mudar quando você inverte a direção.

Execute o teste a seguir em um endereço IP privado com ICMP:

mtr -b -c 50 -rw Host_Instance_Private_IP

Execute o teste a seguir em um endereço IP privado com TCP:

mtr -b -c 50 -rw -T -P 443 Host_Instance_Private_IP

Observação: Nos comandos anteriores, substitua Host_instance_private_IP pelo endereço IP privado da sua instância do EC2 ou host on-premises e 443 pela sua porta.

Execute o teste a seguir em um endereço IP público com ICMP:

mtr -b -c 50 -rw AWS_Tunnel_Public_IP

Execute os testes a seguir em um endereço IP público com UDP:

mtr -b -c 50 -rw -u -P 500 AWS_Tunnel_Public_IP

mtr -b -c 50 -rw -u -P 4500 AWS_Tunnel_Public_IP

Observação: Nos comandos anteriores, substitua AWS_Tunnel_Public_IP pelo endereço IP público do túnel, e 500 e 4500 pelas suas portas UDP.

Espera-se perda de pacotes e aumento do tempo de ida e volta (RTT) em um único salto. A perda de pacotes e o aumento do RTT só são problemas se você os visualizar em cada salto. O exemplo de saída a seguir mostra uma perda consistente que começa no salto 3 e continua até o salto final:

HOST: localhost                      Loss%   Snt   Last  Avg  Best  Wrst   StDev
   1. 63.247.74.43                   0.0%    10    0.3   0.6   0.3   1.2   0.3
   2. 63.247.64.157                  0.0%    10    0.4   1.0   0.4   6.1   1.8
   3. 209.51.130.213                60.0%    10    0.8   2.7   0.8  19.0   5.7
   4. aix.pr1.atl.google.com        60.0%    10    6.7   6.8   6.7   6.9   0.1
   5. 72.14.233.56                  50.0%    10    7.2   8.3   7.1  16.4   2.9
   6. 209.85.254.247                40.0%    10   39.1  39.4  39.1  39.7   0.2
   7. 64.233.174.46                 40.0%    10   39.6  40.4  39.4  46.9   2.3
   8. gw-in-f147.1e100.net          40.0%    10   39.6  40.5  39.5  46.7   2.2

O exemplo a seguir mostra um teste do endereço IP público de um túnel que usa a porta UDP 500. Entre os saltos 1 e 4, a coluna Loss% mostra uma perda percentual. No entanto, como não há perda de pacotes entre os saltos 5 e 13, essa perda não se qualifica como perda significativa de pacotes. A perda entre o salto 14 e o salto final mostra uma perda significativa de pacotes porque é uma perda sustentada que termina em 100% de perda. O problema neste exemplo ocorre no salto 14.

sudo mtr -b -c 30 -rw -u -P 500 185.156.137.215
Start: 2024-08-28T18:59:49+0000
HOST: ip-10-100-20-25                       Loss% Snt Last Avg Best Wrst StDev
1. |-- ???                                   100.0 30 0.0  0.0  0.0  0.0   0.0
2. |-- 240.1.84.6                            73.3% 30 0.5  0.5  0.5  0.5   0.0
3. |-- 242.3.160.33                          63.3% 30 1.4  1.0  0.6  1.4   0.3
4. |-- 241.0.6.67                            63.3% 30 0.5  6.7  0.5  12.4  5.9
5. |-- 100.100.6.39                          0.0%  30 0.5  3.1  0.5  27.7  6.2
6. |-- 100.100.72.6                          0.0%  30 1.1  9.9  0.5  96.0  17.6
7. |-- 100.91.209.81                         0.0%  30 11.5 20.6 11.1 127.3 24.3
8. |-- 100.100.6.107                         0.0%  30 12.8 19.9 11.6 127.8 22.6
9. |-- 99.83.70.223                          0.0%  30 12.3 18.1 11.7 117.0 19.2
10.|-- 100.100.92.209                        0.0%  30 11.9 13.7 11.6 50.6  7.0
11.|-- 100.100.16.88                         0.0%  30 13.2 14.0 11.9 33.1  3.8
12.|-- gw-as249.retn.net (87.245.240.41)     0.0%  30 13.2 13.2 11.8 19.9  1.5
13.|-- thw.sw01.loudltd.net (185.156.136.14) 0.0%  30 11.4 12.5 11.4 14.2  1.0
14.|-- no-ptr.pckear.com (185.116.108.124)   20.0% 30 14.8 13.2 12.5 14.8  0.5
15.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 14.1 13.6 12.5 15.5  0.8
16.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 16.5 14.5 13.3 16.5  0.8
17.|-- ???                                  100.0% 30 0.0  0.0  0.0  0.0   0.0

Verifique se há problemas de latência e roteamento

A ferramenta traceroute mostra o caminho que os dados percorrem pela rede. Use essas informações para identificar onde ocorrem atrasos.

Para instalar o traceroute no Amazon Linux, execute o seguinte comando:

sudo yum install traceroute

Para instalar o traceroute no Ubuntu, execute o seguinte comando:

sudo apt-get install traceroute

Para Windows, em vez de traceroute, use a ferramenta tracert. Essa ferramenta é instalada em todas as máquinas Windows por padrão. Observe que o tracert não permite rastreamento de TCP. Para obter todos os recursos, você pode instalar a ferramenta tracetcp.

Execute os seguintes testes entre o endereço IP público e privado de suas instâncias do Amazon EC2 e seu host on-premises.

Importante: Obtenha resultados em ambas as direções. O caminho entre os nós em uma rede de endereços TCP e IP pode mudar quando você inverte a direção.

Para Linux, use o seguinte comando:

sudo traceroute -T -p 80 Host_IP

Observação: Substitua Host_IP pelo endereço IP privado da sua instância do EC2 ou host on-premises e 80 pela sua porta. Para maior precisão, o exemplo anterior usa um rastreamento baseado em TCP (T) para testar o caminho do tráfego dentro do túnel. Para testar o caminho do tráfego pela internet, substitua Host_IP pelo endereço IP público do túnel.

Você recebe uma saída semelhante ao seguinte exemplo:

traceroute -T -p 443 aws.com
traceroute to aws.com (3.161.213.43), 30 hops max, 60 byte packets
1 SEA-1801842641.mshome.net (172.28.96.1)  0.363 ms  0.346 ms  0.362 ms
2  192.168.50.1 (192.168.50.1)              5.514 ms  5.508 ms  5.501 ms
3  172.27.232.1 (172.27.232.1)             45.179 ms 52.879 ms 52.871 ms
4                                                  *         *         *
5                                                  *         *         *
6                                                  *         *         *
7                                                  *         *         *
8                                                  *         *         *
9 server.yul62.r.ct.net (3.161.213.43)     57.452 ms 57.741 ms 62.604 ms

Este exemplo de saída mostra saltos intermediários sem resposta. Embora os dispositivos não tenham respondido na porta 443 solicitada, não há problema porque o destino ainda responde conforme o esperado.

Para Windows, execute tracert. Ou, se você instalou o tracetcp, execute o seguinte comando do PowerShell:

tracetcp.exe Host_IP:80

Observação: Substitua Host_IP pelo endereço IP privado da sua instância do EC2 ou host on-premises e 80 pela sua porta. Para maior precisão, o exemplo anterior usa um rastreamento baseado em TCP (T) para testar o caminho do tráfego dentro do túnel. Para testar o caminho do tráfego pela internet, substitua Host_IP pelo endereço IP público do túnel.

Você recebe uma saída semelhante ao seguinte exemplo:

PS C:\Users\UserA> tracetcp.exe aws.com:443

Tracing route to 18.239.168.29 [server-18-239-168-29.bos50.r.cloudfront.net] on port 443
Over a maximum of 30 hops.
1  5 ms  7 ms  6 ms  192.168.50.1
2  41 ms 42 ms 44 ms 172.27.232.1
3  *     *     *     Request timed out.
4  *     *     *     Request timed out.
5  *     *     *     Request timed out.
6  51 ms 43 ms 45 ms 241.0.11.143
7  62 ms 54 ms 43 ms 241.0.11.135
8  53 ms 53 ms 55 ms 240.4.8.24
9  52 ms 56 ms 53 ms 240.4.8.17
10 56 ms 59 ms 62 ms 240.64.239.162
11 57 ms 56 ms 61 ms 240.64.239.162
12 57 ms 55 ms 57 ms 240.64.239.162
13 58 ms Destination Reached in 54 ms. Connection established to 18.239.168.29
Trace Complete.

Teste o desempenho do TCP de ponta a ponta

Use hping3 para testar a perda e a latência de pacotes TCP de ponta a ponta. Essa ferramenta permite avaliar o desempenho do TCP diretamente entre os hosts.

Para instalar o hping3 no Amazon Linux, execute o seguinte comando:

sudo yum --enablerepo=epel install hping3

Para instalar o hping3 no Ubuntu, execute o seguinte comando:

sudo apt-get install hping3

Para executar o hping3, execute o seguinte comando:

hping3 -S -c 50 -V Host_IP

Observação: Substitua Host_IP pelo endereço IP privado da sua instância do EC2 ou host on-premises, ou pelo endereço IP público do túnel.

O exemplo de saída a seguir mostra um teste com o endereço IP público de um endpoint de VPN que usa a porta TCP 8443:

sudo hping3 -S -c 3 -p 8443 -V 34.233.155.9
using eth0, addr: 172.28.100.111, MTU: 1500
HPING 34.233.155.9 (eth0 34.233.155.9): S set, 40 headers + 0 data bytes
len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44
sport=8443 flags=SA seq=0 win=26883 rtt=49.6 ms
seq=2996814187 ack=1585541078 sum=22f7 urp=0

len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44
sport=8443 flags=SA seq=1 win=26883 rtt=49.6 ms
seq=3555645549 ack=1207738370 sum=29a5 urp=0

len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44
sport=8443 flags=SA seq=2 win=26883 rtt=49.2 ms
seq=4045561197 ack=742863285 sum=f78c urp=0

Identifique problemas com a rede ou a aplicação

Obtenha capturas simultâneas de pacotes na instância do EC2 e no host on-premises quando o problema ocorrer. Use a captura de pacotes para identificar problemas com a rede ou a aplicação.

Para obter uma captura de pacotes para instâncias Linux, use tcpdump.

Para instalar o tcpdump no Amazon Linux, execute o seguinte comando:

sudo yum install tcpdump

Para instalar o tcpdump no Ubuntu, execute o seguinte comando:

sudo apt-get install tcpdump

Para Windows, em vez de tcpdump, use o Wireshark. Para baixar a ferramenta, consulte Baixar o Wireshark no site do Wireshark.

A captura de pacotes é semelhante ao exemplo a seguir:

tcpdump -i any -nnvv port 500 and port 4500
tcpdump: listening on any, link-type EN10MB (Ethernet), capture size 65535 bytes
18:12:54.944933 IP (tos 0x0, ttl 63, id 43082, offset 0, flags [DF], proto UDP (17), length 212)
10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→0000000000000000: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=1
(t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=7080)(type=enc value=aes)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024))))
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16) out slot1/tmm0 lis=$_ike_1061b_out_23.20.145.20 port=1.0 trunk=
18:12:54.946069 IP (tos 0x0, ttl 253, id 56278, offset 0, flags [none], proto UDP (17), length 152)
23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=1
(t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifedura tion value=7080))))
(vid: len=16)
(vid: len=16) in slot1/tmm0 lis= port=1.0 trunk=
18:12:54.949988 IP (tos 0x0, ttl 63, id 43084, offset 0, flags [DF], proto UDP (17), length 256)
10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 I ident:
(ke: key len=128)
(nonce: n len=16 data=(e84ae917994501b5b4f4...1a547b3cf720e35995f5b0c69198c9f796b5d9f9))
(pay20)
(pay20) out slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk=
18:12:54.951858 IP (tos 0x0, ttl 253, id 56279, offset 0, flags [none], proto UDP (17), length 272)
23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident:
(ke: key len=128)
(nonce: n len=32 data=(c5170686e88069e33323...4448aaf06cc37d4b32d67df97e275e5756a534d8))
(pay20)
(pay20) in slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk=

(Somente Windows) Desative a ECN

Se a notificação explícita de congestionamento (ECN) estiver ativada para suas instâncias do Windows, você poderá ter perda de pacotes ou problemas de desempenho.

Para verificar se a ECN está ativada, execute o seguinte comando do PowerShell:

netsh interface tcp show global

Para desativar a ECN, execute o seguinte comando do PowerShell:

netsh interface tcp set global ecncapability=disabled

Informações relacionadas

Por que minha aplicação tem problemas de latência e desempenho quando eu uso o Site-to-Site VPN?

As métricas de desempenho de rede em nível de instância do Amazon EC2 revelam novos insights

Como soluciono problemas de baixa velocidade de transferência no meu Site-to-Site VPN?