Dela via

Verifiera VPN-dataflöde till ett virtuellt nätverk

  • Artikel

Med en VPN-gatewayanslutning kan du upprätta en säker, lokal anslutning mellan ditt virtuella nätverk i Azure och din lokala IT-infrastruktur.

Den här artikeln visar hur du verifierar nätverkets dataflöde från de lokala resurserna till en virtuell Azure-dator (VM).

Kommentar

Den här artikeln är avsedd att hjälpa dig att diagnostisera och åtgärda vanliga problem. Kontakta supporten om du inte kan lösa problemet med hjälp av följande information.

Översikt

VPN-gatewayanslutningen omfattar följande komponenter:

Följande diagram visar den logiska anslutningen för ett lokalt nätverk till ett virtuellt Azure-nätverk via VPN.

Logisk anslutning för kundnätverk till MSFT-nätverk med VPN

Beräkna den maximala förväntade ingressen/utgående

  1. Fastställa programmets krav på baslinjedataflöde.
  2. Fastställa dataflödesgränserna för din Azure VPN-gateway. Mer hjälp finns i avsnittet "Gateway-SKU:er" i Om VPN Gateway.
  3. Fastställa vägledningen för dataflöde för virtuella Azure-datorer för din VM-storlek.
  4. Fastställ bandbredden för internetleverantören (ISP).
  5. Beräkna ditt förväntade dataflöde genom att ta minst bandbredd för den virtuella datorn, VPN Gateway eller ISP. som mäts i Megabit per sekund (/) dividerat med åtta (8). Den här beräkningen ger dig Megabyte per sekund.

Om ditt beräknade dataflöde inte uppfyller programmets grundläggande dataflödeskrav måste du öka bandbredden för den resurs som du identifierade som flaskhalsen. Information om hur du ändrar storlek på en Azure VPN Gateway finns i Ändra en gateway-SKU. Information om hur du ändrar storlek på en virtuell dator finns i Ändra storlek på en virtuell dator. Om du inte har den förväntade Internetbandbredden kan du även kontakta internetleverantören.

Kommentar

VPN Gateway-dataflödet är en mängd av alla anslutningar från plats till plats\VNET-till-VNET eller punkt-till-plats-anslutningar.

Verifiera nätverkets dataflöde med hjälp av prestandaverktyg

Den här valideringen bör utföras under icke-piptimmar, eftersom mättnad i VPN-tunneldataflöde under testningen inte ger korrekta resultat.

Verktyget vi använder för det här testet är iPerf, som fungerar på både Windows och Linux och har både klient- och serverlägen. Den är begränsad till 3 Gbit/s för virtuella Windows-datorer.

Det här verktyget utför inga läs-/skrivåtgärder på disken. Den producerar endast självgenererad TCP-trafik från ena änden till den andra. Den genererar statistik baserat på experimentering som mäter den tillgängliga bandbredden mellan klient- och servernoder. När du testar mellan två noder fungerar en nod som server och den andra noden fungerar som en klient. När det här testet har slutförts rekommenderar vi att du ändrar nodernas roller för att testa både överförings- och nedladdningsdataflödet på båda noderna.

Ladda ned iPerf

Ladda ned iPerf. Mer information finns i iPerf-dokumentationen.

Kommentar

De produkter från tredje part som beskrivs i den här artikeln tillverkas av företag som är oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

Kör iPerf (iperf3.exe)

  1. Aktivera en NSG/ACL-regel som tillåter trafik (för testning av offentliga IP-adresser på en virtuell Azure-dator).

  2. Aktivera ett brandväggsfel för port 5001 på båda noderna.

    Windows: Kör följande kommando som administratör:

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

    Om du vill ta bort regeln när testningen är klar kör du det här kommandot:

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

    Azure Linux: Azure Linux-avbildningar har tillåtande brandväggar. Om ett program lyssnar på en port tillåts trafiken. Anpassade avbildningar som skyddas kan behöva portar som öppnas explicit. Vanliga brandväggar på Linux OS-nivå är iptables, ufweller firewalld.

  3. På servernoden ändrar du till katalogen där iperf3.exe extraheras. Kör sedan iPerf i serverläge och ställ in det på att lyssna på port 5001 som följande kommandon:

    cd c:\iperf-3.1.2-win65

iperf3.exe -s -p 5001

    Kommentar

    Port 5001 är anpassningsbar för att ta hänsyn till särskilda brandväggsbegränsningar i din miljö.

  4. På klientnoden ändrar du till katalogen där iperf-verktyget extraheras och kör sedan följande kommando:

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

    Klienten dirigerar 30 sekunders trafik på port 5001 till servern. Flaggan "-P" anger att vi gör 32 samtidiga anslutningar till servernoden.

    Följande skärm visar utdata från det här exemplet:

    Output

  5. (VALFRITT) Om du vill bevara testresultaten kör du det här kommandot:

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

  6. När du har slutfört föregående steg kör du samma steg med rollerna omvända, så att servernoden nu blir klientnoden och vice versa.

Kommentar

Iperf är inte det enda verktyget. NTTTCP är en alternativ lösning för testning.

Testa virtuella datorer som kör Windows

Läs in Latte.exe på de virtuella datorerna

Ladda ned den senaste versionen av Latte.exe

Överväg att placera Latte.exe i en separat mapp, till exempel c:\tools

Tillåt Latte.exe via Windows-brandväggen

På mottagaren skapar du en Tillåt-regel i Windows-brandväggen så att Latte.exe trafik kan tas emot. Det är enklast att tillåta hela Latte.exe programmet med namn i stället för att tillåta specifika inkommande TCP-portar.

Tillåt Latte.exe via Windows-brandväggen så här

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

Om du till exempel kopierade latte.exe till mappen "c:\tools" skulle det här vara kommandot

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

Köra svarstidstester

Starta latte.exe på MOTTAGAREN (kör från CMD, inte från PowerShell):

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

Cirka 65 000 iterationer är tillräckligt långa för att returnera representativa resultat.

Alla tillgängliga portnummer är bra.

Om den virtuella datorn har en IP-adress på 10.0.0.4 skulle det se ut så här

latte -c -a 10.0.0.4:5005 -i 65100

Starta latte.exe på SENDER (kör från CMD, inte från PowerShell)

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

Det resulterande kommandot är detsamma som på mottagaren förutom med tillägget av "-c" för att indikera att detta är "klienten" eller avsändaren

latte -c -a 10.0.0.4:5005 -i 65100

Vänta på resultatet. Beroende på hur långt ifrån varandra de virtuella datorerna är kan det ta några minuter att slutföra. Överväg att börja med färre iterationer för att testa för framgång innan du kör längre tester.

Testa virtuella datorer som kör Linux

Använd SockPerf för att testa virtuella datorer.

Installera SockPerf på de virtuella datorerna

På de virtuella Linux-datorerna (både SENDER och RECEIVER) kör du följande kommandon för att förbereda SockPerf på dina virtuella datorer:

RHEL – Installera GIT och andra användbara verktyg

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 – Installera GIT och andra användbara verktyg

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 - alla

Från bash-kommandoraden (förutsätter att git är installerat)

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

Make är långsammare, kan ta flera minuter

make

Gör installationen snabb

sudo make install

Kör SockPerf på de virtuella datorerna

Exempelkommandon efter installationen. Server/mottagare – förutsätter att serverns IP-adress är 10.0.0.4

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

Klient – förutsätter att serverns IP-adress är 10.0.0.4

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

Kommentar

Kontrollera att det inte finns några mellanliggande hopp (t.ex. virtuell installation) under dataflödestestningen mellan den virtuella datorn och gatewayen. Om det finns dåliga resultat (i termer av övergripande dataflöde) som kommer från iPERF/NTTTCP-testerna ovan kan du läsa den här artikeln för att förstå de viktigaste faktorerna bakom de möjliga rotorsakerna till problemet:

I synnerhet hjälper analys av spårningar av paketinsamling (Wireshark/Network Monitor) som samlats in parallellt från klient och server under dessa tester i utvärderingarna av dåliga prestanda. Dessa spårningar kan omfatta paketförlust, hög svarstid, MTU-storlek. fragmentering, TCP 0-fönster, out of order-fragment och så vidare.

Åtgärda problem med långsam filkopiering

Även om det övergripande dataflödet som utvärderades med föregående steg (iPERF/NTTTCP/osv.) var bra kan det uppstå långsam filhantering när du antingen använder Utforskaren eller drar och släpper genom en RDP-session. Det här problemet beror normalt på en eller båda av följande faktorer:

  • Filkopieringsprogram, till exempel Utforskaren och RDP, använder inte flera trådar när du kopierar filer. För bättre prestanda använder du ett program för flertrådad filkopiering, till exempel Richcopy , för att kopiera filer med hjälp av 16 eller 32 trådar. Om du vill ändra trådnumret för filkopiering i Richcopy klickar du på Alternativ för åtgärdskopiering>>Filkopiering.

    Problem med långsam filkopiering

    Kommentar

    Alla program fungerar inte likadant och alla program/processer använder inte alla trådar. Om du kör testet kan du se att vissa trådar är tomma och inte ger korrekta dataflödesresultat. Om du vill kontrollera programmets filöverföringsprestanda använder du flera trådar genom att öka antalet trådar i följd eller minska för att hitta det optimala dataflödet för programmet eller filöverföringen.

  • Otillräcklig läs-/skrivhastighet för virtuell datordisk. Mer information finns i Felsökning av Azure Storage.

Externt gränssnitt för lokal enhet

Nämnde undernäten för lokala intervall som du vill att Azure ska nå via VPN på lokal nätverksgateway. Definiera VNET-adressutrymmet i Azure samtidigt till den lokala enheten.

  • Routningsbaserad gateway: Principen eller trafikväljaren för routningsbaserade VPN:er konfigureras som valfri (eller jokertecken).

  • Principbaserad gateway: Principbaserade VPN krypterar och dirigerar paket via IPsec-tunnlar baserat på kombinationerna av adressprefix mellan ditt lokala nätverk och det virtuella Azure-nätverket. Principen (eller trafikväljaren) definieras vanligtvis som en åtkomstlista i VPN-konfigurationen.

  • UsePolicyBasedTrafficSelector-anslutningar : ("UsePolicyBasedTrafficSelectors" för att $True på en anslutning konfigurerar Azure VPN-gatewayen för att ansluta till en principbaserad VPN-brandvägg lokalt. Om du aktiverar PolicyBasedTrafficSelectors måste du se till att VPN-enheten har de matchande trafikväljarna definierade med alla kombinationer av prefixen för ditt lokala nätverk (lokal nätverksgateway) till och från prefixen för virtuella Azure-nätverk i stället för valfria.

Olämplig konfiguration kan leda till frekventa frånkopplingar i tunneln, paketförluster, dåligt dataflöde och svarstid.

Kontrollera svarstiden

Du kan kontrollera svarstiden med hjälp av följande verktyg:

  • WinMTR
  • TCPTraceroute
  • ping och psping (Dessa verktyg kan ge en bra uppskattning av RTT, men de kan inte användas i alla fall.)

Kontrollera svarstid

Om du ser en hög svarstidstopp vid något av hoppen innan du anger MS Network-stamnätet kan du fortsätta med ytterligare undersökningar med internetleverantören.

Om en stor, ovanlig svarstidstoppar märks från hopp inom "msn.net" kontaktar du MS-supporten för ytterligare undersökningar.

Nästa steg

Mer information eller hjälp finns på följande länk: