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, a rendszeres 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?

További információ: Elérhető helyek és régiók.

A felhasználónak rendelkeznie kell központtal és küllővel az SD-WAN/VPN-eszközökkel az Azure Virtual WAN használatához?

A Virtual WAN számos funkciót biztosít egyetlen üvegpanelbe, például helyek/helyek közötti VPN-kapcsolat, Felhasználó/P2S kapcsolat, ExpressRoute-kapcsolat, virtuális hálózati kapcsolat, VPN ExpressRoute-kapcsolat, virtuális hálózatok közötti tranzitív kapcsolat, központosított útválasztás, Azure Firewall és Firewall Manager-biztonság, Monitorozás, ExpressRoute-titkosítás és sok más képesség. A Virtual WAN használatának megkezdéséhez nem kell minden ilyen használati esetet használnia. Első lépésként csak egy használati esetet használhat.

A Virtual WAN-architektúra egy küllős architektúra, amelyben ágak (VPN/SD-WAN-eszközök), felhasználók (Azure VPN-ügyfelek, openVPN vagy IKEv2-ügyfelek), ExpressRoute-kapcsolatcsoportok és virtuális hálózatok szolgálnak küllőként 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. Az SD-WAN/VPN-eszközök küllős használata esetén a felhasználók manuálisan állíthatják be az Azure Virtual WAN portálon, vagy a Virtual WAN Partner CPE (SD-WAN/VPN) használatával állíthatják be az Azure-hoz való kapcsolódást.

A Virtual WAN-partnerek automatizálást biztosítanak a kapcsolathoz, amely 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 nem hálózva lesznek. 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 emellett nem kell letiltania vagy engedélyeznie a funkciót a hálós központok beszerzéséhez. A Virtual WAN számos útválasztási lehetőséget biztosít a küllők (VNet, VPN vagy ExpressRoute) közötti forgalom irányításához. Ez biztosítja a teljes hálós központok egyszerűségét, valamint az igény szerinti útválasztási forgalom rugalmasságát.

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 hubon 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 telepíthető a rendelkezésre állási zónák támogatására az Azure Firewall Manager Portál, 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 kell é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 maga a virtuális WAN-régió problémába merült volna, a virtuális WAN-régióban lévő összes központ továbbra is az aktuális módon fog működni, de a felhasználó nem fog tudni új központokat létrehozni, amíg a virtuális WAN-régió el nem érhető.

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. 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 Client támogatja a Microsoft Entra-hitelesítést. Legalább a Windows 10 ügyfélszámítógép operációs 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.

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 dns-kiszolgálókat ad hozzá a P2S-ügyfelekhez?

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ű Csatlakozás	Összesített átviteli sebesség
0	2	500	0,5 Gb/s
2	2	500	1 Gbps
3	2	500	1,5 Gb/s
4	2	1000	2 Gbps
5	2	1000	2,5 Gb/s
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 Gbps
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 Gb/s
60	6	30000	30 Gb/s
80	8	40 000	40 Gbps
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	70 000	90 Gb/s
200	20	100 000	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, ez nem jelenti azt, hogy az 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.

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.

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-ágeszközök beépített automatizálással rendelkeznek, amely automatikusan kiépíti és csatlakozik 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özponttal is rendelkezhet, ami azt jelenti, hogy több mint 1000 ágat csatlakoztathat egyetlen Azure-régióhoz úgy, hogy több Virtual WAN-központot helyez üzembe az Adott Azure-régióban, amelyek mindegyike saját helyek közötti VPN-átjáróval rendelkezik.

Mi az ajánlott algoritmus és a csomagok másodpercenként a helyek közötti példányonként a Virtual WAN Hubban? Példányonként hány alagút támogatott? 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 az IP Standard kiadás C titkosítás és integritás esetében is GCMAES256 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 Mb/s-os skálázási egység helyek közötti VPN-átjárópéldányt helyez üzembe egy virtuális WAN-központban. 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. Az egy aktív példányban megszüntethető alagutak teljes száma 1000, ami azt is jelenti, hogy az 1 példány átviteli sebessége összesítve lesz elérhető 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)	A PPS maximális száma alagútonként	Példányonkénti átviteli sebesség (Mbps)	Példányonkénti PPS maximális száma
0	500	47K	500	47K
2	1000	94 E	1000	94 E
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

Feljegyzés

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?

Szám 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 befejezte a CPE-eszköz automatizálási munkáját a fent megadott automatizálási irányelvek alapján, a partnereken keresztül kapcsolatba léphet azurevirtualwan@microsoft.com az itt felsorolt Csatlakozás tivitással. 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 SD-WAN-szolgáltató, akkor azt feltételezik, hogy az 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ó aktív-aktív módban van üzembe helyezve egy virtuális központban, ami azt jelenti, hogy a helyszíni eszközöktől különálló alagutak végződnek külön példányokon. 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 a másodlagos aktív példányra kerül, és a felhasználó újracsatlakozhat. A BGP-munkamenetek nem lépnek át a példányokon.

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. Vegye figyelembe továbbá, hogy az átjárók alaphelyzetbe állítása nem változtatja meg 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?

Igen. 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ésekért tekintse meg a Virtual WAN-központ NVA-kkal kapcsolatos lépéseit.

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

Szám A küllős virtuális hálózat nem rendelkezhet virtuális hálózati átjáróval, ha csatlakozik a virtuális központhoz.

A küllős virtuális hálózatok rendelkezhetnek Azure Route Serverrel?

Szám 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 lesznek a BGP-ben.

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

Igen. 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)?

Igen. 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 az egy régión belüli virtuális WAN-központhoz csatlakoztatott virtuális hálózatokhoz, valamint a több Virtuális WAN-központon keresztül két vagy több régióban csatlakoztatott virtuális hálózatokhoz tartozó "globális Virtual WAN virtuális hálózat átvitele" néven.

Bizonyos esetekben a küllős virtuális hálózatok a helyi vagy globális Virtual WAN virtuális hálózatok átvitele mellett virtuális hálózatok közötti 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.

Az elágazási forgalom áthalad az Azure Virtual WAN-on?

Igen. 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?

Szám 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ég szolgáltatásonként egy virtuális WAN-központban található. 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 következményekért tekintse meg az Útválasztási infrastruktúra egységköltségét az Azure Virtual WAN díjszabási oldalán.

Amikor a VPN-webhelyek csatlakoznak egy központhoz, azt kapcsolatok segítségével teszik. A Virtual WAN virtuális központonként legfeljebb 1000 kapcsolatot vagy 2000 IPsec-alagutat támogat. 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 bejárá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. Ebben a konfigurációban győződjön meg arról, hogy 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ál egyik központjában, majd kattintson a méretezési egységre a megfelelő beállítás módosításához.

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?

Igen. 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-központból származik; Az alapértelmezett útvonal propagálása akkor történik, ha a Virtual WAN hub 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 propagálja a hubok (központközi) között.

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

Igen. 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ó: Virtual Hub routing preference page.

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

Az ER-to-ER közötti átvitel mindig globális kapcsolaton keresztül történik. A virtuális központ átjárói dc- vagy Azure-régiókban vannak üzembe helyezve. Amikor két ExpressRoute-kapcsolatcsoport globális elérésű kapcsolaton keresztül csatlakozik, nincs szükség arra, hogy a forgalom a peremhálózati útválasztóktól a virtuális központ tartományvezérlőjéig érkezzen.

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

Igen. 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.

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 viselkedés az, hogy az ExpressRoute-kapcsolatcsoport elérési útját részesíti előnyben a központtól a központig a virtuális hálózatok közötti kapcsolatokhoz. 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 központ útválasztási beállításaké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 halad át, amely jobb teljesítményt nyújt, mint az ExpressRoute-útvonal. Az ExpressRoute elérési útja magában foglalja az ExpressRoute-átjárót, amely alacsonyabb sávszélesség-korlátozásokkal rendelkezik, mint a központi útválasztó, valamint a Microsoft Enterprise Edge-útválasztók/M Standard kiadás E, amely 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ó engedélyezve van az ág–ág között, akkor a kapcsolat le lesz tiltva az 1. és a 4. különálló virtuális hálózat 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 az összes többi forgalmi folyamat esetében (például a 2. virtuális hálózat küllős virtuális hálózatának helyszíni helye nem lesz hatással, a 2. virtuális hálózatról a 3. virtuális hálózatra stb.).

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

Igen. 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.

Mi az ajánlott központi címtér a központ létrehozása során?

Az ajánlott Virtual WAN hub-címtér a /23. A Virtual WAN Hub alhálózatokat rendel különböző átjárókhoz (ExpressRoute, helyek közötti VPN, pont–hely VPN, Azure Firewall, virtuális központ útválasztója). Azokban a forgatókönyvekben, amelyekben az NVA-k egy virtuális központban vannak üzembe helyezve, a /28 általában ki van faragva az NVA-példányokhoz. Ha azonban a felhasználónak több NVA-t kellene kiépítenie, hozzárendelhet egy /27 alhálózatot. Ezért a jövőbeli architektúrát szem előtt tartva, míg a Virtual WAN hubok minimális mérete /24, a létrehozáskor javasolt hubcímtér a felhasználó számára a bemenethez a /23.

Támogatott az IPv6 a Virtual WAN-ban?

Az IPv6 nem támogatott a Virtual WAN hubban és átjáróiban. Ha rendelkezik IPv4- és IPv6-támogatással rendelkező virtuális hálózattal, és a virtuális hálózatot a Virtual WAN-hoz szeretné csatlakoztatni, ez a forgatókönyv jelenleg nem támogatott.

A pont–hely felhasználói VPN-forgatókönyv esetében, amely az Azure Firewallon keresztüli internetkitörést használja, valószínűleg ki kell kapcsolnia az IPv6-kapcsolatot az ügyféleszközön, hogy a virtuális WAN-központ felé irányuló forgalmat kényszerítse. Ennek az az oka, hogy a modern eszközök alapértelmezés szerint IPv6-címeket használnak.

Milyen api-verziót használnak a különböző Virtual WAN-funkciókat automatizáló szkriptek?

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?

Szám 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?

Igen. 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 Servert általában egy ön által felügyelt ügyfélközpont virtuális hálózata helyezi üzembe, míg az Azure Virtual WAN egy érintésmentes, teljes körű hubszolgáltatást biztosít, amelyhez az ügyfelek a küllők végpontjaihoz csatlakoznak (Azure VNet, helyszíni ágak helyek közötti VPN-vel vagy SDWAN-val, távoli felhasználók pont–hely/Távoli felhasználó VPN-nel és Privát kapcsolatokkal az ExpressRoute-tal), és élvezheti a küllős virtuális hálózaton üzembe helyezett NVA-k BGP-társviszony-létesítését más vWAN-kkal együtt olyan képességek, mint a virtuális hálózatok közötti adatátviteli kapcsolat, a VPN és az ExpressRoute közötti tranzitkapcsolat, az egyéni/speciális útválasztás, az egyéni útvonal társítása és propagálása, az útválasztási szándék/szabályzatok a régiók közötti biztonsági problémák nélkül, a Secure Hub/Azure-tűzfal stb. A Virtual WAN BGP-társviszony-létesítéssel kapcsolatos további információkért tekintse meg a BGP virtuális központokkal való társviszony-létesítését 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. 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 a VPN-átjáró ASN-jének módosítására?

Szám A Virtual WAN nem támogatja a VPN-á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	Csatlakozás ionok másodpercenként	Mega-Bits másodpercenként	Csomagok másodpercenként
1 méretezési egység	14000	2000	200,000
2 méretezési egység	28,000	4 000	400,000
3 méretezési egység	42,000	6000	600,000
4 méretezési egység	56,000	8,000	800,000
5 méretezési egység	70,000	10,000.	1,000,000
6 méretezési egység	84,000	12 000	1,200,000
7 méretezési egység	98,000	14000	1,400,000
8 méretezési egység	112,000	16000	1,600,000
9 méretezési egység	126,000	18000	1,800,000
10 méretezési egység	140,000.	20000	2,000,000

Skálázza a 2–10- es egységeket a karbantartási műveletek során, és tartsa karban az összesített átviteli sebességet. Az 1. skálázási egység azonban egy karbantartási művelet során enyhe eltérést tapasztalhat az átviteli sebességben.

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 jelenik meg az „Útválasztó frissítése a legújabb szoftververzióra" üzenet és gomb a portálon?

Feljegyzés

2024 januárjától a Virtual WAN csapata megkezdte a virtuális központok frissítését a legújabb verzióra. Ha nem frissítette a központot, de most azt tapasztalja, hogy a központ útválasztójának verziója a "legújabb", akkor a központot a Virtual WAN csapata frissítette.

Az Azure-ra kiterjedő Cloud Services-alapú infrastruktúra elavult. Ennek eredményeképpen a Virtual WAN csapata már dolgozik a virtuális útválasztók frissítésén a jelenlegi Cloud Services-infrastruktúráról a virtuálisgép-méretezési csoportokon alapuló üzemelő példányokra. Minden újonnan létrehozott virtuális központ automatikusan üzembe lesz helyezve a legújabb virtuálisgép-méretezési csoportokon alapuló infrastruktúrán. Ha megnyitja a Virtual WAN hub erőforrását, és látja ezt az üzenetet és gombot, a gombra kattintva frissítheti az útválasztót a legújabb verzióra. Ha ki szeretné használni az új Virtual WAN-funkciókat, például a BGP-társviszonyt a központtal, frissítenie kell a virtuális központ útválasztóját az Azure Portalon keresztül. Ha a gomb nem látható, nyisson meg egy támogatási esetet.

A virtuális központ útválasztóját csak akkor tudja frissíteni, ha a központ összes erőforrása (átjárók/útvonaltáblák/VNet-kapcsolatok) sikeres állapotban vannak. Győződjön meg arról, hogy az összes küllős virtuális hálózat aktív/engedélyezett előfizetésben van, és hogy a küllős virtuális hálózatok nem törlődnek. Emellett, mivel ehhez a művelethez új virtuálisgép-méretezési csoportokon alapuló virtuális központ-útválasztók üzembe helyezésére van szükség, a virtuális hálózatok közötti forgalom várható állásideje 1–2 perc lesz ugyanazon a központon keresztül, és 5–7 perc az összes többi, a hubon áthaladó forgalom esetében. Egyetlen Virtual WAN-erőforráson belül a központokat egyenként kell frissíteni ahelyett, hogy egyszerre többre frissítenek. Amikor az útválasztó verziója "Legújabb" szöveget ad meg, a központ már nem frissül. A frissítés után nem változik az útválasztási viselkedés.

A virtuális központ útválasztójának frissítésével kapcsolatban számos dolgot érdemes megjegyezni:

• Ha már konfigurálta a BGP-társviszonyt a Virtual WAN-központ és egy küllős virtuális hálózatban lévő NVA között, akkor törölnie kell, majd újra létre kell hoznia a BGP-társát. Mivel a virtuális központ útválasztójának IP-címe a frissítés után megváltozik, újra kell konfigurálnia az NVA-t is, hogy társviszonyban legyen a virtuális központ útválasztójának új IP-címeivel. Ezek az IP-címek "virtualRouterIps" mezőként jelennek meg a Virtual Hub erőforrás-JSON-fájljában.

• Ha hálózati virtuális berendezéssel (NVA) rendelkezik a virtuális központban, az NVA-partnerével kell együttműködnie, hogy útmutatást kapjon a Virtual WAN Hub frissítésére vonatkozóan.

• Ha a virtuális központ több mint 15 útválasztási infrastruktúraegységtel van konfigurálva, a frissítési kísérlet előtt skálázzon a virtuális központban 2 útválasztási infrastruktúra-egységre. A központ frissítése után több mint 15 útválasztási infrastruktúraegységre skálázhatja vissza a központot.

Ha a frissítés bármilyen okból meghiúsul, a központ automatikusan helyreáll a régi verzióra, hogy továbbra is működőképes legyen a beállítás.

További tudnivalók:

• A felhasználónak tulajdonosi vagy közreműködői szerepkörre lesz szüksége a központi útválasztó verziójának pontos állapotának megtekintéséhez. Ha egy felhasználóhoz olvasói szerepkör van rendelve a Virtual WAN-erőforráshoz és -előfizetéshez, az Azure Portal megjeleníti a felhasználónak, hogy a központi útválasztót frissíteni kell a legújabb verzióra, még akkor is, ha a központ már a legújabb verzión van.

• Ha a küllős virtuális hálózat előfizetési állapotát letiltottról engedélyezettre módosítja, majd frissíti a virtuális központot, frissítenie kell a virtuális hálózati kapcsolatot a virtuális központ frissítése után (például konfigurálhatja a virtuális hálózati kapcsolatot úgy, hogy egy álcímkére propagálja).

• Ha a központ nagy számú küllős virtuális hálózathoz csatlakozik (60 vagy több), akkor azt tapasztalhatja, hogy 1 vagy több küllős virtuális hálózat közötti társviszony-létesítés sikertelen állapotba kerül a frissítés után. A virtuális hálózatok közötti társviszonyok sikeres állapotba való visszaállításához a frissítés után konfigurálhatja a virtuális hálózati kapcsolatokat úgy, hogy azok egy álcímkére propagáljanak, vagy törölheti és újra létrehozhatja ezeket a virtuális hálózati kapcsolatokat.

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ő úgy, hogy nincs szükség frissítésre vagy alaphelyzetbe állításra a társviszony-létesítési kapcsolaton. A virtuális hálózatok címterének módosításáról itt talál további információt.

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 és ExpressRoute-átjárókhoz.

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?

Igen.

Üzembe kell helyeznem egy minimális átjáró-méretezési egységet, hogy jogosult legyen az ügyfél által ellenőrzött karbantartásra?

Szám

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 akár 24 órát is igénybe vehetnek, ha a karbantartási szabályzat az átjáró-erőforráshoz van társítva.

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 az egyik erőforrásom jövőbeli dátumá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.

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.