Partilhar via

How to validate VPN throughput to a virtual network (Como validar o débito da VPN para uma rede virtual)

  • Artigo

Uma conexão de gateway VPN permite que você estabeleça conectividade segura entre locais entre sua Rede Virtual no 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.

Nota

Este artigo destina-se a ajudar a diagnosticar e corrigir problemas comuns. Se não conseguir resolver o problema utilizando as seguintes informações, contacte o suporte.

Descrição geral

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

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

Conectividade lógica da rede do cliente com a rede MSFT usando VPN

Calcular a entrada/saída máxima esperada

  1. Determine os requisitos de taxa de transferência da linha de base do seu aplicativo.
  2. Determine os limites de taxa de transferência do gateway de VPN do Azure. Para obter ajuda, consulte a seção "SKUs de gateway" de Sobre o VPN Gateway.
  3. Determine a orientação de taxa de transferência da VM do Azure para o tamanho da sua VM.
  4. Determine a largura de banda do seu Provedor de Serviços de Internet (ISP).
  5. Calcule sua taxa de transferência esperada usando a menor largura de banda da VM, VPN Gateway ou ISP; que é medido em Megabits por segundo (/) dividido por oito (8). Este cálculo dá-lhe Megabytes por segundo.

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

Nota

A taxa de transferência do Gateway VPN é uma agregação de todas as conexões Site-to-Site\VNET-to-VNET ou Point-to-Site.

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

Essa validação deve ser realizada fora do horário de pico, pois a saturação da taxa de transferência do túnel VPN durante o teste não fornece resultados precisos.

A ferramenta que usamos para este teste é o iPerf, que funciona tanto no Windows quanto no Linux e tem os modos cliente e servidor. É limitado a 3 Gbps para VMs do Windows.

Esta ferramenta não executa quaisquer operações de leitura/escrita no disco. Ele só produz tráfego TCP auto-gerado de uma extremidade para a outra. Ele gera estatísticas baseadas em experimentação que mede a largura de banda disponível entre nós 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 que você inverta as funções dos nós para testar a taxa de transferência de upload e download em ambos os nós.

Baixar iPerf

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

Nota

Os produtos de terceiros discutidos neste artigo são fabricados por empresas independentes da Microsoft. A Microsoft não concede qualquer garantia, implícita ou de outra natureza, relativamente ao desempenho ou à fiabilidade destes produtos.

