Compartilhar via

Como validar a taxa de transferência VPN para uma rede virtual

  • Artigo

Uma conexão de gateway de VPN permite que você estabeleça conectividade entre instalações segura entre a sua Rede Virtual do Azure e sua infraestrutura de TI local.

Este artigo mostra como validar a taxa de transferência de rede dos recursos locais para uma máquina virtual (VM) do Azure.

Observação

Este artigo destina-se a ajudar a diagnosticar e corrigir problemas comuns. Se você não conseguir solucionar o problema usando as informações a seguir, contate o suporte.

Visão geral

A conexão de gateway de VPN envolve os seguintes componentes:

O diagrama a seguir mostra a conectividade lógica de uma rede local para uma rede virtual do Azure por meio de VPN.

Conectividade Lógica da Rede do Cliente com a Rede MSFT usando VPN

Calcule a entrada/saída máxima esperada

  1. Determine os requisitos da taxa de transferência de linha de base do aplicativo.
  2. Determine os limites de taxa de transferência de gateway de VPN do Azure. Para obter ajuda, confira a seção "SKUs do Gateway" em Sobre o Gateway de VPN.
  3. Determine as Diretrizes de taxa de transferência para a VM do Azure para seu tamanho de VM.
  4. Determine a largura de banda do Provedor de Serviços de Internet (ISP).
  5. Calcule a taxa de transferência esperada usando a menor largura de banda da VM, do Gateway de VPN ou do ISP; que é medida em megabits por segundo (/) divididos por oito (8). Esse cálculo fornece megabytes por segundo.

Se a taxa de transferência calculada não atender aos requisitos de taxa de transferência de linha de base do aplicativo, será necessário aumentar a largura de banda do recurso identificado como o gargalo. Para redimensionar um Gateway de VPN do Azure, consulte Alterar um SKU de gateway. Para redimensionar uma máquina virtual, consulte Redimensionar uma VM. Se não houver a largura de banda de Internet esperada, também convém entrar em contato com seu ISP.

Observação

A taxa de transferência do Gateway de VPN é um agregado de todas as conexões Site a Site\VNET a VNET ou ponto a site.

Validar a taxa de transferência de rede usando as ferramentas de desempenho

Essa validação deve ser executada durante horários fora de pico, já que a saturação de taxa de transferência de túnel da VPN durante o teste não apresenta resultados precisos.

A ferramenta que usamos para esse teste é iPerf, que funciona tanto no Windows como no Linux e tem modos de cliente e servidor. Ela é limitada a 3 Gbps para VMs do Windows.

Essa ferramenta não executa operações de leitura/gravação em disco. A ferramenta somente produz o tráfego TCP gerado automaticamente de uma extremidade à outra. As estatísticas são geradas com base em experimentos que medem a largura de banda disponível entre nós de cliente e servidor. Ao testar entre dois nós, um nó atua como o servidor e o outro nó atua como um cliente. Quando esse teste for concluído, recomendamos reverter as funções dos nós para testar tanto a taxa de transferência de upload como a de download em ambos os nós.

Baixar iPerf

Baixar iPerf. Para obter detalhes, consulte a Documentação iPerf.

Observação

Os produtos de terceiros mencionados neste artigo são fabricados por empresas que são independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, sobre o desempenho ou a confiabilidade desses produtos.

Executar iPerf (iperf3.exe)

  1. Habilite uma regra NSG/ACL permitindo o tráfego (para teste de endereço IP público em VM do Azure).

  2. Em ambos os nós, habilite uma exceção de firewall para a porta 5001.

    Windows: Execute o seguinte comando como um administrador:

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

    Para remover a regra após a conclusão do teste, execute esse comando:

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

    Linux do Azure: as imagens do Linux do Azure têm firewalls permissivos. Se houver um aplicativo escutando em uma porta, o tráfego por ela será permitido. Imagens personalizadas que são protegidas podem precisar de portas abertas explicitamente. Os firewalls da camada de OS do Linux comuns incluem iptables, ufw, ou firewalld.

  3. No nó de servidor, altere para o diretório onde o iperf3.exe é extraído. Em seguida, execute o iPerf no modo de servidor e configure-o para escutar na porta 5001, de acordo com os seguintes comandos:

    cd c:\iperf-3.1.2-win65

iperf3.exe -s -p 5001

    Observação

    A porta 5001 pode ser personalizada para atender a restrições específicas de firewall em seu ambiente.

  4. No nó de cliente, altere para o diretório onde a ferramenta iperf é extraída e, em seguida, execute o seguinte comando:

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

    O cliente está direcionando 30 segundos de tráfego na porta 5001 para o servidor. O sinalizador “-P” indica que estamos fazendo 32 conexões simultâneas com o nó do servidor.

    A tela a seguir mostra a saída a partir desse exemplo:

    Saída

  5. (OPCIONAL) Para preservar os resultados dos testes, execute este comando:

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

  6. Após concluir as etapas anteriores, execute as mesmas etapas com as funções invertidas, de modo que o nó de servidor agora seja o nó de cliente e vice-versa.

Observação

O Iperf não é a única ferramenta. O NTTTCP é uma solução alternativa para testes.

Testar VMs que executam o Windows

Carregar o latte.exe nas VMs

Baixar a versão mais recente do Latte.exe

Considerar colocar o Latte.exe em uma pasta separada, como c:\tools

Permitir o Latte.exe pelo firewall do Windows

No receptor, crie uma regra de Permissão no Firewall do Windows para permitir a chegada do tráfego de Latte.exe. É mais fácil permitir todo o programa Latte.exe pelo nome, em vez de permitir a entrada de portas TCP específicas.

Permitir o Latte.exe pelo Firewall do Windows desta maneira

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

Por exemplo, se você copiou o latte.exe para a pasta “c:\tools”, esse seria o comando

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

Executar testes de latência

Inicie o latte.exe no RECEPTOR (execute no CMD, não no PowerShell):

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

Cerca de 65.000 iterações são longas o suficiente para retornar resultados representativos.

Pode ser qualquer número de porta disponível.

Se a VM tiver um endereço IP 10.0.0.4, o comando será parecido com este

latte -c -a 10.0.0.4:5005 -i 65100

Iniciar o latte.exe no REMETENTE (execute no CMD, não no PowerShell)

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

O comando resultante é o mesmo que no receptor, exceto com a adição de "-c" para indicar que este é o "cliente" ou o remetente

latte -c -a 10.0.0.4:5005 -i 65100

Aguarde os resultados. Dependendo da distância entre as VMs, a conclusão pode levar alguns minutos. Considere iniciar com menos iterações para testar o êxito antes de executar testes mais longos.

Testar VMs que executam o Linux

Use SockPerf para testar VMS.

Instalar o SockPerf nas VMs

Nas VMs do Linux (REMETENTE e RECEPTOR), execute estes comandos para preparar o SockPerf em suas VMs:

RHEL: instalar o GIT e outras ferramentas úteis

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 ꟷ instalar o GIT e outras ferramentas úteis

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 ꟷ todos

Da linha de comando bash (assume que o git está instalado)

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

A criação é mais lenta, pode levar vários minutos

make

Tornar a instalação rápida

sudo make install

Executar SockPerf nas VMs

Comandos de amostra após a instalação. Servidor/receptor ꟷ supõe que o IP do servidor seja 10.0.0.4

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

Cliente ꟷ que o IP do servidor seja 10.0.0.4

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

Observação

Verifique se não há saltos intermediários (por exemplo, solução de virtualização) durante o teste de taxa de transferência entre a VM e o gateway. Se houver resultados insatisfatórios (em termos de taxa de transferência) provenientes dos testes iPERF/NTTTCP acima, confira este artigo para compreender os principais fatores por trás das possíveis causas raiz do problema:

