Come convalidare la velocità effettiva della VPN verso una rete virtuale

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione Linux prossima allo stato EOL (End of Life, fine del ciclo di vita). Prendere in considerazione l'uso e il piano di conseguenza. Per altre informazioni, vedere le linee guida per la fine della vita di CentOS.

Una connessione del gateway VPN consente di stabilire una connettività cross-premise sicura tra la rete virtuale in Azure e l'infrastruttura IT locale.

Questo articolo descrive come convalidare la velocità effettiva della rete dalle risorse locali a una macchina virtuale (VM) di Azure.

Nota

Questo articolo ha lo scopo di semplificare la diagnosi e la risoluzione dei problemi comuni. Se non si riesce a risolvere il problema tramite le informazioni seguenti, contattare il supporto tecnico.

Panoramica

La connessione del gateway VPN coinvolge i componenti seguenti:

• Dispositivo VPN locale (visualizzare un elenco di dispositivi VPN convalidati).
• Internet pubblico
• Gateway VPN di Azure
• Macchina virtuale di Azure

Il diagramma seguente mostra la connettività logica di una rete locale a una rete virtuale di Azure tramite VPN.

Calcolare il traffico in ingresso/in uscita massimo previsto

1. Determinare i requisiti di velocità effettiva di base dell'applicazione.
2. Determinare i limiti di velocità effettiva del gateway VPN di Azure. Per informazioni, vedere la sezione "SKU del gateway" di Informazioni su Gateway VPN.
3. Determinare le informazioni aggiuntive relative alla velocità effettiva della macchina virtuale di Azure in base alle dimensioni della macchina virtuale.
4. Determinare la larghezza di banda del provider di servizi Internet (ISP).
5. Calcolare la velocità effettiva prevista prendendo la larghezza di banda minima della macchina virtuale, Gateway VPN o ISP, misurata in megabit al secondo (/) diviso per otto (8). Questo calcolo offre megabyte al secondo.

Se la velocità effettiva calcolata non soddisfa i requisiti di velocità effettiva di base dell'applicazione, è necessario aumentare la larghezza di banda della risorsa identificata come collo di bottiglia. Per ridimensionare un gateway VPN di Azure, vedere Changing a gateway SKU (Modifica SKU del gateway). Per ridimensionare una macchina virtuale, vedere Ridimensionare una VM . Se non si verifica la larghezza di banda Internet prevista, è anche possibile contattare l'ISP.

Nota

Gateway VPN velocità effettiva è un'aggregazione di tutte le connessioni da sito a sito\da rete virtuale a rete virtuale o da punto a sito.

Convalidare la velocità effettiva della rete mediante gli strumenti di prestazioni

Questa convalida deve essere eseguita durante ore non indici, perché la saturazione della velocità effettiva del tunnel VPN durante i test non restituisce risultati accurati.

Lo strumento usato per questo test è iPerf, che è supportato sia su Windows sia su Linux e dispone di modalità client e server. Per le macchine virtuali di Windows è limitato a 3 Gbps.

Questo strumento non esegue operazioni di lettura/scrittura su disco, ma produce solo traffico TCP generato automaticamente da un'entità finale all'altra. Genera statistiche basate sulla sperimentazione che misura la larghezza di banda disponibile tra i nodi client e server. Quando si esegue il test tra due nodi, un nodo funge da server e l'altro funge da client. Al termine di questo test, è consigliabile invertire i ruoli dei nodi per testare sia il caricamento che il download della velocità effettiva in entrambi i nodi.

Scaricare iPerf

Eseguire il download di iPerf. Per dettagli, vedere la documentazione di iPerf.

Nota

I prodotti di terze parti descritti in questo articolo sono prodotti da aziende indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Eseguire iPerf (iperf3.exe)

