¿Cómo puedo solucionar los problemas de pérdida de paquetes en mi conexión VPN?

Resolución

Comprobación de la utilización de recursos

El uso elevado de la CPU, la memoria o el ancho de banda de la red contribuye a la pérdida de paquetes. Supervisa CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn, NetworkPacketsOut y las métricas de Amazon CloudWatch. Comprueba la utilización de los recursos en los hosts de origen y destino.

Comprobación de problemas de red

Para comprobar si hay latencia o pérdida de paquetes ICMP o TCP, instala la herramienta de red mtr en la máquina local. Instala también mtr en una instancia de Amazon Elastic Compute Cloud (Amazon EC2).

Para ara Amazon Linux, ejecuta el siguiente comando:

sudo yum install mtr

Para Ubuntu, ejecuta el siguiente comando:

sudo apt-get install mtr

Para Windows, usa WinMTR de SourceForge.

Nota: WinMTR no admite MTR basado en TCP.

Comprueba si hay pérdida de paquetes dentro del túnel VPN de AWS. Prueba la conexión desde el host local que utiliza el túnel a la dirección IP privada de tu instancia de Amazon EC2. Además, prueba la conexión desde la puerta de enlace de cliente local a la dirección IP pública de cada túnel. Si no puedes usar mtr en tu dispositivo de puerta de enlace de cliente, utiliza un host con la misma conexión a Internet que el dispositivo de puerta de enlace de cliente.

Importante: Obtén los resultados de mtr en ambas direcciones. La ruta entre los nodos de una red de direcciones IP y TCP puede cambiar al invertir la dirección.

Ejecuta la siguiente prueba en una dirección IP privada con ICMP:

mtr -b -c 50 -rw Host_Instance_Private_IP

Ejecuta la siguiente prueba en una dirección IP privada con TCP:

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

Nota: En los comandos anteriores, sustituye Host_instance_private_IP por la dirección IP privada de tu instancia de EC2 o del host local, y 443 por tu puerto.

Ejecuta la siguiente prueba en una dirección IP pública con ICMP:

mtr -b -c 50 -rw AWS_Tunnel_Public_IP

Ejecuta las siguientes pruebas en una dirección IP pública con 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

Nota: En los comandos anteriores, sustituye AWS_Tunnel_Public_IP por la dirección IP pública del túnel y 500 y 4500 por los puertos UDP.

Se espera una pérdida de paquetes y un aumento del tiempo de ida y vuelta (RTT) en un solo salto. La pérdida de paquetes y el aumento del RTT solo son problemas si los ves en cada salto. En el siguiente resultado de ejemplo se muestra una pérdida constante que comienza en el salto 3 y continúa hasta el 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

En el siguiente ejemplo se muestra una prueba de la dirección IP pública de un túnel que usa el puerto UDP 500. Entre los saltos 1 y 4, la columna Loss% muestra un porcentaje de pérdida. Sin embargo, dado que no hay pérdida de paquetes entre los saltos 5 y 13, esta pérdida no se considera una pérdida de paquetes significativa. La pérdida entre el salto 14 y el salto final muestra una pérdida significativa de paquetes porque es una pérdida sostenida que termina en una pérdida del 100 %. El problema de este ejemplo se produce en el 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

Comprobación de problemas de latencia y enrutamiento

La herramienta traceroute muestra la ruta que siguen los datos a través de la red. Utiliza esta información para identificar dónde se producen los retrasos.

Para instalar traceroute en Amazon Linux, ejecuta el siguiente comando:

sudo yum install traceroute

Para instalar traceroute en Ubuntu, ejecuta el siguiente comando:

sudo apt-get install traceroute

Para Windows, en lugar de traceroute, usa la herramienta tracert. Esta herramienta se instala en todas las máquinas Windows de forma predeterminada. Ten en cuenta que tracert no permite el rastreo de TCP. Para obtener todas las capacidades, puedes instalar la herramienta tracetcp.

Ejecuta las siguientes pruebas entre la dirección IP privada y pública de tu instancia de Amazon EC2 y tu host local.

