Validación del rendimiento de la VPN en una red virtual

Una conexión a la puerta de enlace de la VPN le permite establecer una conectividad segura y entre entornos locales entre su red virtual dentro de Azure y la infraestructura local de TI.

Este artículo muestra cómo validar el rendimiento de red de los recursos locales en una máquina virtual de Azure.

Nota:

Este artículo se ha creado para ayudar a diagnosticar problemas comunes y solucionarlos. Si no puede resolver el problema mediante el uso de la siguiente información, póngase en contacto con soporte técnico.

Información general

La conexión a la puerta de enlace de la VPN afecta a los siguientes componentes:

• Dispositivo VPN local (vea una lista de dispositivos VPN validados).
• Internet público
• Azure VPN Gateway
• Azure VM

El siguiente diagrama muestra la conectividad lógica de una red local en una red virtual de Azure a través de VPN.

Cálculo de la entrada/salida máxima esperada

1. Determine los requisitos de rendimiento de la línea de base de la aplicación.
2. Establezca los límites de rendimiento de la puerta de enlace de VPN de Azure. Para obtener ayuda, consulte la sección "SKU de puerta de enlace" de Acerca de VPN Gateway.
3. Determine la Guía de rendimiento de la máquina virtual de Azure para el tamaño de la máquina virtual.
4. Establezca el ancho de banda del proveedor de servicios de Internet (ISP).
5. Calcule el rendimiento esperado tomando el menor ancho de banda de la máquina virtual, VPN Gateway o ISP, que se mide en megabits por segundo (/) dividido por ocho (8). Este cálculo proporciona megabytes por segundo.

Si el rendimiento calculado no cumple con los requisitos de rendimiento de línea de base de la aplicación, debe aumentar el ancho de banda del recurso que identificó como el cuello de botella. Para cambiar el tamaño de una instancia de Azure VPN Gateway, vea Cambio de una SKU de puerta de enlace. Para cambiar el tamaño de una máquina virtual, vea Cambio del tamaño de una VM. Si no obtiene el ancho de banda de Internet previsto, también puede ponerse en contacto con el ISP.

Nota:

El rendimiento de VPN Gateway es un agregado de todas las conexiones de sitio a sitio, de red virtual a red virtual o de punto a sitio.

Validación del rendimiento de red mediante el uso de herramientas de rendimiento

Esta validación debe realizarse durante las horas de entrada, ya que la saturación del rendimiento del túnel VPN durante las pruebas no proporciona resultados precisos.

La herramienta que se usa para esta prueba es iPerf, que funciona en Windows y Linux, y tiene los modos de cliente y servidor. Está limitada a 3 GB/s para máquinas virtuales de Windows.

Esta herramienta no lleva a cabo operaciones de lectura/escritura en el disco. Solo se produce el tráfico TCP generado automáticamente de un extremo a otro. Genera estadísticas basadas en la experimentación que mide el ancho de banda disponible entre los nodos de cliente y servidor. Cuando se realiza la prueba entre dos nodos, un nodo actúa como servidor y el otro nodo como cliente. Una vez completada esta prueba, se recomienda que invierta los roles de los nodos para probar el rendimiento de carga y descarga en ambos nodos.

Descarga de iPerf

Descargue iPerf. Para más información, vea la documentación de Ambari.

Nota:

Los productos de terceros que se tratan en este artículo están fabricados por compañías independientes de Microsoft. Microsoft no otorga ninguna garantía, implícita o de otro tipo, sobre el rendimiento o la confiabilidad de estos productos.

Ejecución de iPerf (iperf3.exe)

1. Habilite una regla NSG/ACL que permita el tráfico (para la prueba de la dirección IP pública en la máquina virtual de Azure).

2. En ambos nodos, habilite una excepción de firewall para el puerto 5001.

   Windows: Ejecute el comando siguiente como administrador:

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

   Para quitar la regla cuando la prueba esté completa, ejecute este comando:

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

   Azure Linux: las imágenes de Azure Linux tienen firewalls permisivos. Si hay una aplicación que escucha en un puerto, se permite el tráfico. Las imágenes personalizadas que se protegen pueden necesitar puertos abiertos de forma explícita. Los firewalls de nivel de sistema operativo Linux comunes incluyen iptables, ufw, o firewalld.

3. En el nodo de servidor, cambie al directorio donde se extrae iperf3.exe. A continuación, ejecute iPerf en el modo de servidor y configúrela para que escuche el puerto 5001 como se indica a continuación:

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

   Nota:

   El puerto 5001 se puede personalizar para tener en cuenta las restricciones particulares del firewall de su entorno.

4. En el nodo de cliente, cambie al directorio donde se extrae la herramienta iperf y luego ejecute el siguiente comando:

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

   El cliente dirige 30 segundos de tráfico en el puerto 5001 al servidor. La marca "-P" indica que estamos realizando 32 conexiones simultáneas al nodo de servidor.

   La siguiente pantalla muestra el resultado de este ejemplo:

   

5. (OPCIONAL) Para conservar los resultados de pruebas, ejecute este comando:

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

6. Después de completar los pasos anteriores, ejecute los mismos pasos con los roles invertidos, de manera que el nodo servidor será ahora el nodo cliente y viceversa.

Nota:

Iperf no es la única herramienta. NTTTCP es una solución alternativa para la realización de pruebas.

Prueba de máquinas virtuales que ejecutan Windows

Cargue Latte.exe en las máquinas virtuales.

Descargue la versión más reciente de Latte.exe.

Considere la posibilidad de colocar Latte.exe en una carpeta independiente, como c:\tools.

Permitir Latte.exe mediante el firewall de Windows

En el receptor, cree una regla Permitir en el Firewall de Windows para permitir la recepción de tráfico de Latte.exe. Es más fácil permitir todo el programa Latte.exe por su nombre en lugar de determinados puertos TCP de entrada.

Permita Latte.exe a través del Firewall de Windows de la siguiente forma:

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

Por ejemplo, si ha copiado Latte.exe a la carpeta "c:\tools", este sería el comando

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

Ejecución de pruebas de latencia

Inicie Latte.exe en el receptor (se ejecuta desde CMD, no desde PowerShell):

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

Es suficiente alrededor de 65 000 iteraciones para obtener unos resultados representativos.

Cualquier número de puerto disponible es válido.

Si la máquina virtual tiene la dirección IP 10.0.0.4, sería similar al siguiente:

latte -c -a 10.0.0.4:5005 -i 65100

Inicie Latte.exe en el emisor (se ejecuta desde CMD, no desde PowerShell).

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

El comando resultante es el mismo que en el receptor, excepto con la adición de "-c" para indicar que se trata del "cliente" o del emisor.

latte -c -a 10.0.0.4:5005 -i 65100

Espere a que se muestren los resultados. Dependiendo de la distancia que haya entre las máquinas virtuales, podría llevar unos minutos completarlos. Considere comenzar con menos iteraciones para probar si se ha realizado correctamente antes de ejecutar pruebas más largas.

Prueba de máquinas virtuales que ejecutan Linux

Use SockPerf para probar las máquinas virtuales.

Instalación de SockPerf en las máquinas virtuales

En las máquinas virtuales Linux (tanto en el emisor como en el receptor), ejecute estos comandos para preparar SockPerf en las máquinas virtuales:

RHEL: instalación de GIT y otras herramientas útiles

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: instalación de GIT y otras herramientas útiles

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: todo

Desde la línea de comandos de bash (asume que git está instalado)

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

"Make" es más lento, puede tardar varios minutos

make

"Make install" es rápido

sudo make install

Ejecución de SockPerf en las máquinas virtuales

Comandos de ejemplo después de la instalación. Servidor o receptor: asume que la dirección IP del servidor es 10.0.0.4

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

Cliente: asume que la dirección IP del servidor es 10.0.0.4

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

Nota:

Asegúrese de que no haya saltos intermedios (por ejemplo, una aplicación virtual) durante la prueba de rendimiento entre la máquina virtual y la puerta de enlace. Si los resultados de las pruebas de iPERF/NTTTCP anteriores no son satisfactorios (en términos de rendimiento total), consulte este artículo para conocer los factores clave que subyacen a las posibles causas principales del problema:

En particular, el análisis de seguimientos de captura de paquetes (Wireshark/Monitor de red) recopilados en paralelo desde el cliente y el servidor durante esas pruebas ayudan en las evaluaciones del rendimiento incorrecto. Estos seguimientos pueden incluir la pérdida de paquetes, la latencia alta, el tamaño de MTU, la fragmentación, la ventana TCP 0, fragmentos desordenados, etc.

Solución de problemas de copia de archivos lenta

Incluso si el rendimiento global evaluado con los pasos anteriores (iPERF/NTTTCP/etc.) era correcto, es posible que experimente una copia lenta de los archivos al usar el Explorador de Windows o al arrastrar y soltar en una sesión de RDP. Este problema suele ser debido a uno o ambos de los siguientes factores:

• Las aplicaciones de copia de archivos, como el Explorador de Windows y RDP, no usan varios subprocesos al copiar archivos. Para mejorar el rendimiento, utilice una aplicación de copia de archivos de multiproceso como Richcopy para copiar archivos mediante 16 o 32 subprocesos. Para cambiar el número de subprocesos de copia de archivos en Richcopy, haga clic en Acción>Opciones de copia>Copia de archivos.

  
  

  Nota:

  No todas las aplicaciones funcionan de la misma manera y no todas las aplicaciones o procesos utilizan todos los subprocesos. Si ejecuta la prueba, puede ver que algunos subprocesos están vacíos y no proporcionarán resultados precisos de rendimiento. Para comprobar el rendimiento de la transferencia de archivos de la aplicación, utilice varios subprocesos aumentando el número de subprocesos sucesivamente o disminuyéndolo para encontrar el rendimiento óptimo de la aplicación o de la transferencia de archivos.

• Velocidad de lectura/escritura del disco de VM insuficiente. Para más información, vea Solución de problemas de Azure Storage.

Interfaz con orientación externa del dispositivo local

Se han mencionado las subredes de los intervalos locales a las que le gustaría que Azure llegara a través de VPN en la puerta de enlace de la red local. A la vez, defina el espacio de direcciones de la red virtual de Azure en el dispositivo local.

• Puerta de enlace basada en rutas: La directiva o el selector de tráfico para las VPN basadas en enrutamiento se configura como conectividad de tipo cualquiera a cualquier (o caracteres comodín).

• Puerta de enlace basada en directivas: Las VPN basadas en directivas cifran y dirigen los paquetes a través de túneles de IPsec basados en las combinaciones de prefijos de dirección entre su red local y la red virtual de Azure. Normalmente, la directiva (o selector de tráfico) se define como una lista de acceso en la configuración de la VPN.

• Conexiones de UsePolicyBasedTrafficSelector: ("UsePolicyBasedTrafficSelectors" para $True en una conexión configura la puerta de enlace de VPN de Azure para conectarse al firewall de VPN basado en directivas en el entorno local. Si habilita PolicyBasedTrafficSelectors, debe asegurarse de que el dispositivo VPN tiene los selectores de tráfico coincidentes definidos con todas las combinaciones de sus prefijos de red local (puerta de enlace de red local) hacia y desde los prefijos de red virtual de Azure, en lugar de cualquiera a cualquiera.

Una configuración inadecuada puede dar lugar a desconexiones frecuentes dentro del túnel, caídas de paquetes, rendimiento deficiente y latencia.

Comprobación de la latencia

Puede comprobar la latencia con las siguientes herramientas:

• WinMTR
• TCPTraceroute
• ping y psping (estas herramientas pueden proporcionar una buena estimación de RTT, pero no se pueden usar en todos los casos).

Si observa un pico de latencia alta en cualquiera de los saltos antes de entrar en la red troncal de Microsoft, es posible que desee realizar más investigaciones con su proveedor de servicios de Internet.

Si se detecta un pico de latencia grande e inusual en los saltos en "msn.net", póngase en contacto con el soporte técnico de Microsoft para que lo investiguen.

Pasos siguientes

Para más información, consulte el vínculo siguiente:

• Ayuda y soporte técnico de Microsoft