1. Abilitare una regola NSG/ACL che consenta il traffico (per il test dell'indirizzo IP pubblico nella macchina virtuale di Azure).

2. In entrambi i nodi abilitare un'eccezione firewall per la porta 5001.

   Windows: eseguire questo comando come amministratore.

   netsh advfirewall firewall add rule name="Open Port 5001" dir=in action=allow protocol=TCP localport=5001
   

   Per rimuovere la regola al termine del test, eseguire questo comando:

   netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001
   

   Linux di Azure: le immagini Linux di Azure dispongono di firewall permissivi. Se è presente un'applicazione in ascolto su una porta, il traffico è consentito. Per le immagini personalizzate protette potrebbero essere necessarie porte aperte in modo esplicito. Firewall a livello di sistema operativo Linux comuni includono iptables, ufw o firewalld.

3. Sul nodo del server passare alla directory in cui è stato estratto iperf3.exe. Eseguire quindi iPerf in modalità server e impostarlo per l'ascolto sulla porta 5001 come comandi seguenti:

   cd c:\iperf-3.1.2-win65
   
   iperf3.exe -s -p 5001
   

   Nota

   La porta 5001 è personalizzabile per tenere conto di particolari restrizioni del firewall nell'ambiente in uso.

4. Nel nodo client passare alla directory in cui è stato estratto lo strumento iperf e quindi eseguire questo comando:

   iperf3.exe -c <IP of the iperf Server> -t 30 -p 5001 -P 32
   

   Il client indirizza 30 secondi di traffico sulla porta 5001 al server. Il flag '-P' indica che si stanno effettuando 32 connessioni simultanee al nodo del server.

   La schermata seguente mostra l'output di questo esempio:

   

5. (FACOLTATIVO) Per mantenere i risultati del test, eseguire questo comando:

   iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32  >> output.txt
   

6. Dopo aver completato i passaggi precedenti, eseguire gli stessi passaggi con i ruoli invertiti, in modo che il nodo del server sia ora il nodo client e viceversa.

Nota

Iperf non è l'unico strumento. NTTTCP è una soluzione alternativa per i test.

Testare le macchine virtuali che eseguono Windows

Caricare Latte.exe nelle macchine virtuali

Scaricare la versione più recente di Latte.exe

Prendere in considerazione l'inserimento di Latte.exe in una cartella separata, ad esempio c:\tools

Consenti Latte.exe tramite Windows Firewall

Nel ricevitore creare una regola Consenti in Windows Firewall per consentire l'arrivo del traffico Latte.exe. È più semplice consentire l'intero programma di Latte.exe in base al nome anziché consentire porte TCP specifiche in ingresso.

Consenti Latte.exe tramite Windows Firewall come questo

netsh advfirewall firewall add rule program=<PATH>\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY

Ad esempio, se è stato copiato latte.exe nella cartella "c:\tools", si tratta del comando

netsh advfirewall firewall add rule program=c:\tools\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY

Eseguire test di latenza

Avviare latte.exe nel ricevitore (eseguire da CMD, non da PowerShell):

latte -a <Receiver IP address>:<port> -i <iterations>

Circa 65.000 iterazioni sono sufficienti per restituire risultati rappresentativi.

Qualsiasi numero di porta disponibile è corretto.

Se la macchina virtuale ha un indirizzo IP 10.0.0.4, l'aspetto sarà simile al seguente

latte -c -a 10.0.0.4:5005 -i 65100

Avviare latte.exe nel edizione Standard NDER (eseguire da CMD, non da PowerShell)

latte -c -a <Receiver IP address>:<port> -i <iterations>

Il comando risultante è lo stesso del ricevitore, ad eccezione dell'aggiunta di "-c" per indicare che si tratta del "client" o del mittente

latte -c -a 10.0.0.4:5005 -i 65100

Attendere i risultati. A seconda della distanza tra le macchine virtuali, il completamento potrebbe richiedere alcuni minuti. Prendere in considerazione l'avvio con un minor numero di iterazioni per verificare l'esito positivo prima di eseguire test più lunghi.

Testare le macchine virtuali che eseguono Linux

Usare SockPerf per testare le macchine virtuali.

Installare SockPerf nelle macchine virtuali

Nelle macchine virtuali Linux (sia edizione Standard NDER che RECEIVER) eseguire questi comandi per preparare SockPerf nelle macchine virtuali:

CentOS/RHEL - Installare GIT e altri strumenti utili

sudo yum install gcc -y -q sudo yum install git -y -q sudo yum install gcc-c++ -y sudo yum install ncurses-devel -y sudo yum install -y automake

Ubuntu - Installare GIT e altri strumenti utili

sudo apt-get install build-essential -y sudo apt-get install git -y -q sudo apt-get install -y autotools-dev sudo apt-get install -y automake

Bash - all

Dalla riga di comando di bash (presuppone che git sia installato)

git clone https://github.com/mellanox/sockperf cd sockperf/ ./autogen.sh ./configure --prefix=

Rendere più lento, può richiedere alcuni minuti

make

Effettuare l'installazione è veloce

sudo make install

Eseguire SockPerf nelle macchine virtuali

Comandi di esempio dopo l'installazione. Server/ricevitore: presuppone che l'INDIRIZZO IP del server sia 10.0.0.4

sudo sockperf sr --tcp -i 10.0.0.4 -p 12345 --full-rtt

Client: presuppone che l'INDIRIZZO IP del server sia 10.0.0.4

sockperf ping-pong -i 10.0.0.4 --tcp -m 1400 -t 101 -p 12345 --full-rtt

Nota

Assicurarsi che non siano presenti hop intermedi (ad esempio, Appliance virtuale) durante il test della velocità effettiva tra la macchina virtuale e il gateway. Se sono presenti risultati scarsi (in termini di velocità effettiva complessiva) provenienti dai test iPERF/NTTTCP precedenti, fare riferimento a questo articolo per comprendere i fattori chiave alla base delle possibili cause radice del problema:

In particolare, l'analisi delle tracce di acquisizione di pacchetti (Wireshark/Network Monitor) raccolte in parallelo dal client e dal server durante questi test aiutano nelle valutazioni delle prestazioni non ottimali. Queste tracce possono includere perdita di pacchetti, latenza elevata, dimensioni MTU. frammentazione, finestra TCP 0, frammenti fuori ordine e così via.

Risolvere i problemi di esecuzione lenta della copia dei file

Anche se la velocità effettiva complessiva valutata con i passaggi precedenti (iPERF/NTTTCP/etc.) era buona, si potrebbe riscontrare un rallentamento della gestione dei file quando si usa Esplora risorse o trascinando e rilasciando una sessione RDP. Questo problema è in genere dovuto a uno o a entrambi i fattori seguenti:

• Le applicazioni di copia file, ad esempio Esplora risorse e RDP, non usano più thread durante la copia dei file. Per prestazioni ottimali, usare un'applicazione per la copia dei file multithread, ad esempio Richcopy, per copiare i file a 16 o 32 thread. Per modificare il numero di thread per la copia dei file in Richcopy, fare clic su Azione>Opzioni copia>Copia dei file.

  
  

  Nota

  Non tutte le applicazioni funzionano allo stesso modo e non tutte le applicazioni/processi usano tutti i thread. Se si esegue il test, è possibile che alcuni thread siano vuoti e non forniscano risultati accurati sulla velocità effettiva. Per controllare le prestazioni di trasferimento dei file dell'applicazione, usare multithread aumentando il numero di thread in successione o riducendo al fine di trovare la velocità effettiva ottimale dell'applicazione o del trasferimento di file.

• Velocità di lettura/scrittura disco macchina virtuale insufficiente. Per altre informazioni, vedere Risoluzione dei problemi di Archiviazione di Azure.

Interfaccia con connessione rivolta all'esterno del dispositivo locale

Sono state menzionate le subnet degli intervalli locali che si vuole che Azure raggiunga tramite VPN nel gateway di rete locale. Contemporaneamente, definire lo spazio di indirizzi della rete virtuale in Azure per il dispositivo locale.

• Gateway basato su route: i criteri o il selettore di traffico per le VPN basate su route sono configurati come any-to-any (o caratteri jolly).

• Gateway basato su criteri: le VPN basate su criteri crittografano e indirizzano i pacchetti tramite tunnel IPsec in base alle combinazioni di prefissi di indirizzi tra la rete locale e la rete virtuale di Azure. I criteri (o selettore di traffico) vengono in genere definiti come un elenco di accesso nella configurazione VPN.

• Connessioni UsePolicyBasedTrafficSelector : ("UsePolicyBasedTrafficSelectors" per $True in una connessione configura il gateway VPN di Azure per connettersi al firewall VPN basato su criteri in locale. Se si abilita PolicyBasedTrafficSelectors, è necessario assicurarsi che il dispositivo VPN disponga dei selettori di traffico corrispondenti definiti con tutte le combinazioni dei prefissi di rete locale (gateway di rete locale) da e verso i prefissi della rete virtuale di Azure, anziché da qualsiasi a qualsiasi.

La configurazione inappropriata può causare frequenti disconnessioni all'interno del tunnel, cadute di pacchetti, velocità effettiva non valida e latenza.

Controllare la latenza

È possibile controllare la latenza usando gli strumenti seguenti:

• WinMTR
• TCPTraceroute
• ping e psping (questi strumenti possono fornire una stima valida di RTT, ma non possono essere usati in tutti i casi).

Se si nota un picco di latenza elevata in uno qualsiasi degli hop prima di entrare nel backbone della rete MS, è consigliabile procedere con ulteriori indagini con il provider di servizi Internet.

Se si nota un picco di latenza insolito e elevato dagli hop all'interno di "msn.net", contattare il supporto ms per ulteriori indagini.

Passaggi successivi

Per altre informazioni o assistenza, vedere il collegamento seguente:

• Supporto tecnico Microsoft