Share via


VPN teljesítményének érvényesítése virtuális hálózaton

Figyelemfelhívás

Ez a cikk a CentOS-ra, egy olyan Linux-disztribúcióra hivatkozik, amely közel áll az élettartam (EOL) állapotához. Fontolja meg a használatát, és ennek megfelelően tervezze meg. További információ: CentOS End Of Life útmutató.

A VPN Gateway-kapcsolat lehetővé teszi, hogy biztonságos, helyek közötti kapcsolatot létesítsen az Azure-on belüli virtuális hálózat és a helyszíni informatikai infrastruktúra között.

Ez a cikk bemutatja, hogyan ellenőrizheti a hálózati átviteli sebességet a helyszíni erőforrásoktól az Azure-beli virtuális gépekig.

Feljegyzés

Ez a cikk a gyakori problémák diagnosztizálásához és megoldásához nyújt segítséget. Ha az alábbi információk segítségével nem tudja megoldani a problémát, forduljon az ügyfélszolgálathoz.

Áttekintés

A VPN Gateway-kapcsolat a következő összetevőket foglalja magában:

  • Helyszíni VPN-eszköz (Az ellenőrzött VPN-eszközök listájának megtekintése.)
  • Nyilvános internet
  • Azure VPN Gateway
  • Azure VM

Az alábbi ábra egy helyszíni hálózat logikai kapcsolatát mutatja be egy Azure-beli virtuális hálózattal VPN-en keresztül.

Az ügyfélhálózat logikai Csatlakozás tivitása az MSFT-hálózatra VPN használatával

A várható bejövő/kimenő forgalom maximális számának kiszámítása

  1. Határozza meg az alkalmazás alapkonfigurációs átviteli sebességére vonatkozó követelményeket.
  2. Határozza meg az Azure VPN Gateway átviteli sebességkorlátait. További segítségért tekintse meg a VPN Gatewayről szóló szakasz "Átjáró termékváltozatai" című szakaszát.
  3. Határozza meg az Azure-beli virtuális gépek átviteli sebességére vonatkozó útmutatást a virtuális gép méretéhez.
  4. Határozza meg az internetszolgáltató (ISP) sávszélességét.
  5. Számítsa ki a várt átviteli sebességet a virtuális gép, a VPN Gateway vagy az INTERNETP minimális sávszélességének figyelembevételével; amelyet megabit/másodpercben (/) osztva nyolcval (8) kell mérni. Ez a számítás másodpercenként megabájtos értéket ad.

Ha a számított átviteli sebesség nem felel meg az alkalmazás alapkonfigurációs átviteli sebességére vonatkozó követelményeknek, növelnie kell a szűk keresztmetszetként azonosított erőforrás sávszélességét. Az Azure VPN Gateway átméretezéséhez tekintse meg az átjáró termékváltozatának módosítását. A virtuális gépek átméretezéséhez lásd : Virtuális gép átméretezése. Ha nem tapasztalja a várt internetes sávszélességet, akkor az internetszolgáltatóval is kapcsolatba léphet.

Feljegyzés

A VPN Gateway átviteli sebessége az összes helyek közötti\VNET–VNET vagy pont–hely kapcsolat összesítése.

Hálózati átviteli sebesség ellenőrzése teljesítményeszközökkel

Ezt az ellenőrzést nem munkaidőben kell elvégezni, mivel a VPN-alagút átviteli sebességének tesztelés közbeni telítettsége nem ad pontos eredményeket.

A teszthez használt eszköz az iPerf, amely Windows és Linux rendszeren is működik, és ügyfél- és kiszolgálói módokkal is rendelkezik. Windows rendszerű virtuális gépek esetén 3 Gb/s-ra van korlátozva.

Ez az eszköz nem végez olvasási/írási műveleteket a lemezen. Kizárólag ön által generált TCP-forgalmat hoz létre az egyik végéről a másikra. Az ügyfél- és kiszolgálócsomópontok közötti rendelkezésre álló sávszélességet mérő kísérletezésen alapuló statisztikákat hoz létre. Két csomópont közötti teszteléskor az egyik csomópont kiszolgálóként, a másik csomópont pedig ügyfélként működik. A teszt befejezése után javasoljuk, hogy a csomópontok szerepköreit megfordítva tesztelje a feltöltési és letöltési átviteli sebességet mindkét csomóponton.

IPerf letöltése

Töltse le az iPerf fájlt. Részletekért lásd az iPerf dokumentációját.

Feljegyzés

A cikkben tárgyalt harmadik féltől származó termékeket a Microsofttól független vállalatok gyártják. A Microsoft sem hallgatólagosan, sem egyéb módon nem vállal szavatosságot a termékek teljesítményére vagy megbízhatóságára vonatkozóan.

Az iPerf futtatása (iperf3.exe)

  1. Engedélyezze a forgalmat engedélyező NSG/ACL-szabályt (az Azure-beli virtuális gépen való nyilvános IP-címteszteléshez).

  2. Mindkét csomóponton engedélyezze az 5001-s port tűzfalkivételét.

    Windows: Futtassa a következő parancsot rendszergazdaként:

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

    Ha a tesztelés befejezésekor el szeretné távolítani a szabályt, futtassa a következő parancsot:

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

    Azure Linux: Az Azure Linux-rendszerképek megengedő tűzfalakkal rendelkeznek. Ha egy alkalmazás figyel egy portot, a forgalom engedélyezett. A védett egyéni rendszerképek számára előfordulhat, hogy explicit módon megnyitott portokat kell megnyitni. A linuxos operációsrendszer-rétegű tűzfalak közé tartoznak iptablesaz , ufwvagy firewalld.

  3. A kiszolgálócsomóponton váltson arra a könyvtárra, ahol a iperf3.exe kinyerik. Ezután futtassa az iPerf-et kiszolgáló módban, és állítsa be az 5001-as porton a következő parancsok szerint:

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

    Feljegyzés

    Az 5001-s port testre szabható, hogy figyelembe vegyék a környezet bizonyos tűzfalkorlátozásait.

  4. Az ügyfélcsomóponton váltson arra a könyvtárra, ahol az iperf-eszközt kinyeri, majd futtassa a következő parancsot:

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

    Az ügyfél 30 másodpercnyi forgalmat irányít az 5001-s porton a kiszolgálóra. A "-P" jelző azt jelzi, hogy 32 egyidejű kapcsolatot létesítünk a kiszolgálócsomóponttal.

    Az alábbi képernyőn a példa kimenete látható:

    Hozam

  5. (NEM KÖTELEZŐ) A tesztelési eredmények megőrzéséhez futtassa a következő parancsot:

    iperf3.exe -c IPofTheServerToReach -t 30 -p 5001 -P 32  >> output.txt
    
  6. Az előző lépések elvégzése után hajtsa végre ugyanazokat a lépéseket a szerepkörök megfordításával, hogy a kiszolgálócsomópont legyen az ügyfélcsomópont, és fordítva.

Feljegyzés

Nem az Iperf az egyetlen eszköz. Az NTTTCP egy alternatív megoldás a teszteléshez.

Windows rendszerű virtuális gépek tesztelése

Latte.exe betöltése a virtuális gépekre

A Latte.exe legújabb verziójának letöltése

Fontolja meg a Latte.exe külön mappába helyezését, például c:\tools

Latte.exe engedélyezése a Windows tűzfalon keresztül

A fogadón hozzon létre egy Engedélyezési szabályt a Windows tűzfalon, amely lehetővé teszi a Latte.exe forgalom érkezését. A legegyszerűbb, ha a teljes Latte.exe programot név szerint engedélyezi ahelyett, hogy adott TCP-portokat engedélyezne.

A Latte.exe engedélyezése a Windows tűzfalon, mint ez

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

Ha például a latte.exe a "c:\tools" mappába másolta, ez lenne a parancs

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

Késési tesztek futtatása

Indítsa el a latte.exe a RECEIVER-en (futtassa a CMD-ből, nem a PowerShellből):

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

Körülbelül 65 ezres iteráció elég hosszú ahhoz, hogy reprezentatív eredményeket ad vissza.

Minden elérhető portszám rendben van.

Ha a virtuális gép IP-címe 10.0.0.4, a következőképpen nézne ki

latte -c -a 10.0.0.4:5005 -i 65100

Indítsa el a latte.exe a Standard kiadás NDERen (futtassa a CMD-ből, nem a PowerShellből)

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

Az eredményül kapott parancs ugyanaz, mint a fogadón, kivéve a "-c" hozzáadását, amely azt jelzi, hogy ez az "ügyfél" vagy a feladó

latte -c -a 10.0.0.4:5005 -i 65100

Várja meg az eredményeket. Attól függően, hogy milyen messze vannak egymástól a virtuális gépek, eltarthat néhány percig. Érdemes lehet kevesebb iterációval kezdeni a sikeres tesztelést, mielőtt hosszabb teszteket futtat.

Linuxot futtató virtuális gépek tesztelése

A SockPerf használatával tesztelje a virtuális gépeket.

A SockPerf telepítése a virtuális gépekre

Linux rendszerű virtuális gépeken (Standard kiadás NDER és RECEIVER) futtassa ezeket a parancsokat a SockPerf előkészítéséhez a virtuális gépeken:

CentOS / RHEL – A GIT és más hasznos eszközök telepítése

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 – A GIT és más hasznos eszközök telepítése

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 – mind

Bash parancssorból (feltételezi, hogy a Git telepítve van)

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

A make lassabb, több percet is igénybe vehet

make

A telepítés gyorssá tétele

sudo make install

A SockPerf futtatása a virtuális gépeken

Mintaparancsok a telepítés után. Kiszolgáló/fogadó – feltételezi, hogy a kiszolgáló IP-címe 10.0.0.4

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

Ügyfél – feltételezi, hogy a kiszolgáló IP-címe 10.0.0.4

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

Feljegyzés

Győződjön meg arról, hogy nincsenek köztes ugrások (például virtuális berendezés) a virtuális gép és az átjáró közötti átviteli sebesség tesztelése során. Ha a fenti iPERF/NTTTCP-tesztekből gyenge eredmények (az általános átviteli sebesség tekintetében) származnak, tekintse meg ezt a cikket a probléma lehetséges kiváltó okai mögötti főbb tényezők megértéséhez:

Különösen az ügyféltől és a kiszolgálótól párhuzamosan gyűjtött csomagrögzítési nyomkövetések (Wireshark/Network Monitor) elemzése segít a hibás teljesítmény értékelésében. Ezek a nyomkövetések csomagvesztést, nagy késést és MTU-méretet tartalmazhatnak. töredezettség, TCP 0 Ablak, Elavult töredékek stb.

Lassú fájlmásolási problémák elhárítása

Még ha az előző lépésekkel értékelt teljes átviteli sebesség (iPERF/NTTCP/stb.) is jó volt, előfordulhat, hogy lassú fájlmunkát tapasztal a Windows Intéző használatakor, vagy egy RDP-munkamenet húzásával és áthúzásával. Ez a probléma általában az alábbi tényezők egyikének vagy mindkettőnek köszönhető:

  • A fájlmásolási alkalmazások, például a Windows Intéző és az RDP nem használnak több szálat a fájlok másolásakor. A jobb teljesítmény érdekében használjon többszálú fájlmásoló alkalmazást, például a Richcopyt a fájlok másolásához 16 vagy 32 szál használatával. A Richcopyban a fájlmásolás szálszámának módosításához kattintson a Műveletmásolás>beállításai>Fájlmásolás parancsra.

    Lassú fájlmásolási problémák

    Feljegyzés

    Nem minden alkalmazás működik azonosan, és nem minden alkalmazás/folyamat használja az összes szálat. Ha futtatja a tesztet, láthatja, hogy egyes szálak üresek, és nem adnak pontos átviteli sebességet. Az alkalmazás fájlátviteli teljesítményének ellenőrzéséhez használjon többszálas műveletet a szál számának egymás utáni növelésével vagy csökkentésével az alkalmazás vagy a fájlátvitel optimális átviteli sebességének megkereséséhez.

  • A virtuálisgép-lemez olvasási/írási sebessége nem megfelelő. További információkért lásd az Azure Storage hibaelhárítását.

Helyszíni eszköz külső felület

Megemlítette azon helyszíni tartományok alhálózatait, amelyeket az Azure-nak vpn-en keresztül szeretne elérni a helyi hálózati átjárón keresztül. Ezzel egyidejűleg adja meg az Azure-ban a virtuális hálózat címterét a helyszíni eszközre.

  • Útvonalalapú átjáró: Az útvonalalapú VPN-ek házirendje vagy forgalomválasztója bármilyen (vagy helyettesítő) értékűként van konfigurálva.

  • Szabályzatalapú átjáró: A házirendalapú VPN-ek az IPsec-alagutakon keresztül titkosítják és irányítják a csomagokat a helyszíni hálózat és az Azure virtuális hálózat címelőtagjainak kombinációi alapján. A házirend (vagy forgalomválasztó) általában egy hozzáférési listaként van megadva a VPN-konfigurációban.

  • UsePolicyBasedTrafficSelector kapcsolatok: ("UsePolicyBasedTrafficSelectors" a kapcsolat $True konfigurálja az Azure VPN Gatewayt, hogy a helyszíni házirendalapú VPN-tűzfalhoz csatlakozzon. Ha engedélyezi a PolicyBasedTrafficSelectors szolgáltatást, győződjön meg arról, hogy a VPN-eszköz rendelkezik a helyszíni hálózat (helyi hálózati átjáró) előtagjainak és az Azure-beli virtuális hálózati előtagok minden kombinációjával definiált, egyező forgalomválasztókkal, ahelyett, hogy bármelyikhez.

A nem megfelelő konfiguráció gyakran megszakadhat az alagútban, a csomagvesztések, a hibás átviteli sebesség és a késés.

Késés ellenőrzése

A késést az alábbi eszközökkel ellenőrizheti:

  • WinMTR
  • TCPTraceroute
  • ping és psping (Ezek az eszközök jó becslést adhatnak az RTT-ről, de nem használhatók minden esetben.)

Késés ellenőrzése

Ha az MS Network gerinchálózatának beírása előtt nagy késést tapasztal bármelyik ugrásnál, érdemes lehet további vizsgálatokat folytatnia az internetszolgáltatónál.

Ha a "msn.net" komlói nagy, szokatlan késési csúcsot észlelnek, további vizsgálatokért forduljon az MS ügyfélszolgálatához.

Következő lépések

További információért vagy segítségért tekintse meg az alábbi hivatkozást: