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

Resolução

Se você estiver enfrentando problemas de performance ou latência ao usar o Site-to-Site VPN para acessar recursos, siga estas etapas de solução de problemas:

• Isole os sistemas de origem e destino, um de cada vez.
• Verifique o caminho de rede em busca de problemas que possam estar causando latência.
• Verifique se há erros comuns na sua aplicação que causam problemas de latência.

Isole seus sistemas de origem e destino

Para mitigar problemas de performance entre sua aplicação on-premises e a AWS, primeiro isole os sistemas de origem e destino. Em seguida, use ferramentas de rede para verificar se há perda e latência fora da aplicação que possam estar afetando diretamente a performance.

1. Altere a origem e o destino. Use uma origem diferente e, em seguida, um destino diferente e verifique se o problema persiste após cada alteração. Depois, verifique o dispositivo para determinar se há um problema de configuração do sistema operacional (SO) ou outro problema.

2. Realize um teste de recursos de largura de banda UDP. Problemas de performance podem indicar problemas de throughput, portanto use a ferramenta iperf3 para verificar sua largura de banda provisionada. Realize esse teste bidirecionalmente. O exemplo de teste UDP a seguir usa a ferramenta iperf3.

Observação: -i se refere ao intervalo, -u se refere ao UDP, -b se refere à largura de banda (ajustar adequadamente), -p se refere à porta UDP e -v se refere ao modo detalhado.

Server: sudo iperf -s -u [-p 5001]
client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V

Observação: certifique-se de que o crédito de largura de banda esteja disponível para a instância do Amazon Elastic Compute Cloud (Amazon EC2) que você está usando. Ou tente usar um tamanho de instância maior e, em seguida, teste novamente.

3. Use o iperf3 para realizar um teste TCP de throughput no Site-to-Site VPN. Realize esse teste bidirecionalmente. Veja os seguintes exemplo:

Observação: para obter uma performance ideal, experimente diferentes tamanhos de janela TCP de recepção para testar os buffers de memória de origem e destino ao aumentar o tamanho da instância.

Server : iperf3 -s [-p 5001]
Client:
sudo iperf3 -c <Private IP> -P 10 -w 128K -V
sudo iperf3 -c <Private IP> -P 10 -w 512K -V
sudo iperf3 -c <Private IP> -P 10 -w 1024K -V  

Verifique se há problemas no caminho de rede

Verifique o patch de rede para identificar o dispositivo ou salto específico que está causando problemas na rede:

• Verifique se há perda de pacotes ao longo do caminho entre os pares do Site-to-Site VPN.
• Verifique o throughput do túnel do Site-to-Site VPN.
• Verifique a configuração do roteador do gateway do cliente.
• Verifique a MTU mais baixa do caminho.

Verifique se há perda de pacotes ao longo do caminho entre pares do Site-to-Site VPN

Seu túnel do Site-to-Site VPN é uma comunicação criptografada entre pares. Porém, a rede subjacente pode estar apresentando uma perda que afeta a qualidade da comunicação criptografada. A perda de pacotes aumenta a latência e afeta diretamente o throughput.

Veja a seguinte equação e o exemplo:

Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):

Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})=  (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)

A medida do throughput é [Tamanho da janela TCP em bits] / [Latência (RTT) em segundos]. Veja os seguintes exemplo:

Eg.  64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput

Para verificar a perda de pacotes no caminho público entre pares do Site-to-Site VPN, use um teste ICMP, como MTR. Para obter mais informações sobre a instalação e o uso do MTR, consulte Como solucionar problemas de performance de rede entre instâncias do Windows ou Linux do EC2 em uma VPC e um host on-premises pelo gateway da Internet?

Veja os seguintes exemplo:

Observação: a saída do MTR neste exemplo inclui valores sem dados ou com 100% de perda. Isso indica que o dispositivo descartou o pacote com uma TTL de 0, mas não respondeu com uma mensagem de tempo ICMP excedida (Tipo 11, Código 0). Portanto, esses valores não indicam um problema.

 [ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss%   Snt   Last   Avg  Best  Wrst StDev  1.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  3.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  4.|-- 241.0.12.14                0.0%    20    0.4   0.4   0.3   0.8   0.1  5.|-- 240.0.204.2                0.0%    20    0.4   0.4   0.3   0.5   0.0  6.|-- 240.0.204.17               0.0%    20    0.4   0.4   0.3   0.5   0.0  7.|-- 240.0.204.5                0.0%    20    0.4   0.4   0.4   0.5   0.0  8.|-- 242.2.74.145               0.0%    20    1.2   4.0   0.4  23.9   5.7  9.|-- 52.93.29.71                0.0%    20    0.8   2.3   0.7   9.2   2.8 10.|-- 100.100.8.66               0.0%    20   10.8   2.5   0.7  12.8   4.0 11.|-- 100.92.53.85               0.0%    20   26.0  13.3  11.0  26.0   4.4 12.|-- 52.93.239.5                0.0%    20   11.6  12.8  11.4  23.7   2.7 13.|-- 52.95.1.159                0.0%    20   11.0  12.0  11.0  18.3   1.7 14.|-- 52.95.1.186                0.0%    20   11.5  14.1  11.2  32.6   5.9 15.|-- 15.230.39.135              0.0%    20   11.6  11.9  11.1  15.5   1.1 16.|-- 15.230.39.124              0.0%    20   11.7  12.8  11.2  27.2   3.6 17.|-- 108.166.252.38             0.0%    20   11.2  11.2  11.1  11.3   0.0 18.|-- 242.0.102.17               0.0%    20   12.1  12.4  11.2  23.9   2.8 19.|-- 108.166.252.35             0.0%    20   11.3  11.3  11.2  12.3   0.2 20.|-- 241.0.12.207               0.0%    20   11.2  11.3  11.1  13.2   0.5 21.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 22.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 23.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 24.|-- 100.65.30.129              0.0%    20   57.2  24.9  11.6  76.4  17.9 25.|-- 18.189.121.166             0.0%    20   11.3  11.8  11.2  17.6   1.6[ec2-user@ip-10-7-10-67 ~]$

Verifique o throughput do túnel do Site-to-Site VPN

Verifique se o throughput está ultrapassando o limite de 1,2 Gbps:

1. Abra o console do Amazon CloudWatch para ver as métricas do Site-to-Site VPN.

2. Escolha as métricas para TunnelDataIn e TunnelDataOut.

3. Em Estatística, escolha Soma e para Período, escolha 5 minutos.

4. Aplique o cálculo a seguir aos pontos de dados quando estiverem no pico. Nessa equação, m1 = TunnelDataIn e m2 = TunnelDataOut.

Observação: se o throughput for superior a 1,2 Gbps por um período prolongado, implemente dois túneis BGP com ECMP e gateway de trânsito.

(((m1+m2)/300)*8)/1000000

Verifique a configuração do roteador do gateway do cliente

Verifique o dispositivo de gateway do cliente para as seguintes configurações:

• Certifique-se de que não haja políticas ou políticas de elaboração que limitem o throughput.
• Redefina o sinalizador Don't Fragment (DF) nos pacotes IP.
• Certifique-se de fragmentar os pacotes IPSec antes de criptografá-los.
• Confirme se o gateway do cliente tem configuração de MSS para que os cabeçalhos IP, TCP, UDP ou ESP e a carga útil de dados não excedam 1500. Siga as diretrizes da MTU para o algoritmo de criptografia que você está usando. Para obter mais informações, consulte Práticas recomendadas para o dispositivo de gateway do cliente.

Verifique a MTU mais baixa do caminho

Teste o caminho para garantir que a MTU mais baixa do caminho seja a esperada:

Para fazer isso, ping -s 1460 <DESTINATION> -M do:

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms

Se um dispositivo ao longo do caminho não conseguir transportar a carga útil, ele retornará uma mensagem de caminho ICMP excedida pela MTU:

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500

Verifique se há erros comuns na aplicação

Verifique sua aplicação on-premises para ver os problemas mais comuns:

• Problemas de configuração da aplicação.
• Uso de segmentos paralelos na transferência de dados. Se você estiver observando o que parece ser mais lento do que o esperado no throughput do Site-to-Site VPN, use segmentos paralelos para confirmar o throughput fora da aplicação.
• Implementação do algoritmo de nova tentativa com recuo exponencial. Se você observar tempos limite ao chamar os serviços da AWS, use o algoritmo de nova tentativa com recuo exponencial.

Informações relacionadas

Rede aprimorada no Linux

Perguntas frequentes sobre o AWS VPN