Importante: Obtén resultados en ambas direcciones. La ruta entre los nodos de una red de direcciones IP y TCP puede cambiar al invertir la dirección.

Para Linux, utiliza el siguiente comando:

sudo traceroute -T -p 80 Host_IP

Nota: Sustituye Host_IP por la dirección IP privada de tu instancia de EC2 o del host local y 80 por tu puerto. Para una mayor precisión, el ejemplo anterior utiliza un rastreo (T) basado en TCP para probar la ruta del tráfico dentro del túnel. Para probar la ruta del tráfico a través de Internet, sustituye Host_IP por la dirección IP pública del túnel.

Recibirás un resultado similar al siguiente ejemplo:

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 resultado de ejemplo muestra saltos intermedios sin respuesta. Aunque los dispositivos no respondieron en el puerto 443 solicitado, no hay ningún problema porque el destino sigue respondiendo según lo esperado.

Para Windows, ejecuta tracert. O bien, si has instalado tracetcp, ejecuta el siguiente comando de PowerShell:

tracetcp.exe Host_IP:80

Nota: Sustituye Host_IP por la dirección IP privada de tu instancia de EC2 o del host local y 80 por tu puerto. Para una mayor precisión, el ejemplo anterior utiliza un rastreo (T) basado en TCP para probar la ruta del tráfico dentro del túnel. Para probar la ruta del tráfico a través de Internet, sustituye Host_IP por la dirección IP pública del túnel.

Recibirás un resultado similar al siguiente ejemplo:

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.

Prueba del rendimiento de TCP de extremo a extremo

Usa hping3 para probar la latencia y la pérdida de paquetes TCP de extremo a extremo. Esta herramienta te permite evaluar el rendimiento de TCP directamente entre los hosts.

Para instalar hping3 en Amazon Linux, ejecuta el siguiente comando:

sudo yum --enablerepo=epel install hping3

Para instalar hping3 en Ubuntu, ejecuta el siguiente comando:

sudo apt-get install hping3

Para ejecutar hping3, ejecuta el siguiente comando:

hping3 -S -c 50 -V Host_IP

Nota: Sustituye Host_IP por la dirección IP privada de tu instancia de EC2 o del host local, o por la dirección IP pública del túnel.

En el siguiente resultado de ejemplo se muestra una prueba con la dirección IP pública de un punto de enlace de VPN que usa el puerto 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

Identificación de problemas con la red o la aplicación

Obtén capturas de paquetes simultáneas tanto en la instancia de EC2 como en el host local cuando se produzca el problema. Utiliza la captura de paquetes para identificar problemas con la red o la aplicación.

Para obtener una captura de paquetes para instancias de Linux, usa tcpdump.

Para instalar tcpdump en Amazon Linux, ejecuta el siguiente comando:

sudo yum install tcpdump

Para instalar tcpdump en Ubuntu, ejecuta el siguiente comando:

sudo apt-get install tcpdump

Para Windows, en lugar de tcpdump, usa Wireshark. Para descargar la herramienta, consulta Descargar Wireshark en el sitio web de Wireshark.

La captura de paquetes tiene un aspecto similar al siguiente ejemplo:

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=

(Solo Windows) Desactivación de ECN

Si la notificación explícita de congestión (ECN) está activada para tus instancias de Windows, es posible que experimentes problemas de rendimiento o pérdida de paquetes.

Para comprobar si ECN está activada, ejecuta el siguiente comando de PowerShell:

netsh interface tcp show global

Para desactivar ECN, ejecuta el siguiente comando de PowerShell:

netsh interface tcp set global ecncapability=disabled

Información relacionada

¿Por qué mi aplicación tiene problemas de latencia y rendimiento cuando utilizo una VPN de sitio a sitio?

Las métricas de rendimiento de red a nivel de instancia de Amazon EC2 revelan nueva información

¿Cómo soluciono los problemas de baja velocidad de transferencia en mi VPN de sitio a sitio?