Come posso risolvere una perdita di pacchetti su una connessione VPN?
Riscontro una perdita di pacchetti continua o intermittente e problemi di latenza elevata sulla mia connessione VPN.
Risoluzione
Verifica l'utilizzo delle risorse
Un utilizzo elevato di CPU, memoria o larghezza di banda della rete contribuisce alla perdita di pacchetti. Monitora le metriche di Amazon CloudWatch CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn e NetworkPacketsOut. Controlla l'utilizzo delle risorse sia sull'host di origine che su quello di destinazione.
Verifica la presenza di problemi di rete
Per verificare se c'è perdita o latenza di pacchetti ICMP o TCP, installa lo strumento di rete mtr sul computer on-premises locale. Inoltre, installa mtr su un'istanza Amazon Elastic Compute Cloud (Amazon EC2).
Per Amazon Linux, esegui il comando seguente:
sudo yum install mtr
Per Ubuntu, esegui il comando seguente:
sudo apt-get install mtr
Per Windows, usa WinMTR da SourceForge.
Nota: WinMTR non supporta l'MTR basato su TCP.
Verifica se c'è una perdita di pacchetti all'interno del tunnel VPN AWS. Verifica la connessione dall'host on-premises che utilizza il tunnel all'indirizzo IP privato della tua istanza Amazon EC2. Inoltre, verifica la connessione dal gateway del cliente on-premises all'indirizzo IP pubblico di ciascun tunnel. Se non puoi utilizzare mtr sul dispositivo gateway del cliente, utilizza un host con la stessa connessione internet del dispositivo gateway del cliente.
Importante: ottieni i risultati di mtr in entrambe le direzioni. Il percorso tra i nodi su una rete di indirizzi TCP e IP può cambiare quando si inverte la direzione.
Esegui il test seguente su un indirizzo IP privato con ICMP:
mtr -b -c 50 -rw Host_Instance_Private_IP
Esegui il test seguente su un indirizzo IP privato con TCP:
mtr -b -c 50 -rw -T -P 443 Host_Instance_Private_IP
Nota: nei comandi precedenti, sostituisci Host_instance_private_IP con l'indirizzo IP privato dell'istanza EC2 o dell'host on-premises e 443 con la tua porta.
Esegui il test seguente su un indirizzo IP pubblico con ICMP:
mtr -b -c 50 -rw AWS_Tunnel_Public_IP
Esegui i test seguenti su un indirizzo IP pubblico 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: nei comandi precedenti, sostituisci AWS_Tunnel_Public_IP con l'indirizzo IP pubblico del tunnel e 500 e 4500 con le tue porte UDP.
La perdita di pacchetti e un aumento del tempo di andata e ritorno (RTT) su un singolo hop sono normali; diventano un problema solo se li riscontri su ogni hop. L'output di esempio seguente mostra una perdita costante che inizia con l'hop 3 e continua fino all'hop finale:
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
L'esempio che segue mostra un test dell'indirizzo IP pubblico di un tunnel che utilizza la porta UDP 500. Tra gli hop 1 e 4, la colonna Loss% mostra una perdita percentuale. Tuttavia, poiché non vi sono perdite di pacchetti tra i hop 5 e 13, questa perdita di pacchetti non è da considerare significativa. La perdita di pacchetti tra l'hop 14 e l'hop finale è significativa perché è sostenuta e termina con una perdita del 100%. Il problema in questo esempio si verifica sull'hop 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
Verifica la presenza di problemi di latenza e routing
Lo strumento traceroute mostra il percorso dei dati attraverso la rete. Usa queste informazioni per individuare dove si verificano i ritardi.
Per installare traceroute su Amazon Linux, esegui il comando seguente:
sudo yum install traceroute
Per installare traceroute su Ubuntu, esegui il comando seguente:
sudo apt-get install traceroute
Per Windows, invece di traceroute, usa lo strumento tracert. Questo strumento è installato su tutti i computer Windows per impostazione predefinita. Nota che tracert non consente il tracciamento TCP. Per accedere a funzionalità complete, puoi installare lo strumento tracetcp.
Esegui i test seguenti tra l'indirizzo IP privato e pubblico della tua istanza Amazon EC2 e il tuo host on-premises.
Importante: ottieni risultati in entrambe le direzioni. Il percorso tra i nodi su una rete di indirizzi TCP e IP può cambiare quando si inverte la direzione.
Per Linux, usa il comando seguente:
sudo traceroute -T -p 80 Host_IP
Nota: sostituisci Host_IP con l'indirizzo IP privato dell'istanza EC2 o dell'host on-premises e 80 con la tua porta. Per una maggiore precisione, l'esempio precedente utilizza una traccia basata su TCP (T) per testare il percorso del traffico all'interno del tunnel. Per testare il percorso del traffico su internet, sostituisci Host_IP con l'indirizzo IP pubblico del tunnel.
Riceverai un output simile all'esempio seguente:
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
Questo output di esempio mostra gli hop intermedi senza risposta. Anche se i dispositivi non hanno risposto sulla porta 443 richiesta, non ci sono problemi perché la destinazione risponde comunque come previsto.
Per Windows, esegui tracert. Oppure, se hai installato tracetcp, esegui il comando PowerShell seguente:
tracetcp.exe Host_IP:80
Nota: sostituisci Host_IP con l'indirizzo IP privato dell'istanza EC2 o dell'host on-premises e 80 con la tua porta. Per una maggiore precisione, l'esempio precedente utilizza una traccia basata su TCP (T) per testare il percorso del traffico all'interno del tunnel. Per testare il percorso del traffico su internet, sostituisci Host_IP con l'indirizzo IP pubblico del tunnel.
Riceverai un output simile all'esempio seguente:
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.
Verifica le prestazioni TCP end-to-end
Usa hping3 per testare la perdita e la latenza dei pacchetti TCP end-to-end. Questo strumento consente di valutare le prestazioni TCP direttamente tra gli host.
Per installare hping3 su Amazon Linux, esegui questo comando:
sudo yum --enablerepo=epel install hping3
Per installare hping3 su Ubuntu, esegui questo comando:
sudo apt-get install hping3
Per eseguire hping3, esegui questo comando:
hping3 -S -c 50 -V Host_IP
Nota: sostituisci Host_IP con l'indirizzo IP privato dell'istanza EC2 o dell'host on-premises o con l'indirizzo IP pubblico del tunnel.
L'output di esempio seguente mostra un test sull'indirizzo IP pubblico di un endpoint VPN che utilizza la 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
Individua problemi nella rete o nell'applicazione
Acquisisci simultaneamente i pacchetti sia sull'istanza EC2 che sull'host on-premises quando si verifica il problema. Esamina i pacchetti acquisiti per individuare eventuali problemi nella rete o nell'applicazione.
Per acquisire i pacchetti per le istanze Linux, usa tcpdump.
Per installare tcpdump su Amazon Linux, esegui questo comando:
sudo yum install tcpdump
Per installare tcpdump su Ubuntu, esegui questo comando:
sudo apt-get install tcpdump
Per Windows, invece di tcpdump, usa Wireshark. Per scaricare lo strumento, vedi Download Wireshark sul sito web di Wireshark.
L'acquisizione dei pacchetti sarà simile all'esempio seguente:
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) Disattiva ECN
Se per le istanze Windows è attiva Explicit Congestion Notification (ECN), potresti riscontrare una perdita di pacchetti o problemi di prestazioni.
Per verificare se ECN è attiva, esegui questo comando PowerShell:
netsh interface tcp show global
Per disattivare ECN, esegui questo comando PowerShell:
netsh interface tcp set global ecncapability=disabled
Informazioni correlate
Amazon EC2 instance-level network performance metrics uncover new insights
How do I troubleshoot low transfer speed on my Site-to-Site VPN?
- Argomenti
- Networking & Content Delivery
- Lingua
- Italiano
