VPN-doorvoer naar een virtueel netwerk valideren
Met een VPN-gatewayverbinding kunt u beveiligde, cross-premises connectiviteit tot stand brengen tussen uw virtuele netwerk in Azure en uw on-premises IT-infrastructuur.
In dit artikel wordt beschreven hoe u netwerkdoorvoer van de on-premises resources naar een virtuele Azure-machine (VM) valideert.
Notitie
Dit artikel is bedoeld om veelvoorkomende problemen vast te stellen en op te lossen. Als u het probleem niet kunt oplossen met behulp van de volgende informatie, neemt u contact op met de ondersteuning.
Overzicht
De VPN-gatewayverbinding omvat de volgende onderdelen:
- On-premises VPN-apparaat (een lijst met gevalideerde VPN-apparaten weergeven.)
- Openbaar internet
- Azure VPN-gateway
- Azure VM
In het volgende diagram ziet u de logische connectiviteit van een on-premises netwerk met een virtueel Azure-netwerk via VPN.
Het maximum aantal verwachte inkomend/uitgaand verkeer berekenen
- Bepaal de doorvoervereisten voor de basislijn van uw toepassing.
- Bepaal de doorvoerlimieten van uw Azure VPN-gateway. Zie de sectie Gateway-SKU's van Over VPN Gateway voor hulp.
- Bepaal de richtlijnen voor doorvoer van azure-VM's voor uw VM-grootte.
- Bepaal de bandbreedte van uw internetprovider.
- Bereken de verwachte doorvoer door de minste bandbreedte van de VM, VPN Gateway of internetprovider te gebruiken; die wordt gemeten in Megabits-per-seconde (/) gedeeld door acht (8). Deze berekening geeft u Megabytes per seconde.
Als uw berekende doorvoer niet voldoet aan de vereisten voor doorvoer volgens de basislijn van uw toepassing, moet u de bandbreedte verhogen van de resource die u hebt geïdentificeerd als het knelpunt. Zie Een gateway-SKU wijzigen om het formaat van een Azure VPN-gateway te wijzigen. Als u het formaat van een virtuele machine wilt wijzigen, raadpleegt u Het formaat van een VIRTUELE machine wijzigen. Als u niet de verwachte internetbandbreedte ondervindt, kunt u ook contact opnemen met uw internetprovider.
Notitie
VPN Gateway-doorvoer is een aggregaties van alle site-naar-site-/VNET-naar-VNET- of punt-naar-site-verbindingen.
Netwerkdoorvoer valideren met behulp van prestatiehulpprogramma's
Deze validatie moet worden uitgevoerd tijdens niet-peakuren, omdat de verzadiging van de VPN-tunneldoorvoer tijdens het testen geen nauwkeurige resultaten oplevert.
Het hulpprogramma dat we voor deze test gebruiken, is iPerf, die zowel in Windows als Linux werkt en zowel client- als servermodi heeft. Het is beperkt tot 3 Gbps voor Windows-VM's.
Met dit hulpprogramma worden geen lees-/schrijfbewerkingen naar de schijf uitgevoerd. Het produceert uitsluitend zelf gegenereerd TCP-verkeer van het ene naar het andere uiteinde. Er worden statistieken gegenereerd op basis van experimenten waarmee de bandbreedte wordt berekend die beschikbaar is tussen client- en serverknooppunten. Bij het testen tussen twee knooppunten fungeert één knooppunt als de server en het andere knooppunt fungeert als een client. Zodra deze test is voltooid, raden we u aan om de rollen van de knooppunten om te draaien om zowel de upload- als downloaddoorvoer op beide knooppunten te testen.
iPerf downloaden
Download iPerf. Zie de iPerf-documentatie voor meer informatie.
Notitie
De producten van derden die in dit artikel worden besproken, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.
iPerf uitvoeren (iperf3.exe)
Schakel een NSG-/ACL-regel in die het verkeer toestaat (voor het testen van openbare IP-adressen op azure-VM's).
Schakel op beide knooppunten een firewall-uitzondering in voor poort 5001.
Windows: Voer de volgende opdracht uit als beheerder:
netsh advfirewall firewall add rule name="Open Port 5001" dir=in action=allow protocol=TCP localport=5001
Als u de regel wilt verwijderen wanneer het testen is voltooid, voert u deze opdracht uit:
netsh advfirewall firewall delete rule name="Open Port 5001" protocol=TCP localport=5001
Azure Linux: Azure Linux-installatiekopieën hebben permissieve firewalls. Als er een toepassing op een poort luistert, wordt het verkeer toegestaan. Aangepaste installatiekopieën die zijn beveiligd, hebben mogelijk expliciet poorten nodig die zijn geopend. Algemene Linux OS-laag firewalls omvatten
iptables
,ufw
offirewalld
.Ga op het serverknooppunt naar de map waarin iperf3.exe wordt geëxtraheerd. Voer vervolgens iPerf uit in de servermodus en stel deze in om te luisteren op poort 5001 als de volgende opdrachten:
cd c:\iperf-3.1.2-win65 iperf3.exe -s -p 5001
Notitie
Poort 5001 kan worden aangepast om rekening te houden met bepaalde firewallbeperkingen in uw omgeving.
Ga op het clientknooppunt naar de map waarin het iperf-hulpprogramma is geëxtraheerd en voer vervolgens de volgende opdracht uit:
iperf3.exe -c <IP of the iperf Server> -t 30 -p 5001 -P 32
De client stuurt 30 seconden verkeer op poort 5001 naar de server. De vlag '-P' geeft aan dat we 32 gelijktijdige verbindingen maken met het serverknooppunt.
In het volgende scherm ziet u de uitvoer uit dit voorbeeld:
(OPTIONEEL) Voer deze opdracht uit om de testresultaten te behouden:
iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32 >> output.txt
Nadat u de vorige stappen hebt voltooid, voert u dezelfde stappen uit met de omgekeerde rollen, zodat het serverknooppunt nu het clientknooppunt is en omgekeerd.
Notitie
Iperf is niet de enige tool. NTTTCP is een alternatieve oplossing voor testen.
Vm's met Windows testen
Latte.exe op de VM's laden
Download de nieuwste versie van Latte.exe
Overweeg Latte.exe in een afzonderlijke map te plaatsen, zoals c:\tools
Latte.exe via de Windows-firewall toestaan
Maak op de ontvanger een regel Toestaan in Windows Firewall om toe te staan dat het Latte.exe verkeer binnenkomt. Het is het eenvoudigst om het hele Latte.exe programma op naam toe te staan in plaats van specifieke TCP-poorten binnenkomend toe te staan.
Latte.exe toestaan via Windows Firewall, zoals deze
netsh advfirewall firewall add rule program=<PATH>\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY
Als u bijvoorbeeld latte.exe naar de map c:\tools hebt gekopieerd, is dit de opdracht
netsh advfirewall firewall add rule program=c:\tools\latte.exe name="Latte" protocol=any dir=in action=allow enable=yes profile=ANY
Latentietests uitvoeren
Start latte.exe op de ONTVANGER (uitvoeren vanaf CMD, niet vanuit PowerShell):
latte -a <Receiver IP address>:<port> -i <iterations>
Ongeveer 65.000 iteraties is lang genoeg om representatieve resultaten te retourneren.
Elk beschikbaar poortnummer is prima.
Als de VM een IP-adres van 10.0.0.4 heeft, ziet deze er als volgt uit
latte -c -a 10.0.0.4:5005 -i 65100
Start latte.exe op de AFZENDER (uitvoeren vanuit CMD, niet vanuit PowerShell)
latte -c -a <Receiver IP address>:<port> -i <iterations>
De resulterende opdracht is hetzelfde als op de ontvanger, behalve met de toevoeging van '-c' om aan te geven dat dit de 'client' of afzender is
latte -c -a 10.0.0.4:5005 -i 65100
Wacht op de resultaten. Afhankelijk van hoe ver de VM's zich bevinden, kan het enkele minuten duren. Overweeg om te beginnen met minder iteraties om te testen op succes voordat u langere tests uitvoert.
Vm's testen waarop Linux wordt uitgevoerd
Gebruik SockPerf om VM's te testen.
SockPerf installeren op de VM's
Voer op de Linux-VM's (zowel SENDER als RECEIVER) deze opdrachten uit om SockPerf voor te bereiden op uw VM's:
RHEL - GIT en andere nuttige hulpprogramma's installeren
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 - GIT en andere nuttige hulpprogramma's installeren
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 - alle
Vanaf de bash-opdrachtregel (wordt ervan uitgegaan dat Git is geïnstalleerd)
git clone https://github.com/mellanox/sockperf
cd sockperf/
./autogen.sh
./configure --prefix=
De make is langzamer, kan enkele minuten duren
make
Installatie snel maken
sudo make install
SockPerf uitvoeren op de VM's
Voorbeeldopdrachten na installatie. Server/ontvanger: gaat ervan uit dat het IP-adres van de server 10.0.0.4 is
sudo sockperf sr --tcp -i 10.0.0.4 -p 12345 --full-rtt
Client: gaat ervan uit dat het IP-adres van de server 10.0.0.4 is
sockperf ping-pong -i 10.0.0.4 --tcp -m 1400 -t 101 -p 12345 --full-rtt
Notitie
Zorg ervoor dat er geen tussenliggende hops (bijvoorbeeld virtueel apparaat) zijn tijdens het testen van de doorvoer tussen de VIRTUELE machine en de gateway. Als er slechte resultaten (in termen van algemene doorvoer) afkomstig zijn van de bovenstaande iPERF/NTTTCP-tests, raadpleegt u dit artikel om inzicht te krijgen in de belangrijkste factoren achter de mogelijke hoofdoorzaken van het probleem:
Met name analyse van traceringen voor pakketopname (Wireshark/Network Monitor) die parallel van de client en server zijn verzameld tijdens deze tests, helpen bij de evaluaties van slechte prestaties. Deze traceringen kunnen pakketverlies, hoge latentie, MTU-grootte omvatten. Fragmentatie, TCP 0-venster, fragmenten buiten volgorde, enzovoort.
Problemen met trage bestandskopie oplossen
Zelfs als de totale doorvoer die is geëvalueerd met de vorige stappen (iPERF/NTTTCP/etc.) goed was, kan het zijn dat u trage bestandsvertraging ondervindt bij het gebruik van Windows Verkenner of het slepen en neerzetten via een RDP-sessie. Dit probleem wordt normaal gesproken veroorzaakt door een of beide van de volgende factoren:
Toepassingen voor het kopiëren van bestanden, zoals Windows Verkenner en RDP, gebruiken geen meerdere threads bij het kopiëren van bestanden. Gebruik voor betere prestaties een toepassing voor het kopiëren van bestanden met meerdere threads, zoals Richcopy , om bestanden te kopiëren met behulp van 16 of 32 threads. Als u het threadnummer voor het kopiëren van bestanden in Richcopy wilt wijzigen, klikt u op Opties voor het kopiëren van het>bestand door actie> te kopiëren.
Notitie
Niet alle toepassingen werken hetzelfde en niet alle toepassingen/processen maken gebruik van alle threads. Als u de test uitvoert, ziet u dat sommige threads leeg zijn en geen nauwkeurige doorvoerresultaten opleveren. Als u de prestaties van de bestandsoverdracht van uw toepassing wilt controleren, gebruikt u meerdere threads door het aantal threads achter elkaar te verhogen of te verlagen om de optimale doorvoer van de toepassing of bestandsoverdracht te vinden.
Onvoldoende lees-/schrijfsnelheid voor VM-schijven. Zie Problemen met Azure Storage oplossen voor meer informatie.
Externe interface voor on-premises apparaten
Vermeld de subnetten van on-premises bereiken die u wilt bereiken via VPN op lokale netwerkgateway. Definieer tegelijkertijd de VNET-adresruimte in Azure op het on-premises apparaat.
Gateway op basis van route: het beleid of de verkeersselector voor op route gebaseerde VPN's worden geconfigureerd als any-to-any (of jokertekens).
Op beleid gebaseerde gateway: op beleid gebaseerde VPN's versleutelen en directe pakketten via IPsec-tunnels op basis van de combinaties van adresvoorvoegsels tussen uw on-premises netwerk en het Azure VNet. Het beleid (of de verkeersselector) wordt gewoonlijk gedefinieerd als een toegangslijst in de VPN-configuratie.
UsePolicyBasedTrafficSelector-verbindingen : ('UsePolicyBasedTrafficSelectors' om te $True op een verbinding configureert de Azure VPN-gateway om on-premises verbinding te maken met op beleid gebaseerde VPN-firewall. Als u PolicyBasedTrafficSelectors inschakelt, moet u ervoor zorgen dat uw VPN-apparaat beschikt over de overeenkomende verkeerskiezers die zijn gedefinieerd met alle combinaties van uw on-premises netwerkvoorvoegsels (lokale netwerkgateway) naar en van de voorvoegsels van het virtuele Azure-netwerk in plaats van any-to-any.
Ongepaste configuratie kan leiden tot frequente verbroken verbindingen binnen de tunnel, pakketverminderingen, slechte doorvoer en latentie.
Latentie controleren
U kunt latentie controleren met behulp van de volgende hulpprogramma's:
- WinMTR
- TCPTraceroute
ping
enpsping
(Deze hulpprogramma's kunnen een goede schatting van RTT bieden, maar ze kunnen niet in alle gevallen worden gebruikt.)
Als u een piek in hoge latentie ziet bij een van de hops voordat u MS Network backbone invoert, kunt u verdergaan met onderzoek met uw internetprovider.
Als een grote, ongebruikelijke latentiepieken wordt opgemerkt vanuit hops binnen 'msn.net', neemt u contact op met ms-ondersteuning voor verder onderzoek.
Volgende stappen
Raadpleeg de volgende koppeling voor meer informatie of hulp: