Virtuális WAN – GYIK

Az Azure Virtual WAN a GA-ban van?

Igen, az Azure Virtual WAN általánosan elérhető (GA). A Virtual WAN azonban számos funkcióból és forgatókönyvből áll. A Virtual WAN-ban vannak olyan funkciók vagy forgatókönyvek, amelyeknél a Microsoft alkalmazza az előzetes verzió címkéjét. Ezekben az esetekben az adott funkció vagy maga a forgatókönyv előzetes verzióban érhető el. Ha nem használ egy adott előzetes verziójú funkciót, az általános GA támogatás érvényes. Az előzetes verzió támogatásáról további információt a Microsoft Azure Előzetes verzió kiegészítő használati feltételei című témakörben talál.

Mely helyek és régiók érhetők el?

A Virtual WAN elérhető régióinak megtekintéséhez tekintse meg a régiónként elérhető termékeket. Adja meg a Virtual WAN nevet a terméknévként.

Szüksége van a felhasználónak SD-WAN/VPN-eszközökből álló hub-and-spoke rendszerre az Azure Virtual WAN használatához?

A Virtual WAN számos funkciót biztosít egyetlen üvegpanelbe beépítve. Ez a következőket foglalja magában:

A Virtual WAN használatának megkezdéséhez nem szükséges az összes ilyen használati eset. Első lépésként csak egy használati esetet használhat.

A Virtual WAN-architektúra egy központi és küllős architektúra beépített méretezhetőséggel és teljesítménnyel, amelyben az ágak (VPN/SD-WAN-eszközök), a felhasználók (Azure VPN-ügyfelek, openVPN vagy IKEv2-ügyfelek), az ExpressRoute-kapcsolatcsoportok és a virtuális hálózatok küllőkként szolgálnak a virtuális központ(ok) felé. Minden központ teljes hálóban csatlakozik egy Standard Virtual WAN-hoz, így a felhasználó egyszerűen használhatja a Microsoft gerincét bármilyen küllős kapcsolathoz. SD-WAN/VPN-eszközökkel való hub-and-spoke modell esetén a felhasználók manuálisan konfigurálhatják az Azure Virtual WAN portálon, vagy a Virtual WAN Partner CPE (SD-WAN/VPN) használatával alakíthatják ki a kapcsolatot az Azure-hoz.

A virtuális WAN-partnerek automatizálást biztosítanak a kapcsolatokhoz. Lehetővé teszi az eszközadatok Azure-ba való exportálását, az Azure-konfiguráció letöltését és az Azure Virtual WAN-központhoz való kapcsolódást. Pont–hely/felhasználói VPN-kapcsolat esetén támogatjuk az Azure VPN-ügyfelet, az OpenVPN-t vagy az IKEv2-ügyfelet.

Le tudja tiltani a teljes hálós központokat a Virtual WAN-ban?

A Virtual WAN kétféle módon érhető el: Alapszintű és Standard. Az alapszintű Virtual WAN-ban a hubok nincsenek összekapcsolva. A standard virtuális WAN-ban a hubok hálóba vannak kötve, és automatikusan csatlakoznak a virtuális WAN első beállításakor. A felhasználónak semmi konkrétat nem kell tennie. A felhasználónak nem kell letiltania vagy engedélyeznie a funkciót a hálós központok megszerzéséhez. A Virtual WAN számos útválasztási lehetőséget biztosít a végpontok (VNet, VPN vagy ExpressRoute) közötti forgalom irányításához. Ez biztosítja a teljesen összekapcsolt csomópontok egyszerűségét, valamint az igény szerinti forgalomirányítás rugalmasságát.

Miért jelenik meg hiba a Virtual WAN-erőforrásokon végzett műveletek végrehajtásához szükséges érvénytelen hatókörrel és engedélyezéssel kapcsolatban?

Ha a következő formátumban hibaüzenet jelenik meg, győződjön meg arról, hogy a következő engedélyek vannak konfigurálva: Virtual WAN-szerepkörök és engedélyek

Hibaüzenet formátuma: "Az objektumazonosítóval {} rendelkező ügyfél nem rendelkezik engedéllyel a művelet {}{} hatókörön keresztüli végrehajtására, vagy a hatókör érvénytelen. A szükséges engedélyekkel kapcsolatos részletekért látogasson el {}ide. Ha a hozzáférést nemrég engedélyezték, frissítse a hitelesítő adatokat."

Hogyan kezelik a rendelkezésre állási zónákat és a rugalmasságot a Virtual WAN-ban?

A Virtual WAN a központban elérhető hubok és szolgáltatások gyűjteménye. A felhasználó igény szerint annyi Virtual WAN-nal rendelkezhet. A Virtual WAN-központban több szolgáltatás is létezik, például VPN, ExpressRoute stb. Ezek a szolgáltatások automatikusan üzembe lesznek helyezve a rendelkezésre állási zónákban (az Azure Firewall kivételével), ha a régió támogatja a rendelkezésre állási zónákat. Ha egy régió a központ kezdeti üzembe helyezése után rendelkezésre állási zónává válik, a felhasználó újra létrehozhatja az átjárókat, ami elindítja a rendelkezésre állási zóna üzembe helyezését. Az összes átjáró aktív-aktívként van kiépítve egy központban, ami azt jelenti, hogy a központon belül rugalmasság van beépítve. A felhasználók több központhoz is csatlakozhatnak, ha rugalmasságot szeretnének a régiók között.

Jelenleg az Azure Firewall üzembe helyezhető a rendelkezésre állási zónák támogatásához az Azure Firewall Manager Portal, a PowerShell vagy a PARANCSSOR használatával. Jelenleg nincs mód meglévő tűzfal konfigurálására a rendelkezésre állási zónákban való üzembe helyezéshez. Törölnie és újra kell üzembe helyeznie az Azure Firewallt.

Bár a Virtual WAN fogalma globális, a tényleges Virtual WAN-erőforrás Resource Manager-alapú, és regionálisan van üzembe helyezve. Ha magának a virtuális WAN-régiónak problémája van, a virtuális WAN összes központja továbbra is működni fog. A felhasználó azonban nem hozhat létre új központokat, amíg el nem érhető a virtuális WAN-régió.

Hogyan törölhetem vagy kitisztíthatom a Virtual WAN-erőforrásaimat?

Ha már nincs szüksége a létrehozott erőforrásokra, törölje őket. A Virtual WAN egyes erőforrásait függőségek miatt bizonyos sorrendben törölni kell. A törlés nagyjából 30 percet vesz igénybe.

  1. Nyissa meg a létrehozott virtuális WAN-t.

  2. Válassza ki a virtuális WAN-hoz társított virtuális központot a központ oldalának megnyitásához.

  3. Törölje az összes átjáró-entitást az egyes átjárótípusokhoz tartozó alábbi sorrend szerint. Ez 30 percet is igénybe vehet.

    VPN:

    • VPN-kapcsolatok leválasztása
    • VPN-kapcsolatok törlése
    • VPN-átjárók törlése

    ExpressRoute:

    • ExpressRoute-kapcsolatok törlése
    • ExpressRoute-átjárók törlése

  4. Ismételje meg az ismétlést a virtuális WAN-hoz társított összes központ esetében.

  5. Ezen a ponton törölheti a központokat, vagy az erőforráscsoport törlésekor később törölheti a központokat.

  6. Lépjen az Azure Portal erőforráscsoportjához.

  7. Válassza az Erőforráscsoport törlése lehetőséget. Ez törli az erőforráscsoport többi erőforrását, beleértve a központokat és a virtuális WAN-t is.

Meg lehet osztani a tűzfalat egy védett központban más központokkal?

Nem, minden Azure Virtual Hubnak saját tűzfallal kell rendelkeznie. Egy másik biztonságos központ tűzfalára mutató egyéni útvonalak üzembe helyezése sikertelen lesz, és nem fejeződik be sikeresen. Fontolja meg, hogy ezeket a központokat saját tűzfalakkal védett hubokká konvertálja.

Melyik ügyfelet támogatja az Azure Virtual WAN felhasználói VPN (pont–hely) ?

A Virtual WAN támogatja az Azure VPN-ügyfelet, az OpenVPN-ügyfelet vagy bármely IKEv2-ügyfelet. Az Azure VPN-ügyfél támogatja a Microsoft Entra-hitelesítést. Legalább a Windows 10 17763.0-s vagy újabb verziójára van szükség. Az OpenVPN-ügyfél(ek) támogathatják a tanúsítványalapú hitelesítést. Miután a tanúsítványalapú hitelesítés ki van jelölve az átjárón, megjelenik az eszközre letölteni kívánt.ovpn* fájl. Az IKEv2 támogatja a tanúsítványt és a RADIUS-hitelesítést is.

A (előzetes verzió) Azure VPN-ügyfél kivonása Linuxhoz

A linuxos Azure VPN-ügyfél (előzetes verzió) 2026. augusztus 31-én megszűnik. További információ: Azure Vpn Client for Linux (előzetes verzió) – A kivonás áttekintése cikk.

Felhasználói VPN esetén (pont–hely) – miért van a P2S-ügyfélkészlet két útvonalra felosztva?

Mindegyik átjárónak két példánya van. A felosztás úgy történik, hogy az egyes átjárópéldányok egymástól függetlenül lefoglalhassák az ügyfél IP-címeit a csatlakoztatott ügyfelek számára, és a virtuális hálózatból érkező forgalmat a rendszer a megfelelő átjárópéldányra irányítja vissza, hogy elkerülje az átjárók közötti ugrást.

Hogyan adhatok hozzá DNS-kiszolgálókat a P2S klienseknek?

A P2S-ügyfelekhez két lehetőség van DNS-kiszolgálók hozzáadására. Az első módszer előnyben részesített, mivel az ügyfél helyett az átjáróhoz adja hozzá az egyéni DNS-kiszolgálókat.

  1. Az egyéni DNS-kiszolgálók hozzáadásához használja a következő PowerShell-szkriptet. Cserélje le a környezet értékeit.

    // Define variables
$rgName = "testRG1"
$virtualHubName = "virtualHub1"
$P2SvpnGatewayName = "testP2SVpnGateway1"
$vpnClientAddressSpaces = 
$vpnServerConfiguration1Name = "vpnServerConfig1"
$vpnClientAddressSpaces = New-Object string[] 2
$vpnClientAddressSpaces[0] = "192.168.2.0/24"
$vpnClientAddressSpaces[1] = "192.168.3.0/24"
$customDnsServers = New-Object string[] 2
$customDnsServers[0] = "7.7.7.7"
$customDnsServers[1] = "8.8.8.8"
$virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
$vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name

// Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers

// Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
$P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
$updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 

// Re-generate VPN profile either from PS/Portal for VPN clients to have the specified dns servers

  2. Ha a Windows 10-hez készült Azure VPN-ügyfelet használja, az importálás előtt módosíthatja a letöltött profil XML-fájlját, és hozzáadhatja a <dnsservers><dnsserver></dnsserver></dnsservers> címkéket.

       <azvpnprofile>
   <clientconfig>

       <dnsservers>
           <dnsserver>x.x.x.x</dnsserver>
           <dnsserver>y.y.y.y</dnsserver>
       </dnsservers>

   </clientconfig>
   </azvpnprofile>

A (pont-hely típusú) felhasználói VPN hány ügyfélkapcsolat létesítését támogatja?

Az alábbi táblázat a különböző méretezési egységekben támogatott pont–hely VPN-átjáró egyidejű kapcsolatainak és összesített átviteli sebességének számát ismerteti.

Skálázási egység Átjárópéldányok Támogatott egyidejű kapcsolatok Összesített átviteli sebesség
1 2 500 0,5 Gb/s
2 2 500 1 Gbit/s
3 2 500 1,5 Gb/s
4 2 1000 2 Gbit/s
5 2 1000 2,5 Gbps
6 2 1000 3 Gb/s
7 2 5000 3,5 Gb/s
8 2 5000 4 Gb/s
9 2 5000 4,5 Gb/s
10 2 5000 5 Gb/s
11 2 10000 5,5 Gb/s
12 2 10000 6 Gb/s
13 2 10000 6,5 Gb/s
14 2 10000 7 Gb/s
15 2 10000 7,5 Gb/s
16 2 10000 8 Gb/s
17 2 10000 8,5 Gb/s
18 2 10000 9 Gb/s
19 2 10000 9,5 Gb/s
20 2 10000 10 Gbit/s
40 4 20000 20 Gbit/s
60 6 30000 30 Gb/s
80 8 40000 40 Gbit/s
100 10 50000 50 Gb/s
120 12 60000 60 Gb/s
140 14 70000 70 Gb/s
160 16 80000 80 Gb/s
180 18 90000 90 Gb/s
200 20 100000 100 Gbit/s

Tegyük fel például, hogy a felhasználó egy skálázási egységet választ. Minden méretezési egység egy aktív-aktív átjáró üzembe helyezését jelentené, és az egyes példányok (ebben az esetben a 2) legfeljebb 500 kapcsolatot támogatnának. Mivel átjárónként 500 kapcsolat * 2 érhető el, az nem azt jelenti, hogy 500 helyett 1000-et tervez ehhez a méretezési egységhez. Előfordulhat, hogy a példányokat szervizelni kell, amelyek során a további 500-ra vonatkozó kapcsolat megszakadhat, ha túllépi a javasolt kapcsolatszámot.

A 20-nál nagyobb skálázási egységekkel rendelkező átjárók esetében további magas rendelkezésre állású átjárópéldánypárok vannak üzembe helyezve, hogy további kapacitást biztosítsanak a felhasználók csatlakoztatásához. Minden példánypár legfeljebb 10 000 további felhasználót támogat. Ha például 100 méretezési egységgel rendelkező átjárót helyez üzembe, 5 átjárópár (összesen 10 példány) lesz üzembe helyezve, és akár 50 000 (10 000 felhasználó x 5 átjárópár) egyidejű felhasználó is csatlakozhat.

Emellett mindenképpen tervezze meg az állásidőt, ha úgy dönt, hogy fel- vagy leskáláz a skálázási egységen, vagy módosítja a pont–hely konfigurációt a VPN-átjárón.

A felhasználói VPN (pont–hely) esetében támogatott a Microsoft regisztrált alkalmazása az Entra Id Authenticationben?

Igen, a Microsoft által regisztrált alkalmazás támogatott a Virtual WAN-ban. A felhasználói VPN-t manuálisan regisztrált alkalmazásból a Microsoft által regisztrált alkalmazásba migrálhatja a biztonságosabb kapcsolat érdekében.

Mik a Virtual WAN-átjáró skálázási egységei?

A skálázási egység egy olyan egység, amely egy átjáró összesített átviteli sebességének kiválasztására van definiálva a Virtuális központban. 1 skálázási egység VPN = 500 Mbps. 1 expressRoute skálázási egység = 2 Gb/s. Példa: A VPN 10 skálázási egysége 500 Mbps * 10 = 5 Gbps értéket jelent.

Igény szerint manuálisan is fel- vagy leskálázhatja az átjáró méretezési egységét. Az átjáróbeállításokról további információt a Virtual WAN-átjáró beállításairól szóló cikkben talál.

Az átjáró-méretezési egységek támogatási korlátaival kapcsolatos további információkért lásd:

Milyen hatással van a Virtual WAN ExpressRoute-átjáró átjáróméret-egységeinek módosítása?

Az átjáró skálázási egységeinek módosításakor vegye figyelembe a következő szempontokat:

  • Forgalmi kapacitás: Győződjön meg arról, hogy a kiépített méretezési egységek támogatják a forgalmi követelményeket.

  • TCP-újracsatlakozások: Előfordulhat, hogy a skálázási egység módosítása során TCP-újracsatlakozások lépnek fel, ami kisebb fennakadásokat okozhat.

  • A privát végpontok hatása: A skálázási egységek változásai hatással lehetnek a privát végpontok kapcsolatára. Tekintse át az üzembe helyezést, és kövesse a Private Link használata a Virtual WAN-ban című témakörben ismertetett ajánlott eljárásokat.

Az átjárók méretezési egységeivel és a kapacitástervezéssel kapcsolatos további információkért lásd a Virtual WAN-átjáró beállításainak ismertetése című témakört.

Mi a különbség az Azure-beli virtuális hálózati átjáró (VPN Gateway) és az Azure Virtual WAN VPN Gateway között?

A Virtual WAN nagy léptékben biztosít helyek közötti kapcsolatokat, és kifejlesztése során elsősorban az átviteli sebességet, a méretezhetőséget és a könnyű használatot tartották szem előtt. Amikor egy webhelyet egy Virtual WAN VPN-átjáróhoz csatlakoztat, az eltér a "helyek közötti VPN" átjárótípust használó hagyományos virtuális hálózati átjárótól. Ha távoli felhasználókat szeretne csatlakoztatni a Virtual WAN-hoz, egy "pont–hely VPN" típusú átjárótípust használ. A helyek közötti és helyek közötti VPN-átjárók különálló entitások a Virtual WAN hubon, és egyenként kell üzembe helyezni. Hasonlóképpen, amikor egy ExpressRoute-kapcsolatcsoportot egy Virtual WAN-központhoz csatlakoztat, az más erőforrást használ az ExpressRoute-átjáróhoz, mint az "ExpressRoute" átjárótípust használó szokásos virtuális hálózati átjáró.

A Virtual WAN akár 20 Gb/s-os összesített átviteli sebességet is támogat VPN és ExpressRoute esetén. A Virtual WAN emellett automatizálással is rendelkezik a CPE-ág-eszközpartnerek ökoszisztémájával való kapcsolathoz. A CPE fióki eszközök beépített automatizálással rendelkeznek, amely automatikusan konfigurálja és csatlakoztatja az Azure Virtual WAN-hoz. Ezek az eszközök az SD-WAN- és a VPN-partnerek egyre bővülő körétől szerezhetők be. Tekintse meg az előnyben részesített partnerlistát.

Miben különbözik a Virtual WAN az Azure-beli virtuális hálózati átjáróktól?

A virtuális hálózati átjáró VPN-je legfeljebb 100 alagútra korlátozódik. Kapcsolatokhoz nagy mennyiségű VPN-forgalmat bonyolító Virtual WAN használata javasolt. Virtuális központonként legfeljebb 1000 ágkapcsolatot csatlakoztathat, központonként 20 Gb/s összesítéssel. A kapcsolatok aktív-aktív alagútnak minősülnek a helyszíni VPN-eszköz és a virtuális központ között. Régiónként több virtuális központ is lehet. Ez azt jelenti, hogy több mint 1000 ágat csatlakoztathat egyetlen Azure-régióhoz több Virtual WAN-központ üzembe helyezésével az Azure-régióban, amelyek mindegyike saját helyek közötti VPN-átjáróval rendelkezik.

Mi az ajánlott algoritmus és a másodpercenkénti csomagszám helyek közötti példányonként a Virtual WAN hubban? Példányonként hány alagutat támogatnak? Mi az egyetlen alagútban támogatott maximális átviteli sebesség?

A Virtual WAN 2 aktív helyek közötti VPN-átjárópéldányt támogat egy virtuális központban. Ez azt jelenti, hogy egy virtuális központban 2 aktív-aktív VPN-átjárópéldány található. A karbantartási műveletek során az egyes példányok egyenként frissülnek, ami miatt a felhasználó rövid ideig csökkentheti a VPN-átjáró összesített átviteli sebességét.

Bár a Virtual WAN VPN számos algoritmust támogat, javaslatunk GCMAES256 az IPSEC-titkosításhoz és az integritáshoz az optimális teljesítmény érdekében. Az AES256 és az SHA256 kevésbé teljesítménnyel rendelkezik, ezért hasonló algoritmustípusok esetében teljesítménycsökkenésre, például késésre és csomagcsökkenésre lehet számítani.

A másodpercenkénti csomagok vagy a PPS a csomagok teljes számának és a példányonként támogatott átviteli sebességnek a tényezője. Ezt legjobban egy példával lehet értelmezni. Tegyük fel, hogy egy 500 Mbps-os, egy egységnyi skálázással rendelkező VPN-átjárópéldányt telepítenek egy virtuális WAN-központban helyek között. 1400 csomagméretet feltételezve az adott VPN Gateway-példány várható PPS-je legfeljebb = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.

A Virtual WAN a VPN-kapcsolat, a kapcsolatkapcsolat és az alagutak fogalmait is ismerteti. Egyetlen VPN-kapcsolat kapcsolatkapcsolatokból áll. A Virtual WAN legfeljebb 4 kapcsolatkapcsolatot támogat a VPN-kapcsolatokban. Minden kapcsolat két IPsec-alagútból áll, amelyek egy virtuális központban üzembe helyezett aktív-aktív VPN-átjáró két példányában végződnek. Egy aktív példányban legfeljebb 1 000 alagút végződhet. Ez azt is jelenti, hogy az 1 példány átviteli sebessége összesítve érhető el az adott példányhoz csatlakozó összes alagútban. Minden alagút bizonyos átviteli sebességértékekkel is rendelkezik. Ha több alagút csatlakozik egy alacsonyabb értékű skálázási egységátjáróhoz, érdemes kiértékelni az alagútonkénti igényt, és megtervezni egy VPN-átjárót, amely a VPN-példányban végződő összes alagút átviteli sebességének összesített értéke.

A Virtual WAN által támogatott különböző méretezési egységek értékei

Skálázási egység Alagútonkénti maximális átviteli sebesség (Mbps) Maximális PPS alagútonként Példányonkénti átviteli sebesség (Mbps) Példányonkénti PPS maximális száma
1 500 47K 500 47K
2 1000 94K 1000 94K
3 1500 140K 1500 140K
4 1500 140K 2000 187K
5 1500 140K 2500 234K
6 1500 140K 3000 281K
7 2300 215K 3500 328K
8 2300 215K 4000 374K
9 2300 215K 4500 421K
10 2300 215K 5000 468K
11 2300 215K 5500 515K
12 2300 215K 6000 562K
13 2300 215K 6500 609K
14 2300 215K 7000 655K
15 2300 215K 7500 702K
16 2300 215K 8000 749K
17 2300 215K 8500 796K
18 2300 215K 9000 843K
19 2300 215K 9500 889K
20 2300 215K 10000 936K

Note

Minden szám GCM-algoritmuson alapul.

Mely eszközszolgáltatók (Virtual WAN-partnerek) támogatottak?

Mostanra már számos partner támogatja a teljesen automatizált Virtual WAN-t. További információ: Virtual WAN-partnerek.

Melyek a Virtual WAN-partnerek automatizálásának lépései?

A partnerek automatizálásának lépéseiért tekintse át a Virtual WAN-partnerek automatizálásával foglalkozó részt.

Kötelező egy adott partner eszközét használnom?

No. Bármely olyan VPN-kompatibilis eszközt használhat, amely megfelel az Azure IKEv2/IKEv1 IPsec-támogatásra vonatkozó követelményeinek. A Virtual WAN olyan CPE-partnermegoldásokkal is rendelkezik, amelyek automatizálják az Azure Virtual WAN-hoz való kapcsolódást, így egyszerűbben állíthatók be az IPsec VPN-kapcsolatok nagy méretekben.

Hogyan csatlakozhatnak a Virtual WAN-partnerek automatikusan az Azure Virtual WAN-hoz?

A szoftveralapú csatlakozási megoldások jellemzően vezérlővel vagy eszközkiépítési központtal kezelik a kompatibilis eszközöket. A vezérlők Azure API-kat is használhatnak az Azure Virtual WAN-hoz való automatikus csatlakozáshoz. Az automatizálás magában foglalja az áginformációk feltöltését, az Azure-konfiguráció letöltését, az IPsec-alagutak Azure Virtual Hubsba való beállítását, valamint az ágeszköz és az Azure Virtual WAN közötti kapcsolat automatikus beállítását. Ha több száz ága van, a Virtual WAN CPE-partnerek használatával való csatlakozás egyszerű, mivel az előkészítési folyamat szükségtelenül igényli a nagyméretű IPsec-kapcsolatok beállítását, konfigurálását és kezelését. További információért tekintse meg a Virtual WAN-partnerek automatizálásával foglalkozó részt.

Mi történik, ha az általam használt eszköz nem szerepel a Virtual WAN partnerlistájában? Továbbra is használhatom az Azure Virtual WAN VPN-hez való csatlakozáshoz?

Igen, ha az eszköz támogatja az IPsec IKEv1 vagy az IKEv2 protokollt. A Virtual WAN-partnerek automatizálják az eszköz és az Azure VPN végpontja közötti kapcsolatot. Ez olyan lépések automatizálását jelenti, mint a "fiókadatok feltöltése", az "IPsec és a konfiguráció" és a "kapcsolat". Mivel az eszköz nem egy Virtual WAN-partneri ökoszisztémából származik, az IPsec-kapcsolat beállításához manuálisan kell elvégeznie az Azure-konfigurációt, és frissítenie kell az eszközt.

Hogyan kerülnek bevezetésre az indítási partnerlistában nem szereplő új partnerek?

Minden virtuális WAN API OpenAPI. A virtual WAN-partnerek automatizálásának dokumentációját a műszaki megvalósíthatóság felméréséhez használhatja. Ideális esetben a partner olyan eszközzel rendelkezik, amely támogatja az IKEv1 vagy az IKEv2 IPsec-kapcsolatot. Miután a vállalat a korábban megosztott automatizálási irányelvek alapján befejezte a CPE-eszköz automatizálási munkáját, kapcsolatba azurevirtualwan@microsoft.com léphet, hogy itt felsorolásra kerüljön Partnerek révén történő kapcsolódás. Ha Ön olyan ügyfél, aki azt szeretné, hogy egy bizonyos vállalati megoldás szerepeljen a Virtual WAN-partnerlistában, kérje meg a vállalatot, hogy küldjön egy e-mailt a Virtual WAN-nak azurevirtualwan@microsoft.com.

Hogyan támogatja a Virtual WAN az SD-WAN-eszközöket?

A Virtual WAN-partnerek automatizálják az IPsec-kapcsolatot az Azure VPN-végpontok felé. Ha a Virtual WAN-partner egy SD-WAN szolgáltató, akkor azt feltételezik, hogy a SD-WAN vezérlő kezeli az Azure VPN-végpontokhoz való automatizálást és IPsec-kapcsolatot. Ha az SD-WAN-eszköznek saját végpontra van szüksége az Azure VPN helyett bármilyen védett SD-WAN-funkcióhoz, üzembe helyezheti az SD-WAN végpontot egy Azure-beli virtuális hálózaton, és együtt létezhet az Azure Virtual WAN-nal.

A Virtual WAN támogatja a BGP-társviszony-létesítést, és NVA-kat is üzembe helyezhet egy virtuális WAN-központban.

Hány VPN-eszköz csatlakozhat egyetlen központhoz?

Virtuális központonként legfeljebb 1000 kapcsolat támogatott. Minden kapcsolat négy hivatkozásból áll, és mindegyik kapcsolat két alagutat támogat, amelyek aktív-aktív konfigurációban vannak. Az alagutak egy Azure-beli virtuális központ VPN-átjárójában fejeződnek be. A hivatkozások az ág/VPN-eszköz fizikai internetszolgáltatói hivatkozását jelölik.

Mi az a fiókkapcsolat az Azure Virtual WAN-hoz?

Egy ágból vagy VPN-eszközről az Azure Virtual WAN-ba való kapcsolat olyan VPN-kapcsolat, amely virtuális központban virtuálisan csatlakoztatja a VPN-helyet és az Azure VPN-átjárót.

Mi történik, ha a helyszíni VPN-eszköznek csak 1 alagútja van egy Azure Virtual WAN VPN-átjáróhoz?

Az Azure Virtual WAN-kapcsolat 2 alagútból áll. A Virtual WAN VPN-átjáró egy virtuális központban, aktív-aktív módban van üzembe helyezve, ami azt jelenti, hogy a helyszíni eszközöktől származó alagutak különálló példányokon végződnek. Ez a javaslat az összes felhasználó számára. Ha azonban a felhasználó úgy dönt, hogy csak egy alagúttal rendelkezik az egyik Virtual WAN VPN-átjárópéldányhoz, ha bármilyen okból (karbantartás, javítások stb.) az átjárópéldány offline állapotba kerül, az alagút átkerül a másodlagos aktív példányra, és a felhasználó újracsatlakozhat. A BGP-munkamenetek nem lépnek át a példányok között.

Mi történik az átjáró alaphelyzetbe állítása során egy Virtual WAN VPN-átjáróban?

Az Átjáró alaphelyzetbe állítása gombot akkor kell használni, ha a helyszíni eszközök a vártnak megfelelően működnek, de az Azure-ban a helyek közötti VPN-kapcsolat megszakadt állapotban van. A virtuális WAN VPN-átjárók mindig aktív-aktív állapotban vannak üzembe helyezve a magas rendelkezésre állás érdekében. Ez azt jelenti, hogy egy VPN-átjáróban mindig több példány van üzembe helyezve. Az Átjáró alaphelyzetbe állítása gomb használata esetén szekvenciális módon újraindítja a VPN-átjáró példányait, hogy a kapcsolatok ne szakadjon meg. A kapcsolatok egyik példányról a másikra való áthelyezésekor rövid rés lesz, de ennek a résnek egy percnél kevesebbnek kell lennie. Emellett az átjárók alaphelyzetbe állítása nem módosítja a nyilvános IP-címeket.

Ez a forgatókönyv csak az S2S-kapcsolatokra vonatkozik.

Csatlakozhat a helyszíni VPN-eszköz több központhoz?

Yes. A forgalom a kezdéskor a helyszíni eszközről a legközelebbi Microsoft hálózati peremhálózatra, majd a virtuális központra kerül.

Elérhetővé válnak új Resource Manager-erőforrások a Virtual WAN-hoz?

Igen, a Virtual WAN új Resource Manager-erőforrásokkal rendelkezik. További információ: Áttekintés.

Üzembe helyezhetem és használhatom a kedvenc hálózati virtuális berendezésemet (NVA virtuális hálózatban) az Azure Virtual WAN használatával?

Igen, csatlakoztathatja kedvenc hálózati virtuális berendezése (NVA) virtuális hálózatát az Azure Virtual WAN-hoz.

Létrehozhatok hálózati virtuális berendezést a virtuális központban?

A hálózati virtuális berendezés (NVA) üzembe helyezhető egy virtuális központban. A lépésekkel kapcsolatosan lásd: Az NVÁ-król egy virtuális WAN-központban.

Csatlakoztathatok egy virtuális hálózatot egy másik bérlőben lévő virtuális központhoz?

Yes. Kövesse a bérlők közötti virtuális hálózatok Virtuális WAN-központhoz való csatlakoztatása című témakörben található útmutatást.

A küllős virtuális hálózatok rendelkezhetnek virtuális hálózati átjáróval?

No. A sugárirányú virtuális hálózatnak nem lehet virtuális hálózati átjárója, ha csatlakozik a virtuális központhoz.

Lehet-e egy küllős VNet-nek Azure Route Servere?

No. A küllős virtuális hálózat nem rendelkezhet útvonalkiszolgálóval, ha a virtuális WAN-központhoz van csatlakoztatva.

Támogatja a BGP-t a VPN-kapcsolat?

Igen, a BGP támogatott. VPN-hely létrehozásakor megadhatja benne a BGP-paramétereket. Ez azt jelenti, hogy az Azure-ban az adott helyhez létrehozott kapcsolatok engedélyezve vannak a BGP-ben.

Milyen licenc- vagy díjszabási információ érhető el a Virtual WAN-ról?

Yes. Lásd a Díjszabás oldalt.

Lehetséges Azure Virtual WAN létrehozása Resource Manager-sablon használatával?

Egy virtual WAN egyszerű konfigurációja egy központtal és egy vpnsite-tal egy rövid útmutatósablon használatával hozható létre. A Virtual WAN elsősorban REST- vagy portálalapú szolgáltatás.

Kommunikálhatnak egymással a virtuális központhoz csatlakoztatott küllős virtuális hálózatok (V2V Transit)?

Yes. A Standard Virtual WAN támogatja a virtuális hálózatok közötti tranzitív kapcsolatot azon a Virtual WAN-központon keresztül, amelyhez a virtuális hálózatok csatlakoznak. A Virtual WAN terminológiájában ezeket az útvonalakat "helyi Virtual WAN VNet-átvitelnek" nevezzük a virtual WAN-központhoz egyetlen régión belül csatlakoztatott virtuális hálózatok esetében. A "globális virtuális WAN VNet átjárás" olyan virtuális hálózatok számára készült, amelyek több virtuális WAN-központon keresztül csatlakoznak két vagy több régióban.

Bizonyos esetekben a spoke VNets a helyi vagy globális Virtual WAN VNet átjárhatósága mellett virtuális hálózati társviszony-létesítéssel is közvetlenül társviszonyba hozhatók egymással. Ebben az esetben a virtuális hálózatok közötti társviszony-létesítés elsőbbséget élvez a Virtual WAN hubon keresztüli tranzitív kapcsolattal szemben.

A Virtual WAN-ban engedélyezett az ágak közötti kapcsolat?

Igen, az ágak közötti kapcsolat elérhető a Virtual WAN-ban. Az ág fogalmilag alkalmazható VPN-helyekre, ExpressRoute-kapcsolatcsoportokra vagy pont–hely/felhasználó VPN-felhasználókra. Az ág-ág engedélyezése alapértelmezés szerint engedélyezve van, és a WAN konfigurációs beállításai között található. Ez lehetővé teszi, hogy a VPN-ágak/felhasználók más VPN-ágakhoz csatlakozzanak, és a VPN és az ExpressRoute-felhasználók között is engedélyezve legyen az átvitel.

Áthalad a telephelyek közötti forgalom az Azure Virtual WAN-en?

Yes. Az ágak közötti forgalom az Azure Virtual WAN-on keresztül halad át.

A Virtual WAN-nak szüksége van az ExpressRoute-ra az egyes helyekről?

No. A Virtual WAN nem igényel ExpressRoute-t az egyes helyekről. Előfordulhat, hogy a webhelyek expressRoute-kapcsolatcsoporttal csatlakoznak egy szolgáltatói hálózathoz. Az ExpressRoute-tal egy virtuális központhoz és az IPsec VPN-hez ugyanahhoz a központhoz csatlakoztatott webhelyek esetében a virtuális központ tranzitkapcsolatot biztosít a VPN és az ExpressRoute-felhasználó között.

Van hálózati átviteli sebesség vagy kapcsolati korlát az Azure Virtual WAN használatakor?

A hálózati átviteli sebességet a virtuális WAN-központban szolgáltatásonként értékelik. Az egyes központokban a VPN-aggregátum átviteli sebessége legfeljebb 20 Gb/s, az ExpressRoute összesített átviteli sebessége legfeljebb 20 Gb/s, a felhasználói VPN/pont–hely VPN összesített átviteli sebessége pedig legfeljebb 200 Gbps lehet. A virtuális központ útválasztója legfeljebb 50 Gb/s-os VNet-forgalmat támogat, és összesen 2000 virtuálisgép-számítási feladatot feltételez az egyetlen virtuális központhoz csatlakoztatott összes virtuális hálózaton.

Ha úgy szeretné biztonságossá tenni az előzetes kapacitást, hogy nem kell megvárnia, amíg a virtuális központ felskálázódik, ha több átviteli sebességre van szükség, beállíthatja a minimális kapacitást, vagy szükség szerint módosíthatja azt. Lásd: A virtuális központ beállításai – hubkapacitás. A költségekkel kapcsolatos információkért tekintse meg az Útválasztási infrastruktúra egységköltségét az Azure Virtual WAN díjszabás oldalán.

Amikor a VPN-webhelyek csatlakoznak egy központhoz, azt kapcsolatok segítségével teszik. A Virtual WAN legfeljebb 1000 kapcsolatot vagy 2000 IPsec-alagutat támogat egy virtuális központonként. Amikor a távoli felhasználók csatlakoznak a virtuális központhoz, a P2S VPN-átjáróhoz csatlakoznak, amely legfeljebb 100 000 felhasználót támogat a virtuális központban a P2S VPN-átjáróhoz választott méretezési egységtől (sávszélességtől függően).

Használhatom a NAT-T-t a VPN-kapcsolataimon?

Igen, a NAT átlépés (NAT-T) támogatott. A Virtual WAN VPN-átjáró NEM hajt végre NAT-szerű funkciókat az IPsec-alagutakba/onnan érkező belső csomagokon. Biztosítsa, hogy ebben a konfigurációban a helyszíni eszköz kezdeményezi az IPsec-alagutat.

Hogyan konfigurálhatok egy méretezési egységet egy adott beállításra, például 20 Gb/s-ra?

Nyissa meg a VPN-átjárót a portálon található központon belül, majd válassza ki a méretezési egységet a megfelelő beállításra való módosításhoz.

Engedélyezi a Virtual WAN, hogy a helyszíni eszköz egyszerre több ISP-t használjon, vagy mindig egyetlen VPN-alagutat használ?

A helyszíni eszközmegoldások forgalmi szabályzatokat alkalmazhatnak, hogy több alagúton keresztül irányítsák a forgalmat az Azure Virtual WAN Hubba (a virtuális központban található VPN-átjáróba).

Mi a globális tranzitarchitektúra?

További információ: Globális átviteli hálózati architektúra és Virtual WAN.

Hogyan történik a forgalom átirányítása az Azure gerinchálózatára?

A forgalom a következő mintát követi: ágeszköz -ISP-Microsoft network edge-Microsoft> DC (hub VNet)->Microsoft network edge-ISP-branch>> device>>

Ebben a modellben mire van szükség az egyes helyek esetében? Csupán internetkapcsolatra?

Yes. IPsec-t támogató internetkapcsolat és fizikai eszköz, lehetőleg integrált Virtual WAN-partnereinktől. Igény szerint manuálisan is kezelheti a konfigurációt és az Azure-hoz való kapcsolódást az előnyben részesített eszközről.

Hogyan engedélyezi az alapértelmezett útvonalat (0.0.0.0/0) egy kapcsolathoz (VPN, ExpressRoute vagy virtuális hálózat)?

A virtuális központ képes propagálja a tanult alapértelmezett útvonalat egy virtuális hálózatra/helyek közötti VPN-/ExpressRoute-kapcsolatra, ha a jelölő engedélyezve van a kapcsolaton. Ez a jelző akkor jelenik meg, ha a felhasználó módosít egy virtuális hálózati kapcsolatot, egy VPN-kapcsolatot vagy egy ExpressRoute-kapcsolatot. Ez a jelző alapértelmezés szerint le van tiltva, ha egy hely vagy egy ExpressRoute-kapcsolatcsoport csatlakozik egy központhoz. Alapértelmezés szerint engedélyezve van, ha virtuális hálózati kapcsolatot adnak hozzá egy virtuális hálózat virtuális központhoz való csatlakoztatásához.

Az alapértelmezett útvonal nem a Virtual WAN hubról származik. Az alapértelmezett útvonal akkor lesz propagálva, ha a virtual WAN-központ már megtanulta azt egy tűzfal központi telepítése miatt, vagy ha egy másik csatlakoztatott hely kényszerített bújtatást engedélyezett.

Az alapértelmezett útvonal nem terjed a hubok között (központközi).

Létrehozhat több virtuális WAN-központot ugyanabban a régióban?

Yes. Az ügyfelek mostantól több központot is létrehozhatnak ugyanabban a régióban ugyanahhoz az Azure Virtual WAN-hoz.

Hogyan választja ki a virtuális WAN-beli virtuális központ egy útvonal legjobb útvonalát több központból?

További információért lásd a Virtual Hub routing preference oldalt.

Engedélyezi a Virtual WAN hub az ExpressRoute-kapcsolatcsoportok közötti kapcsolatot?

Az ER-to-ER közötti kommunikáció a Global reach segítségével érhető el. A virtuális központ átjárói dc- vagy Azure-régiókban vannak üzembe helyezve. Amikor két ExpressRoute áramkör globális eléréssel kapcsolódik, nincs szükség arra, hogy a forgalom egészen a peremhálózati útválasztóktól a virtuális központi adatközpontig jusson el.

A Routing Intent a privát forgalomirányítási szabályzatokkal együtt is használható, hogy lehetővé tegye az ExpressRoute tranzitkapcsolatot egy biztonsági eszközön keresztül, amely a virtuális központban van telepítve.

További információkért lásd: Virtual WAN Global Reach.

Létezik súlyozás az Azure Virtual WAN ExpressRoute-kapcsolatcsoportokban vagy VPN-kapcsolatokban?

Ha több ExpressRoute-kapcsolatcsoport csatlakozik egy virtuális központhoz, a kapcsolat útválasztási súlya lehetővé teszi, hogy a virtuális központban az ExpressRoute előnyben részesítse az egyik kapcsolatcsoportot a másiknál. A VPN-kapcsolat súlyának beállítására nincs mechanizmus. Az Azure mindig az ExpressRoute-kapcsolatot részesíti előnyben egy VPN-kapcsolattal szemben egyetlen központban.

A Virtual WAN inkább az ExpressRoute-t részesíti előnyben a VPN-hez az Azure-ból kimenő forgalomhoz

Yes. A Virtual WAN az ExpressRoute-t részesíti előnyben VPN-ről az Azure-ból kimenő forgalomhoz. Az alapértelmezett beállítás módosításához azonban konfigurálhatja a virtuális központ útválasztási beállításait. A lépésekért tekintse meg a virtuális központ útválasztási beállításának konfigurálását.

Ha egy Virtuális WAN-központhoz ExpressRoute-kapcsolatcsoport és egy VPN-hely csatlakozik, mi okozhatja, hogy a VPN-kapcsolati útvonal előnyben részesüljön az ExpressRoute-tal szemben?

Amikor egy ExpressRoute-kapcsolatcsoport csatlakozik egy virtuális központhoz, a Microsoft Edge-útválasztók az első csomópontok a helyszíni és az Azure közötti kommunikációhoz. Ezek a peremhálózati útválasztók kommunikálnak a Virtual WAN ExpressRoute-átjárókkal, amelyek viszont a virtuális központ útválasztójától tanulják meg az útvonalakat, amelyek a Virtual WAN-átjárók közötti összes útvonalat vezérli. A Microsoft Edge-útválasztók a helyszínitől tanult útvonalakkal szemben nagyobb preferencia mellett dolgozzák fel a virtuális központ ExpressRoute-útvonalait.

Bármilyen okból, ha a VPN-kapcsolat lesz a virtuális központ elsődleges adathordozója az útvonalak tanulásához (például az ExpressRoute és a VPN közötti feladatátvételi forgatókönyvek), kivéve, ha a VPN-hely hosszabb AS elérési úttal rendelkezik, a virtuális központ továbbra is megosztja a VPN által tanult útvonalakat az ExpressRoute-átjáróval. Ez azt eredményezi, hogy a Microsoft Edge-útválasztók a VPN-útvonalakat részesítik előnyben a helyszíni útvonalakon.

Támogatja az ExpressRoute az egyenlő költségű többútvonalos (ECMP) útválasztást a Virtual WAN-ban?

Ha egy vagy több ExpressRoute-kapcsolat csatlakozik egy Virtuális WAN elosztóközponthoz, az ECMP lehetővé teszi a küllős virtuális hálózatok helyszíni forgalmának ExpressRoute-on keresztüli elosztását 2 ExpressRoute-kapcsolat között (ami legfeljebb 4 ExpressRoute-kapcsolatnak felelhet meg), ugyanazon helyszíni útvonalakat hirdetve. Az ECMP jelenleg nincs alapértelmezés szerint engedélyezve a Virtual WAN hubok esetében. Az ECMP környezethez való engedélyezéséhez létrehozhat egy útvonaltérképet a virtuális központhoz. Útvonaltérkép létrehozásakor a rendszer automatikusan frissíti a virtuális központot az ECMP-t támogató legújabb szoftververzióra, függetlenül attól, hogy ezt az útvonaltérképet bármilyen kapcsolatra alkalmazza-e a rendszer. Ennek eredményeképpen csak az útvonaltérképek konfigurálásához kövesse az 1–7. lépést. Ha nem tervezi használni az útvonaltérképet, a 7. lépés befejezése után törölheti az útvonaltérképet, mivel az útvonaltérképet tartalmazó központok további költségekkel járnak. Javasoljuk, hogy hozzon létre egy útvonaltérképet a tesztkörnyezetben, és ellenőrizze az útválasztást és a kapcsolatot, mielőtt létrehoz egy útvonaltérképet az éles környezetben.

Ha két hub (1. és 2. központ) csatlakozik, és egy ExpressRoute-kapcsolatcsoport csatlakozik mindkét központhoz csokornyakkendőként, mi az 1. központhoz csatlakoztatott virtuális hálózat elérési útja a 2. központban csatlakoztatott virtuális hálózat eléréséhez?

Az aktuális működés az, hogy az ExpressRoute kapcsolatkör útvonalát részesíti előnyben a központok közötti út helyett, amikor a virtuális hálózatok közötti kapcsolódásról van szó. Ezt azonban nem javasoljuk a Virtual WAN-beállításokban. A probléma megoldásához tegye a következő két dolog egyikét:

  • Konfiguráljon több ExpressRoute-kapcsolatcsoportot (különböző szolgáltatókat) egy központhoz való csatlakozáshoz, és használja a Virtual WAN által biztosított központ-központ kapcsolatot a régiók közötti forgalmi folyamatokhoz.

  • Konfigurálja az AS-Path elemet a virtuális hub útválasztási preferenciájaként. Ez biztosítja, hogy a két központ közötti forgalom minden hubon áthaladjon a Virtuális központ útválasztón, és az ExpressRoute-útvonal helyett a hub–központ útvonalat használja (amely a Microsoft Edge-útválasztókon áthalad). További információ: Virtuális központ útválasztási beállításának konfigurálása.

Ha egy ExpressRoute-kapcsolatcsoport csokornyakkendőként csatlakozik egy Virtuális WAN-központhoz és egy különálló virtuális hálózathoz, mi az elérési út ahhoz, hogy az önálló virtuális hálózat elérje a Virtual WAN hubot?

Az új üzemelő példányok esetében ez a kapcsolat alapértelmezés szerint le van tiltva. A kapcsolat engedélyezéséhez engedélyezheti ezeket az ExpressRoute-átjáró kapcsolókat a Portál "Virtuális központ szerkesztése" paneljén és a "Virtuális hálózati átjáró" panelen. Javasoljuk azonban, hogy ezeket a kapcsolókat tiltsa le, és ehelyett hozzon létre egy virtuális hálózati kapcsolatot az önálló virtuális hálózatok virtuális WAN-központhoz való közvetlen csatlakoztatásához. Ezt követően a virtuális hálózatok közötti forgalom a Virtual WAN hub útválasztón keresztül halad, amely jobb teljesítményt nyújt az ExpressRoute útvonalhoz képest. Az ExpressRoute elérési útja a következőket tartalmazza:

  • Az ExpressRoute-átjáró, amely alacsonyabb sávszélesség-korláttal rendelkezik, mint a hálózati központi útválasztó
  • és a Microsoft Enterprise Edge-útválasztók/MSEE, ami egy extra ugrás az adatútvonalban.

Az alábbi ábrán mindkét kapcsolót engedélyezni kell a 4. önálló virtuális hálózat és a 2. központhoz közvetlenül csatlakozó virtuális hálózatok (2. és 3. virtuális hálózat) közötti kapcsolat engedélyezéséhez: A virtuális hálózati átjáró távoli Virtuális WAN-hálózataiból érkező forgalom engedélyezése, valamint a virtuális központ ExpressRoute-átjárójának nem virtuális WAN-hálózatokról érkező forgalom engedélyezése. Ha egy Azure Route Server önálló VNet 4-ben van üzembe helyezve, és az útvonalkiszolgálón engedélyezve van az ágak közötti kapcsolat, akkor a kapcsolat blokkolva lesz az 1. VNet és a 4. önálló VNet között.

A kapcsoló engedélyezése vagy letiltása csak a következő forgalomra lesz hatással: a Virtual WAN hub és a különálló virtuális hálózatok közötti forgalom az ExpressRoute-kapcsolatcsoporton keresztül. A kapcsoló engedélyezése vagy letiltása nem jár állásidővel minden más forgalmi folyamat esetében (például a 2. virtuális hálózat küllős VNet-hez való helyszíni kapcsolata nem lesz hatással, és a VNet 2-től a VNet 3-ig irányuló kapcsolat sem lesz érintett).

Ábra egy önálló virtuális hálózatról, amely expressRoute-kapcsolatcsoporton keresztül csatlakozik egy virtuális központhoz.

Az ExpressRoute-kapcsolat frissítésekor ez hatással lesz a többi ExpressRoute-kapcsolatom kapcsolatára?

Amikor egy ExpressRoute-kapcsolaton végez létrehozási, frissítési vagy törlési műveletet, a többi ExpressRoute-kapcsolat "frissítési" állapotban lesz a Portálon. Az ExpressRoute-kapcsolatokon keresztüli kapcsolatok azonban nem lesznek hatással.

Miért nem működik a kapcsolat, ha 0 ASN-vel hirdetek útvonalakat az AS-Pathban?

A Virtual WAN hub 0 ASN-sel elveti az útvonalakat az AS-pathban. Annak érdekében, hogy ezek az útvonalak sikeresen meghirdethetők legyenek az Azure-ban, az AS-path nem tartalmazhat 0-t.

Létre lehet hozni hubokat a Virtual WAN különböző erőforráscsoportjaiban?

Yes. Ez a lehetőség jelenleg csak PowerShell-lel érhető el. A Virtual WAN portál megköveteli, hogy a központok ugyanabban az erőforráscsoportban legyenek, mint maga a Virtual WAN-erőforrás.

A Virtual WAN hub címtere nem módosítható a központ létrehozása után. Az alábbi információk segítségével válassza ki az üzembe helyezéshez megfelelő központi címméretet:

  • A jövőbeli méretezhetőség és az architekturális igények kielégítése érdekében, míg a Virtual WAN-központ minimális címtere /24, ajánlott /23 címteret vagy nagyobbat megadni a központ létrehozásakor.
  • Ha Azure-tűzfalat használ a Virtual WAN-on belül, legalább 22 fős központi címtér szükséges annak biztosításához, hogy az Azure Firewall elegendő IP-címet foglaljon le a maximális átviteli sebességre való skálázáshoz.
  • Ha hálózati virtuális berendezéseket használ a Virtual WAN hubon, a Virtual WAN hub mérete határozza meg az NVA-k számára lefoglalt használható IP-címek számát. Tekintse meg az NVA dokumentációját a központi címtér és az NVA-k számára kiosztható IP-címek közötti leképezésről.

Támogatott az IPv6 a Virtual WAN-ban?

Az IPv6 nem támogatott a Virtual WAN hubban és átjáróiban. Ha egy küllős virtuális hálózatot IPv6-címtartománysal csatlakoztat a Virtual WAN-központhoz, akkor csak az ezzel a küllős virtuális hálózattal létesített IPv4-kapcsolat fog működni. A küllős virtuális hálózattal való IPv6-kapcsolat nem támogatott.

Ha helyszíni IPv6-előtagokat hirdet, ez megszakítja az Azure-erőforrások IPv4-kapcsolatát.

A helyszínre mutató felhasználói VPN-forgatókönyv esetében, amely az Azure Firewallon keresztüli internetes kitörést használja, valószínűleg ki kell kapcsolnia az IPv6-kapcsolatot az ügyfél eszközén, hogy a forgalom a virtuális WAN-központba irányuljon. Ennek az az oka, hogy a modern eszközök alapértelmezés szerint IPv6-címeket használnak.

A 05-01-2022 (2022. május 1.) minimális verzió szükséges.

Vannak virtuális WAN-korlátozások?

Tekintse meg a Virtual WAN-korlátok szakaszt az Előfizetés és szolgáltatáskorlátok lapon.

Milyen különbségek vannak a Virtual WAN-típusok (Alapszintű és Standard) között?

Lásd: Alapszintű és standard virtuális WAN-k. A díjszabásért tekintse meg a Díjszabás lapot.

A Virtual WAN tárolja az ügyféladatokat?

No. A Virtual WAN nem tárol ügyféladatokat.

Vannak olyan felügyelt szolgáltatók, amelyek szolgáltatásként kezelhetik a Virtual WAN-t a felhasználók számára?

Yes. Az Azure Marketplace-en keresztül engedélyezett felügyelt szolgáltatói (MSP-) megoldások listájáért tekintse meg az Azure Marketplace azure-beli hálózati MSP-partnerek ajánlatait.

Miben különbözik a Virtual WAN Hub útválasztása az Azure Route Servertől egy virtuális hálózatban?

Az Azure Virtual WAN Hub és az Azure Route Server egyaránt biztosít határátjáró protokoll (BGP) társviszony-létesítési képességeket, amelyeket az NVA -k (hálózati virtuális berendezés) használhatnak az IP-címek meghirdetéséhez az NVA-ból a felhasználó Azure-beli virtuális hálózatai felé. Az üzembe helyezési lehetőségek abban különböznek, hogy az Azure Route Server-t általában egy önállóan kezelt ügyfélközponti virtuális hálózat (VNet) helyezi üzembe, míg az Azure Virtual WAN egy érintésmentes, teljesen összekapcsolt hubszolgáltatást biztosít, amelyhez az ügyfelek különböző küllő végpontjaikkal csatlakoznak (Azure VNet, helyszíni fióktelepek helyek közötti VPN vagy SDWAN segítségével, távoli felhasználók pont–hely/Távoli felhasználó VPN-nel, valamint privát kapcsolatokkal az ExpressRoute-tal), és kihasználhatják a küllők virtuális hálózatában telepített NVA-k BGP-társviszony létrehozását, valamint más vWAN képességeket, mint például a virtuális hálózatok közötti tranzitkapcsolat, a VPN és az ExpressRoute közötti tranzitkapcsolat, az egyedi/fejlett útválasztás, az egyedi útvonal társítása és propagálása, az útválasztás szándéka/politikája régiók közötti biztonság érdekében megkönnyítve, a Secure Hub/Azure tűzfal stb. A Virtual WAN BGP-társviszonnyal kapcsolatos további információkért tekintse meg a "BGP társviszony létesítése egy virtuális hubbal" című ismertető cikket.

Ha külső biztonsági szolgáltatót (Zscaler, iBoss vagy Checkpoint) használok az internetes forgalom védelméhez, miért nem látom a külső biztonsági szolgáltatóhoz társított VPN-webhelyet az Azure Portalon?

Amikor biztonsági partnerszolgáltatót helyez üzembe a felhasználók internet-hozzáférésének védelme érdekében, a külső biztonsági szolgáltató létrehoz egy VPN-webhelyet az Ön nevében. Mivel a külső biztonsági szolgáltatót a szolgáltató automatikusan hozza létre, és nem felhasználó által létrehozott VPN-webhely, ez a VPN-webhely nem jelenik meg az Azure Portalon.

A külső biztonsági szolgáltatók rendelkezésre álló lehetőségeiről és beállításáról további információt a biztonsági partnerszolgáltató üzembe helyezése című témakörben talál.

Megmaradnak a helyszíni BGP-közösségek a Virtual WAN-ban?

Igen, a helyszíni BGP-közösségek megmaradnak a Virtual WAN-ban.

Megmaradnak-e a BGP társak által létrehozott BGP-közösségek egy kapcsolt virtuális hálózaton belül a Virtual WAN-ban?

Igen, a BGP-társ által létrehozott BGP-közösségek megmaradnak a Virtual WAN-ban. A közösségek megmaradnak ugyanazon a központban és a csomópontok közötti kapcsolatokban. Ez az útválasztási szándékszabályzatokat használó Virtual WAN-forgatókönyvekre is vonatkozik.

Milyen ASN-számokat támogat a BGP-t futtató, távolról csatlakoztatott helyszíni hálózatok?

Saját nyilvános ASN-eket vagy privát ASN-eket használhat a helyszíni hálózatokhoz. Az Azure vagy az IANA által fenntartott tartományok nem használhatók:

  • Az Azure által fenntartott ASN-ek:
    • Nyilvános ASN-ek: 8074, 8075, 12076
    • Privát ASN-ek: 65515, 65517, 65518, 65519, 65520
    • AZ IANA által fenntartott ASN-k: 23456, 64496-64511, 65535-65551

Van mód az ASN-k módosítására a Virtual WAN-ban?

No. A Virtual WAN nem támogatja a Virtual Hubs vagy átjárók ASN-módosításait.

Mi az ExpressRoute-átjáró termékváltozatának becsült teljesítménye a Virtual WAN-ban?

Skálázási egység Kapcsolatok másodpercenként Megabit/s Csomagok másodpercenként Folyamatok összesen
1 14,000 2,000 200,000 200,000
2 28,000 4,000 400,000 400,000
3 42,000 6,000 600,000 600,000
4 56,000 8,000 800,000 800,000
5 70,000 10,000 1,000,000 1,000,000
6 84,000 12,000 1,200,000 1,200,000
7 98,000 14,000 1,400,000 1,400,000
8 112,000 16,000 1,600,000 1,600,000
9 126,000 18,000 1,800,000 1,800,000
10 140,000 20,000 2,000,000 2,000,000

Fontos figyelembe venni a következő szempontokat:

  • A karbantartási műveletek során a 2–10. skálázási egységek fenntartják az összesített átviteli sebességet. Az 1. skálázási egység azonban az ilyen műveletek során enyhe eltérést tapasztalhat az átviteli sebességben.
  • Az üzembe helyezett méretezési egységek számától függetlenül, ha egy TCP-folyamat meghaladja az 1,5 Gb/s-ot, a forgalom teljesítménye csökkenhet.

Ha egy ExpressRoute helyi kapcsolatcsoportot csatlakoztatok egy Virtuális WAN-központhoz, akkor csak a helyi kapcsolatcsoporttal azonos metróállomáson lévő régiókat érhetem el?

A helyi kapcsolatcsoportok csak a megfelelő Azure-régióban lévő ExpressRoute-átjárókhoz csatlakoztathatók. Más régiókban azonban nincs korlátozás a küllős virtuális hálózatok felé történő átirányításra.

Miért van szükség a virtuális központ útválasztójának nyilvános IP-címére nyitott portokkal?

Ezek a nyilvános végpontok szükségesek ahhoz, hogy az Azure mögöttes SDN- és felügyeleti platformja kommunikáljon a virtuális központ útválasztójával. Mivel a virtuális központ útválasztója az ügyfél magánhálózatának része, az Azure mögöttes platformja a megfelelőségi követelmények miatt nem tudja közvetlenül elérni és felügyelni a központi útválasztót a privát végpontokon keresztül. A központi útválasztó nyilvános végpontjaihoz való csatlakozás hitelesítése tanúsítványokon keresztül történik, és az Azure elvégzi ezeknek a nyilvános végpontoknak a rendszeres biztonsági auditjait. Ennek eredményeképpen ezek nem jelentik a virtuális központ biztonsági kitettségét.

Van útvonalkorlát az Azure P2S VPN-átjáróhoz csatlakozó OpenVPN-ügyfelek számára?

Az OpenVPN-ügyfelek útvonalkorlátja 1000.

Hogyan történik a Virtual WAN SLA kiszámítása?

A Virtual WAN egy szolgáltatásként nyújtott hálózatkezelési platform, amely 99,95%-os SLA-val rendelkezik. A Virtual WAN azonban számos különböző összetevőt kombinál, például az Azure Firewallt, a helyek közötti VPN-t, az ExpressRoute-t, a pont–hely VPN-t és a Virtual WAN Hub/Integrált hálózati virtuális berendezéseket.

Az egyes összetevők SLA-ja egyenként lesz kiszámítva. Ha például az ExpressRoute 10 perces állásidővel rendelkezik, az ExpressRoute rendelkezésre állási ideje a következőképpen lesz kiszámítva: (Maximális rendelkezésre állási perc – állásidő) / Maximális rendelkezésre állási perc * 100.

Meg tudja változtatni a virtuális hálózat címterét a központhoz csatlakoztatott küllős virtuális hálózatban?

Igen, ez automatikusan elvégezhető a peering kapcsolaton, frissítésre vagy alaphelyzetbe állításra nincs szükség. Vegye figyelembe a következőket:

  • A "Peering" panelban nem kell kattintania a "Szinkronizálás" gombra. A virtuális hálózat címterének módosítása után a virtuális hálózatok közötti társviszony-létesítés automatikusan szinkronizálódik a virtuális központ VNet-jével.
  • Győződjön meg arról, hogy a frissített címtér nem fedi át a virtuális WAN meglévő küllős virtuális hálózatainak címterét.

A virtuális hálózat címterének módosításáról a virtuális hálózat létrehozása, módosítása vagy törlése című témakörben talál további információt.

Mi a küllős virtuális hálózati címek maximális száma az útválasztási szándékkal konfigurált központok esetében?

Az egyetlen virtuális WAN-központhoz közvetlenül csatlakozó összes virtuális hálózat címtereinek maximális száma 600. Ezt a korlátot egyenként alkalmazzák a Virtual WAN-telepítés minden Virtual WAN-központjára. A virtuális hálózati címterek, amelyek a távoli (más virtuális WAN-központok ugyanabban a virtuális WAN-ban) központokhoz kapcsolódnak, nem számítanak bele ebbe a korlátba.

A virtuális WAN-központhoz csatlakoztatott virtuális hálózatok címtereinek számának meghatározásához szükséges korlátról és mintaszkriptekről további információt az útválasztási szándék virtuális hálózati címterének korlátait ismertető cikkben talál.

Használhatom az Azure Bastiont a Virtual WAN használatával?

Igen, de vannak korlátozások. További részletekért tekintse meg az Azure Bastion gyakori kérdéseit .

Virtual WAN ügyfél által vezérelt átjárókarbantartás

Mely szolgáltatások szerepelnek a hálózati átjárók karbantartási konfigurációs hatókörében?

A Virtual WAN esetében konfigurálhat karbantartási időszakokat helyek közötti VPN-átjárókhoz, pont–hely VPN-átjárókhoz és ExpressRoute-átjárókhoz.

Ez a funkció az Azure Firewalls esetében is támogatott a Virtual WAN biztonságos központokban.

Melyik karbantartást támogatja vagy nem támogatja az ügyfél által ellenőrzött karbantartás?

Az Azure-szolgáltatások rendszeres karbantartási frissítéseken mennek keresztül a funkciók, a megbízhatóság, a teljesítmény és a biztonság javítása érdekében. Miután konfigurálta az erőforrások karbantartási időszakát, a vendég operációs rendszer és a szolgáltatás karbantartása az adott időszakban történik. Ezek a frissítések a legtöbb olyan karbantartási elemhez tartoznak, amelyek aggodalomra adnak okot az ügyfelek számára.

A mögöttes gazdagép hardver- és adatközpont-infrastruktúrafrissítéseit nem fedezik az ügyfél által ellenőrzött karbantartások. Emellett, ha egy nagy súlyosságú biztonsági probléma veszélyeztetheti az ügyfeleinket, előfordulhat, hogy az Azure-nak felül kell bírálnia a karbantartási időszak ügyfél-vezérlését, és el kell végeznie a módosítást. Ezek olyan ritka előfordulások, amelyek csak szélsőséges esetekben használhatók.

Kaphatok speciális értesítést a karbantartásról?

Jelenleg a speciális értesítés nem engedélyezhető a Network Gateway-erőforrások karbantartásához.

Öt óránál rövidebb karbantartási időszakot konfigurálhatok?

Jelenleg legalább ötórás időszakot kell konfigurálnia az előnyben részesített időzónában.

Konfigurálhatok olyan karbantartási ütemezést, amely nem ismétlődik naponta?

Jelenleg napi karbantartási időszakot kell konfigurálnia.

A karbantartási konfigurációs erőforrásoknak ugyanabban a régióban kell lenniük, mint az átjáróerőforrásnak?

Yes.

Szükséges-e üzembe helyeznem egy minimális átjáró-méretezési egységet ahhoz, hogy jogosultságot szerezzek az ügyfél által ellenőrzött karbantartásra?

No.

Mennyi ideig tart, amíg a karbantartási konfigurációs szabályzat érvénybe lép, miután hozzárendelték az átjáró-erőforráshoz?

A hálózati átjárók számára akár 24 órát is igénybe vehet, hogy kövessék a karbantartási ütemtervet, miután a karbantartási szabályzat társításra került az átjáró erőforrással.

Hogyan tervezzem meg a karbantartási időszakokat a VPN és az ExpressRoute együttes használata esetén?

Ha a VPN-et és az ExpressRoute-t együttélési forgatókönyvben használja, vagy ha az erőforrások biztonsági mentésként működnek, javasoljuk, hogy külön karbantartási időszakokat állítson be. Ez a megközelítés biztosítja, hogy a karbantartás ne befolyásolja egyszerre a biztonsági mentési erőforrásokat.

Ütemeztem egy karbantartási időszakot egy későbbi időpontra az egyik erőforrásom számára. Addig szünetelteti a karbantartási tevékenységeket ezen az erőforráson?

Nem, a karbantartási tevékenységek nem lesznek felfüggesztve az erőforráson az ütemezett karbantartási időszak előtti időszakban. A karbantartási ütemtervben nem szereplő napok esetében a karbantartás a szokásos módon folytatódik az erőforráson.

Korlátozva van a meghirdethető útvonalak száma?

Igen, vannak korlátok. Az ExpressRoute legfeljebb 4000 előtagot támogat a privát társviszony-létesítéshez, és 200 előtagot a Microsoft-társviszony-létesítéshez. Az ExpressRoute Premium használatával 10 000 útvonalra növelheti a privát kapcsolódás korlátját. Az Azure magánhálózatos együttműködéséből egy ExpressRoute átjárón keresztül az ExpressRoute-kapcsolaton keresztül meghirdetett útvonalak maximális száma 1000, ami megegyezik mind a standard, mind a prémium ExpressRoute-kapcsolatok esetében. További részletekért tekintse át az ExpressRoute-kapcsolatcsoportok útvonalkorlátait az Azure-előfizetés korlátai és kvótái oldalon . Vegye figyelembe, hogy az IPv6-útvonalhirdetések jelenleg nem támogatottak a Virtual WAN-ban.

Vannak korlátozások a BGP-munkameneten keresztül meghirdethető IP-tartományokra?

Igen, vannak korlátozások. A Microsoft társviszony-létesítési BGP-munkamenetében a privát előtagok (RFC1918) nem fogadhatók el. A Microsoft és privát peering esetén azonban a /32 előtagig bármilyen előtagméret elfogadható.

Mi történik, ha túllépi a BGP útvonalkorlátját?

Ha túllépi a BGP útvonalkorlátját, a BGP-munkamenetek megszakadnak. A munkamenetek akkor lesznek visszaállítva, ha az előtagok száma a korlát alá csökken. További információkért tekintse meg az ExpressRoute-kapcsolatcsoportok útvonalkorlátait az Azure-előfizetések korlátai és kvótái oldalon.

Monitorozhatom az ExpressRoute-kapcsolatcsoporton keresztül meghirdetett vagy fogadott útvonalak számát?

Igen, tudsz. A metrikaalapú riasztások monitorozásának ajánlott eljárásait és konfigurációját az Azure monitorozási ajánlott eljárásaiban is megismerheti.

Mi a javaslat az IP-előtagok számának csökkentésére?

Javasoljuk az előtagok összesítését, mielőtt az ExpressRoute-on vagy a VPN-átjárón keresztül reklámozza őket. Emellett a Route-Maps használatával összegzheti a Virtual WAN-ból vagy a virtuális WAN-ba meghirdetett útvonalakat.

Használhatok felhasználó által definiált útvonaltáblákat a Virtual WAN Hubhoz csatlakoztatott küllős virtuális hálózatokon?

Yes. A Virtual WAN Hub által a csatlakoztatott küllős virtuális hálózatokban üzembe helyezett erőforrásokra meghirdetett útvonalak a Border Gateway Protocol (BGP) típusú útvonalak. Ha egy felhasználó által definiált útvonaltábla a Virtual WAN-hoz csatlakoztatott alhálózathoz van társítva, az "Átjáróútvonalak propagálása" beállítást "Igen" értékre kell állítani ahhoz, hogy a Virtual WAN az adott alhálózaton üzembe helyezett erőforrásokat reklámozhassa. Az Azure mögöttes szoftveralapú hálózati platformja az alábbi algoritmussal választja ki az útvonalakat az Azure útvonalválasztási algoritmusa alapján.

Miért tapasztalok csatlakozási problémákat az Azure-útvonalak Azure-ba való visszatérése után?

Ha azt tervezi, hogy eltávolítja az Azure BGP-közösségeket a virtuális hálózatból és az UDR-útvonalakról, ne hirdesse ezeket az útvonalakat vissza az Azure-ba, mivel ez útválasztási problémákat okoz. Nem javasoljuk, hogy az Azure-útvonalakat újra az Azure-ba reklámozza.

Következő lépések

A Virtual WAN-ról további információt a Virtual WAN-ról szóló cikkben talál.

  • Last updated on