Em particular, a análise de rastreamentos de captura de pacotes (Wireshark/Monitor de Rede) coletados em paralelo no cliente e no servidor durante esses testes ajudará nas avaliações de mau desempenho. Esses rastreamentos podem incluir perda de pacotes, alta latência e tamanho de MTU. fragmentação, janela TCP 0, fragmentos fora de ordem e assim por diante.

Solucionar problemas com cópia de arquivo lenta

Mesmo que a taxa de transferência geral avaliada com as etapas anteriores (iPERF/NTTTCP/etc.) tenha sido boa, você pode experimentar um processamento lento de arquivos ao usar o Windows Explorer ou arrastar e soltar em uma sessão RDP. Esse problema normalmente ocorre devido a um ou ambos os seguintes fatores:

  • Os aplicativos de cópia de arquivos, como o Windows Explorer e o RDP não usam vários threads ao copiar arquivos. Para obter melhor desempenho, use um aplicativo de cópia de arquivo multi-threaded como o Richcopy para copiar arquivos usando 16 ou 32 threads. Para alterar o número de thread para cópia de arquivo no Richcopy, clique em Ação>Opções de cópia>Cópia de arquivos.

    Problemas com cópia de arquivo lenta

    Observação

    Nem todos os aplicativos funcionam da mesma forma e nem todos os aplicativos/processos utilizam todos os threads. Aplicando o teste, você pode ver que alguns threads estão vazios e não fornecem resultados de taxa de transferência precisos. Para verificar o desempenho da transferência de arquivos do aplicativo, use vários threads aumentando o número de threads em sucessão ou diminuição para encontrar a taxa de transferência ideal do aplicativo ou arquivos.

  • Velocidade de leitura/gravação de disco de VM insuficiente. Para obter mais informações, consulte Solução de Problemas de Armazenamento do Azure.

Interface externa do dispositivo local

Foram mencionadas as sub-redes de intervalos locais que você gostaria que o Azure alcançasse via VPN no gateway de rede local. Simultaneamente, defina o espaço de endereço da VNET no Azure para o dispositivo local.

  • Gateway baseado em rota: o seletor de política ou de tráfego para as VPNs baseadas em rota são configurados como qualquer para qualquer (ou curingas).

  • Gateway baseado em política: as VPNs baseadas em política criptografam e direcionam pacotes por meio de túneis IPsec com base em combinações de prefixos de endereço entre sua rede local e a VNet do Azure. A política (ou o seletor de tráfego) normalmente é definida como uma lista de acesso na configuração de VPN.

  • Conexões UsePolicyBasedTrafficSelector: “UsePolicyBasedTrafficSelectors” para $True em uma conexão configurará o gateway de VPN do Azure para se conectar ao firewall de VPN baseado em política localmente. Caso habilite PolicyBasedTrafficSelectors, você precisa garantir que o seu dispositivo VPN tem os seletores de tráfego correspondentes definidos com todas as combinações de prefixos de rede local (gateway de rede local) de/para prefixos de rede virtual do Azure, em vez de "qualquer para qualquer".

A configuração inadequada pode levar a desconexões frequentes no túnel, remoções de pacotes, taxa de transferência incorreta e latência.

Verificar latência

Você pode verificar a latência usando as seguintes ferramentas:

  • WinMTR
  • TCPTraceroute
  • ping e psping (essas ferramentas podem fornecer uma boa estimativa do RTT, mas não podem ser usadas em todos os casos).

Verificar latência

Se você notar um pico de alta latência em qualquer um dos saltos antes de entrar no backbone da rede da MS, convém continuar com investigações adicionais com seu provedor de serviços de Internet.

Se um grande pico de latência incomum for notado de saltos dentro de "msn.net", entre em contato com o suporte da Microsoft para investigações adicionais.

Próximas etapas

Para saber mais ou ajuda, confira os seguintes links: