Perché la mia applicazione presenta problemi di latenza e prestazioni quando utilizzo una VPN da sito a sito?

Risoluzione

Se riscontri problemi di prestazioni o di latenza quando utilizzi la VPN da sito a sito per accedere alle risorse, segui questi passaggi per la risoluzione dei problemi:

• Isola i sistemi di origine e di destinazione uno alla volta.
• Controlla il percorso di rete per verificare la presenza di eventuali problemi che potrebbero causare latenza.
• Controlla la tua applicazione per verificare la presenza di errori comuni che causano problemi di latenza.

Isola i tuoi sistemi di origine e di destinazione

Per mitigare i problemi di prestazioni tra l'applicazione locale e AWS, isola innanzitutto i sistemi di origine e di destinazione. Quindi, utilizza gli strumenti di rete per verificare eventuali perdite e latenze all'esterno dell'applicazione che potrebbero influire direttamente sulle prestazioni.

1. Cambia origine e destinazione. Usa una fonte diversa e una destinazione diversa e controlla se il problema persiste dopo ogni modifica. Quindi, controlla il dispositivo per determinare se c'è un problema di configurazione del sistema operativo (OS) o un altro problema.

2. Esegui un test delle capacità di larghezza di banda UDP. I problemi di prestazioni possono indicare problemi di velocità di trasmissione effettiva, quindi usa lo strumento iperf3 per verificare la larghezza di banda disponibile. Esegui questo test in modo bidirezionale. Il seguente esempio di test UDP utilizza lo strumento iperf3.

Nota: -i si riferisce all'intervallo, -u si riferisce a UDP, -b si riferisce alla larghezza di banda (da regolare di conseguenza), -p si riferisce alla porta UDP e -v si riferisce a verbose.

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

Nota: Assicurati che il tuo credito di larghezza di banda sia disponibile per l'istanza Amazon Elastic Compute Cloud (Amazon EC2) che stai utilizzando. In alternativa, prova a utilizzare un'istanza di dimensioni maggiori, quindi esegui nuovamente il test.

3. Usa iperf3 per eseguire un test di velocità di trasmissione effettiva TCP sulla tua VPN da sito a sito. Esegui questo test in modo bidirezionale. Guarda il seguente esempio:

Nota: Per prestazioni ottimali, prova diverse dimensioni delle finestre di ricezione TCP per testare i buffer di memoria di origine e di destinazione quando aumenti le dimensioni dell'istanza.

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  

Controlla il percorso di rete per verificare la presenza di eventuali problemi

Controlla la patch di rete per identificare l'hop o il dispositivo specifico che sta causando problemi sulla rete:

• Controlla la perdita di pacchetti lungo il percorso tra i peer VPN da sito a sito.
• Verifica la velocità del tunnel VPN da sito a sito.
• Verificare la configurazione del router gateway del cliente.
• Controlla l'MTU più basso del percorso.

Verifica la perdita di pacchetti lungo il percorso tra peer VPN da sito a sito

Il tuo tunnel VPN da sito a sito è una comunicazione crittografata tra peer. Tuttavia, la rete sottostante potrebbe presentare una perdita che influisce sulla qualità della comunicazione crittografata. La perdita di pacchetti aumenta la latenza e influisce direttamente sulla velocità di trasmissione effettiva.

Vedi la seguente equazione ed esempio:

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)

La misura del throughput è [Dimensione finestra TCP in bit] / [Latenza (RTT) in secondi]. Guarda il seguente esempio:

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

Per verificare la perdita di pacchetti sul percorso pubblico tra peer VPN da sito a sito, utilizza un test ICMP, come MTR. Per maggiori dettagli, consulta Come posso risolvere i problemi relativi alle prestazioni di rete tra le istanze EC2 Linux o Windows in un VPC e un host on-premise tramite il gateway Internet?

Guarda il seguente esempio:

Nota: L'output MTR in questo esempio include valori senza dati o con perdita del 100%. Ciò indica che il dispositivo ha eliminato il pacchetto con un TTL pari a 0, ma non ha risposto con un messaggio ICMP di tempo superato (tipo 11, codice 0). Quindi, questi valori non indicano un 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 ~]$

Verifica la velocità di trasmissione effettiva del tunnel VPN da sito a sito

Verifica se la tua velocità di trasmissione supera il limite di 1,2 Gbps:

1. Apri la console Amazon CloudWatch per visualizzare i parametri VPN da sito a sito.

2.    Scegli le metriche per TunnelDataIn e TunnelDataOut.

3. Per Statistica, scegli Somma, quindi per Periodo, scegli 5 minuti.

4. Applica il seguente calcolo ai punti dati al loro picco. In questa equazione, m1 = TunnelDataIn e m2 = TunnelDataOut.

Nota: Se la velocità di trasmissione è superiore a 1,2 Gbps per un periodo prolungato, implementa due tunnel BGP con ECMP e gateway di transito.

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

Verifica la configurazione del router gateway del cliente

Controlla il dispositivo gateway del tuo cliente per le seguenti configurazioni:

• Assicurati che non vi siano policy di controllo o definizione che limitino la produttività.
• Reimposta il flag Don't Fragment (DF) nei pacchetti IP.
• Assicurati di frammentare i pacchetti IPSec prima di crittografarli.
• Verifica che il gateway del cliente abbia una configurazione MSS in modo che le intestazioni IP, TCP, UDP o ESP e il payload dei dati non superino 1500. Segui le linee guida MTU per l'algoritmo di crittografia che stai utilizzando. Per ulteriori informazioni, consulta Procedure ottimali per il dispositivo gateway del cliente.

Controlla l'MTU più basso del percorso

Prova il percorso per assicurarti che l'MTU più basso del percorso sia quello previsto:

Per fare ciò, 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 un dispositivo lungo il percorso non è in grado di trasportare il payload, restituisce un messaggio di superamento del percorso ICMP 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

Verifica la presenza di errori comuni nella tua applicazione

Controlla la tua applicazione locale per i problemi più comuni:

• Problemi di configurazione dell'applicazione.
• Utilizzo di thread paralleli nel trasferimento dei dati. Se stai riscontrando una velocità di trasmissione VPN da sito a sito che sembra essere più lenta del previsto, utilizza thread paralleli per confermare la velocità di trasmissione indipendentemente dall'applicazione.
• Implementazione dell'algoritmo di riprova con backoff esponenziale. Se vedi dei timeout quando chiami i servizi AWS, utilizza l'algoritmo di retry con backoff esponenziale.

Informazioni correlate

Rete migliorata su Linux

Domande frequenti su AWS VPN