Executar iPerf (iperf3.exe)

  1. Habilite uma regra NSG/ACL permitindo o tráfego (para teste de endereço IP público na 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 administrador:

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

    Para remover a regra quando o teste estiver concluído, execute este comando:

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

    Azure Linux: as imagens do Azure Linux têm firewalls permissivos. Se houver um aplicativo escutando em uma porta, o tráfego será permitido. As imagens personalizadas protegidas podem precisar de portas abertas explicitamente. Os firewalls comuns da camada de SO Linux incluem iptables, ufwou firewalld.

  3. No nó do servidor, mude para o diretório onde iperf3.exe é extraído. Em seguida, execute o iPerf no modo de servidor e defina-o para ouvir na porta 5001 como os seguintes comandos:

    cd c:\iperf-3.1.2-win65

iperf3.exe -s -p 5001

    Nota

    A porta 5001 é personalizável para levar em conta restrições de firewall específicas em seu ambiente.

  4. No nó do cliente, mude para o diretório onde a ferramenta iperf é extraída e 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 deste exemplo:

    Saída

  5. (OPCIONAL) Para preservar os resultados do teste, execute este comando:

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

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

Nota

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

Testar VMs executando o Windows

Carregue Latte.exe nas VMs

Faça o download da versão mais recente do Latte.exe

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

Permitir Latte.exe através do firewall do Windows

No recetor, crie uma regra Permitir no Firewall do Windows para permitir que o tráfego Latte.exe chegue. É mais fácil permitir todo o programa Latte.exe pelo nome do que permitir a entrada de portas TCP específicas.

Permitir Latte.exe através do Firewall do Windows como este

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 latte.exe para a pasta "c:\tools", este 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 latte.exe no RECETOR (execute a partir do CMD, não do PowerShell):

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

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

Qualquer número de porta disponível é bom.

Se a VM tiver um endereço IP de 10.0.0.4, terá esta aparência

latte -c -a 10.0.0.4:5005 -i 65100

Iniciar latte.exe no SENDER (executar a partir do CMD, não do PowerShell)

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

O comando resultante é o mesmo que no recetor, exceto com a adição de "-c" para indicar que este é o "cliente" ou 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 começar com menos iterações para testar o sucesso antes de executar testes mais longos.

Testar VMs executando Linux

Use SockPerf para testar VMs.

Instalar o SockPerf nas VMs

Nas VMs Linux (SENDER e RECEIVER), execute estes comandos para preparar o SockPerf em suas VMs:

RHEL - Instale 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 - Instale 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

A partir da linha de comando bash (assume que o git está instalado)

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

Fazer é mais lento, pode demorar vários minutos

make

Fazer a instalação é rápido

sudo make install

Execute o SockPerf nas VMs

Exemplos de comandos após a instalação. Servidor/Recetor - assume que o IP do servidor é 10.0.0.4

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

Cliente - assume que o IP do servidor é 10.0.0.4

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

Nota

Certifique-se de que não há saltos intermediários (por exemplo, Dispositivo Virtual) durante o teste de taxa de transferência entre a VM e o Gateway. Se houver resultados ruins (em termos de taxa de transferência geral) provenientes dos testes iPERF/NTTTCP acima, consulte este artigo para entender os principais fatores por trás das possíveis causas do problema:

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

Resolver problemas de cópia lenta de ficheiros

Mesmo que a taxa de transferência geral avaliada com as etapas anteriores (iPERF/NTTTCP/etc.) tenha sido boa, você pode enfrentar um enfrentamento lento de arquivos ao usar o Windows Explorer ou arrastar e soltar através de uma sessão RDP. Este problema é normalmente 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 um 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 do thread para cópia de arquivo no Richcopy, clique em Opções>de cópia de ação>Cópia de arquivo.

    Problemas de cópia lenta de arquivos

    Nota

    Nem todos os aplicativos funcionam da mesma forma, e nem todos os aplicativos/processos utilizam todos os threads. Se você executar o teste, poderá ver alguns threads vazios e não fornecerão resultados de taxa de transferência precisos. Para verificar o desempenho de transferência de arquivos do aplicativo, use multi-thread aumentando o # de thread em sucessão ou diminuição, a fim de encontrar a taxa de transferência ideal do aplicativo ou transferência de arquivos.

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

Interface externa do dispositivo local

Mencionou 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 VNET no Azure para o dispositivo local.

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

  • Gateway Baseado em Políticas: VPNs baseadas em políticas criptografam e direcionam pacotes por meio de túneis IPsec com base nas combinações de prefixos de endereço entre sua rede local e a VNet do Azure. Normalmente, a política (ou o Seletor de Tráfego), é definido como uma lista de acesso na configuração de VPN.

  • Conexões UsePolicyBasedTrafficSelector : ("UsePolicyBasedTrafficSelectors" para $True em uma conexão configura o gateway de VPN do Azure para se conectar ao firewall VPN baseado em política no local. Se você habilitar PolicyBasedTrafficSelectors, precisará garantir que seu dispositivo VPN tenha os seletores de tráfego correspondentes definidos com todas as combinações de seus prefixos de rede local (gateway de rede local) de e para os prefixos de rede virtual do Azure, em vez de qualquer para qualquer.

A configuração inadequada pode levar a desconexões frequentes dentro do túnel, quedas 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 de RTT, mas não podem ser usadas em todos os casos.)

Verificar latência

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

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

Próximos passos

Para mais informações ou ajuda, consulte o seguinte link: