Virtuális WAN – GYIK

Cikk
11/06/2024

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?

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.

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.

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 az alábbi 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és nemrég lett engedélyezve, frissítse a hitelesítő adatait.”

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

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

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.

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

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

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.

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 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 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 azurevirtualwan@microsoft.com léphet az itt felsorolt kapcsolatokkal. 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.

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

Ha több ExpressRoute-kapcsolatcsoport csatlakozik egy Virtuális WAN-központhoz, az ECMP lehetővé teszi a küllős virtuális hálózatokról a helyszíni forgalom ExpressRoute-on keresztüli elosztását az azonos helyszíni útvonalakat hirdető Összes ExpressRoute-kapcsolatcsoport között. Az ECMP jelenleg nincs alapértelmezés szerint engedélyezve a Virtual WAN hubok esetében.

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/MSEE, ami további ugrás a datapathban.

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

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?

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

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.

A BGP-társ által létrehozott BGP-közösségeket (egy csatolt virtuális hálózatban) megőrzi a Virtual WAN?

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

Fontos megjegyezni a következőket:

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.
Az üzembe helyezett méretezési egységek számától függetlenül a forgalom teljesítménycsökkenést tapasztalhat, ha egyetlen TCP-folyamatban több mint 1,5 Gb/s-t küldenek.

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ő úgy, hogy nincs szükség frissítésre vagy alaphelyzetbe állításra a társviszony-létesítési kapcsolaton. Vegye figyelembe a következőket:

A Társviszony panelen nem kell a "Szinkronizálás" gombra kattintania. 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 virtuális hálózatával.
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ózatok címterének módosításáról itt 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 400. Ezt a korlátot a rendszer egyenként alkalmazza a Virtual WAN-üzemelő példányok egyes Virtual WAN-központjaira. A virtuális hálózati címterek, amelyek távoli (más virtual WAN-központok ugyanabban a Virtual WAN-központban) csatlakoznak, nem számítanak bele ebbe a korlátba.

Ez a korlát állítható. A korlátról, a korlát növelését kérő eljárásról és a virtuális WAN-központhoz csatlakoztatott virtuális hálózatok címtereinek meghatározására szolgáló példaszkriptekrő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.

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.

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 társviszony-létesítés korlátját. Az Azure-beli privát társviszony-létesítésből az ExpressRoute-átjárón keresztül egy ExpressRoute-kapcsolatcsoporton keresztül meghirdetett útvonalak maximális száma 1000, ami megegyezik a standard és a prémium Szintű ExpressRoute-kapcsolatcsoportok esetében is. 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 a privát társviszony-létesítés esetében 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, válthat. 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?

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

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.

Megosztás a következőn keresztül: