Vanliga frågor om Virtual WAN

Är Azure Virtual WAN i GA?

Ja, Azure Virtual WAN är allmänt tillgänglig (GA). Men Virtual WAN består av flera funktioner och scenarier. Det finns funktioner eller scenarier i Virtual WAN där Microsoft använder taggen Förhandsversion. I dessa fall är den specifika funktionen, eller själva scenariot, i förhandsversion. Om du inte använder en specifik förhandsgranskningsfunktion gäller vanlig GA-support. Mer information om förhandsversionssupport finns i Kompletterande villkor för användning Microsoft Azure förhandsversioner.

Behöver användaren ha nav och ekrar med SD-WAN/VPN-enheter för att kunna använda Azure Virtual WAN?

Virtual WAN innehåller många funktioner som är inbyggda i en enda ruta, till exempel PLATS-/plats-till-plats-VPN-anslutning, Användar-/P2S-anslutning, ExpressRoute-anslutning, Virtual Network-anslutning, VPN ExpressRoute-sammankoppling, transitiv anslutning mellan virtuella nätverk, centraliserad routning, Azure Firewall- och Firewall Manager-säkerhet, övervakning, ExpressRoute-kryptering och många andra funktioner. Du behöver inte ha alla dessa användningsfall för att börja använda Virtual WAN. Du kan komma igång med bara ett användningsfall.

Arkitekturen Virtual WAN är en nav- och ekerarkitektur med inbyggd skalning och prestanda där grenar (VPN/SD-WAN-enheter), användare (Azure VPN-klienter, openVPN- eller IKEv2-klienter), ExpressRoute-kretsar, virtuella nätverk fungerar som ekrar till virtuella hubbar. Alla hubbar är anslutna i fullständigt nät i ett Standard Virtual WAN vilket gör det enkelt för användaren att använda Microsofts stamnät för alla-till-alla-anslutningar (alla ekrar). För hubb- och ekerenheter med SD-WAN/VPN-enheter kan användarna antingen konfigurera det manuellt i Azure Virtual WAN-portalen eller använda Virtual WAN Partner CPE (SD-WAN/VPN) för att konfigurera anslutningen till Azure.

Virtual WAN tillhandahåller automatisering för anslutning, vilket är möjligheten att exportera enhetsinformation till Azure, ladda ned Azure-konfigurationen och upprätta en anslutning till Azure Virtual WAN hubben. För punkt-till-plats-/användar-VPN-anslutning stöder vi Azure VPN-klienten,OpenVPN- eller IKEv2-klienten.

Kan du inaktivera helt nätade hubbar i en Virtual WAN?

Virtual WAN finns i två varianter: Basic och Standard. I Basic Virtual WAN är hubbar inte nätade. I en standard Virtual WAN ansluts hubbar och ansluts automatiskt när det virtuella WAN-nätverket först konfigureras. Användaren behöver inte göra något specifikt. Användaren behöver inte heller inaktivera eller aktivera funktionen för att hämta nätade hubbar. Virtual WAN dig många routningsalternativ för att styra trafik mellan ekrar (VNet, VPN eller ExpressRoute). Det ger dig enkel helt nätade hubbar och flexibiliteten att dirigera trafik efter dina behov.

Hur hanteras Tillgänglighetszoner och återhämtning i Virtual WAN?

Virtual WAN är en samling hubbar och tjänster som görs tillgängliga i hubben. Användaren kan ha så många Virtual WAN per behov. I en Virtual WAN finns det flera tjänster som VPN, ExpressRoute osv. Var och en av dessa tjänster distribueras automatiskt över Tillgänglighetszoner (förutom Azure Firewall), om regionen stöder Tillgänglighetszoner. Om en region blir en tillgänglighetszon efter den första distributionen i hubben kan användaren återskapa gatewayerna, vilket utlöser en distribution av tillgänglighetszonen. Alla gatewayer etableras i en hubb som aktiv-aktiv, vilket innebär att det finns inbyggd återhämtning i en hubb. Användare kan ansluta till flera hubbar om de vill ha återhämtningsförmåga mellan regioner.

För närvarande Azure Firewall kan distribueras för att stödja Tillgänglighetszoner med Azure Firewall Manager Portal, PowerShell eller CLI. Det finns för närvarande inget sätt att konfigurera en befintlig brandvägg som ska distribueras över tillgänglighetszoner. Du måste ta bort och distribuera om Azure Firewall.

Även om begreppet Virtual WAN är globalt, är den Virtual WAN resurs Resource Manager och distribueras regionalt. Om själva den virtuella WAN-regionen skulle ha ett problem kommer alla hubbar i det virtuella WAN-nätverken att fortsätta att fungera som det är, men användaren kommer inte att kunna skapa nya hubbar förrän den virtuella WAN-regionen är tillgänglig.

Vilken klient stöder Azure Virtual WAN VPN för användare (punkt-till-plats)?

Virtual WAN azure VPN-klient,OpenVPN-klient eller IKEv2-klient. Azure AD-autentisering stöds med Azure VPN-klienten. Minst Windows 10 version 17763.0 eller senare av klientoperativsystemet krävs. OpenVPN-klienter har stöd för certifikatbaserad autentisering. När certifikatbaserad autentisering har valts på gatewayen visas filen.ovpn* som ska laddas ned till enheten. IKEv2 stöder både certifikat- och RADIUS-autentisering.

För användar-VPN (punkt-till-plats) – varför är P2S-klientpoolen uppdelad i två vägar?

Varje gateway har två instanser. Uppdelningen sker så att varje gatewayinstans oberoende kan allokera klient-IP-adresser för anslutna klienter och trafik från det virtuella nätverket dirigeras tillbaka till rätt gatewayinstans för att undvika hopp mellan gatewayinstanser.

Hur gör jag för att lägga till DNS-servrar för P2S-klienter?

Det finns två alternativ för att lägga till DNS-servrar för P2S-klienterna. Den första metoden är att föredra eftersom den lägger till anpassade DNS-servrar till gatewayen i stället för klienten.

  1. Använd följande PowerShell-skript för att lägga till de anpassade DNS-servrarna. Ersätt värdena för din miljö.

    // 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. Om du använder Azure VPN-klienten för Windows 10 kan du ändra XML-filen <dnsservers> <dnsserver> </dnsserver> </dnsservers> för den nedladdade profilen och lägga till taggarna innan du importerar den.

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

För användar-VPN (punkt-till-plats)– hur många klienter stöds?

Varje VPN P2S-gateway för användare har två instanser. Varje instans stöder upp till ett visst antal anslutningar när skalningsenheterna ändras. Skalningsenhet 1–3 stöder 500 anslutningar, skalningsenhet 4–6 stöder 1 000 anslutningar, skalningsenhet 7–12 stöder 5 000 anslutningar och skalningsenhet 13–18 stöder upp till 10 000 anslutningar.

Anta till exempel att användaren väljer 1 skalningsenhet. Varje skalningsenhet skulle innebära en aktiv-aktiv gateway distribuerad och var och en av instanserna (i det här fallet 2) skulle stödja upp till 500 anslutningar. Eftersom du kan få 500 anslutningar * 2 per gateway betyder det inte att du planerar för 1 000 i stället för 500 för den här skalningsenheten. Instanser kan behöva serdas när anslutningen för de extra 500 kan avbrytas om du överskrider det rekommenderade antalet anslutningar. Se också till att planera för stilleståndstid om du bestämmer dig för att skala upp eller ned på skalningsenheten eller ändra punkt-till-plats-konfigurationen på VPN-gatewayen.

Vad är Virtual WAN gatewayskalningsenheter?

En skalningsenhet är en enhet som definieras för att välja ett aggregerat dataflöde för en gateway i en virtuell hubb. 1 skalningsenhet för VPN = 500 Mbit/s. 1 skalningsenhet för ExpressRoute = 2 Gbit/s. Exempel: 10 skalningsenhet för VPN skulle innebära 500 Mbit/s * 10 = 5 Gbit/s

Vad är skillnaden mellan en virtuell Azure-nätverksgateway (VPN Gateway) och en Azure Virtual WAN VPN-gateway?

Virtual WAN tillhandahåller storskalig plats-till-plats-anslutning och byggs för dataflöde, skalbarhet och användarvänlighet. När du ansluter en plats till en Virtual WAN VPN-gateway skiljer sig den från en vanlig virtuell nätverksgateway som använder gatewaytypen "VPN". När du ansluter en ExpressRoute-krets till en Virtual WAN-hubb använder den på samma sätt en annan resurs för ExpressRoute-gatewayen än den vanliga virtuella nätverksgatewayen som använder gatewaytypen ExpressRoute.

Virtual WAN stöder upp till 20 Gbit/s aggregerat dataflöde både för VPN och ExpressRoute. Virtual WAN har även automatisering för anslutning till ett ekosystem med CPE-grenenhetspartner. CPE-grenenheter har inbyggd automatisering som automatiskt företer och ansluter till Azure Virtual WAN. Enheterna finns tillgängliga från ett växande ekosystem av SD-WAN- och VPN-partner. Se listan över föredragna partner.

Hur skiljer Virtual WAN en virtuell nätverksgateway i Azure?

Vpn för en virtuell nätverksgateway är begränsat till 30 tunnlar. För anslutningar bör du använda Virtual WAN för ett storskaligt virtuellt privat nätverk. Du kan ansluta upp till 1 000 grenanslutningar per virtuell hubb med sammanlagt 20 Gbit/s per hubb. En anslutning är en aktiv-aktiv-tunnel från den lokala VPN-enheten till den virtuella hubben. Du kan också ha flera virtuella hubbar per region, vilket innebär att du kan ansluta fler än 1 000 grenar till en enda Azure-region genom att distribuera flera Virtual WAN-hubbar i den Azure-regionen, var och en med en egen VPN-gateway för plats-till-plats.

Vi rekommenderar att du skickar cirka 95 000 PPS med GCMAES256-algoritmen för både IPSEC-kryptering och -integritet för optimala prestanda. Även om trafik inte blockeras om fler än 95 000 PPS skickas, kan prestandaförsämring som svarstid och paketförlust förväntas. Skapa ytterligare tunnlar om större PPS krävs.

Vilka enhetsleverantörer (Virtual WAN partner) stöds?

Just nu stöds den helt automatiserade Virtual WAN-upplevelsen av många partner. Mer information finns i Virtual WAN-partner.

Vilka är automatiseringsstegen för virtuella WAN-partner?

Information om automatiseringssteg för partner finns i avsnittet om automatisering för virtuella WAN-partner.

Måste jag använda en önskad partnerenhet?

Nej. Du kan använda valfri VPN-kompatibel enhet som följer Azure-kraven för IKEv2/IKEv1 IPsec-stöd. Virtual WAN också CPE-partnerlösningar som automatiserar anslutningen till Azure Virtual WAN gör det enklare att konfigurera IPsec VPN-anslutningar i stor skala.

Hur automatiserar Virtual WAN-partner anslutningsmöjligheter med Azure Virtual WAN?

Programvarudefinierade anslutningslösningar hanterar vanligtvis gren-enheter med hjälp av en kontrollant eller ett enhetsetableringscenter. Kontrollanten kan automatisera anslutningar till Azure Virtual WAN med hjälp av Azure API:er. Automatiseringen omfattar överföring av greninformation, nedladdning av Azure-konfigurationen, konfiguration av IPsec-tunnlar till Virtuella Azure-hubbar och automatisk konfiguration av anslutningar från grenenheten till Azure Virtual WAN. När du har hundratals grenar är det enkelt att ansluta med Virtual WAN CPE-partner eftersom onboarding-upplevelsen gör att du inte behöver konfigurera, konfigurera och hantera storskaligA IPsec-anslutningar. Mer information finns i Virtual WAN automatisering av partner.

Vad händer om en enhet som jag använder inte finns Virtual WAN en partnerlista? Kan jag fortfarande använda den för att ansluta Azure Virtual WAN VPN?

Ja så länge enheten stöder IPsec IKEv1 eller IKEv2. Virtual WAN-partner automatiserar anslutningen från enheten till Azure VPN-slutpunkter. Detta innebär att automatisera steg som "överföring av förgreningsinformation", "IPsec och konfiguration" och "anslutning". Eftersom enheten inte är från ett Virtual WAN-partnerekosystem måste du göra grovjobbet med att manuellt ta Azure-konfigurationen och uppdatera enheten för att konfigurera IPsec-anslutning.

Hur registreras nya partner som inte visas i startpartnerlistan?

Alla VIRTUAL WAN-API:er är öppna API:er. Du kan gå igenom dokumentationen för Virtual WAN för att utvärdera teknisk genomförbarhet. En perfekt partner är en partner som har en enhet som kan etableras för IKEv1 eller IKEv2 IPSec-anslutning. När företaget har slutfört automatiseringsarbetet för sin CPE-enhet baserat på automationsriktlinjerna ovan kan du kontakta för att visas här azurevirtualwan@microsoft.com Anslutning via partner. Om du är en kund som vill att en viss företagslösning ska listas som en Virtual WAN-partner, be företaget kontakta Virtual WAN genom att skicka ett e-postmeddelande till azurevirtualwan@microsoft.com .

Hur stöds Virtual WAN SD-WAN-enheter?

Virtual WAN automatiserar IPsec-anslutningen till Azure VPN-slutpunkter. Om Virtual WAN är en SD-WAN-provider är det underförstått att SD-WAN-kontrollanten hanterar automatisering och IPsec-anslutning till Azure VPN-slutpunkter. Om SD-WAN-enheten kräver en egen startpunkt i stället för Azure VPN för alla egna SD-WAN-funktioner kan du distribuera SD-WAN-startpunkten i ett azure-VNet och samexistera med Azure Virtual WAN.

Hur många VPN-enheter kan ansluta till en enda hubb?

Upp till 1 000 anslutningar stöds per virtuell hubb. Varje anslutning består av fyra länkar och varje länkanslutning stöder två tunnlar som är i en aktiv-aktiv-konfiguration. Tunnlarna avslutas i en VPN-gateway för en virtuell Azure-hubb. Länkar representerar den fysiska Internetleverantörens länk på grenen/VPN-enheten.

Vad är en grenanslutning till Azure Virtual WAN?

En anslutning från en gren eller VPN-enhet till Azure Virtual WAN är en VPN-anslutning som ansluter virtuellt vpn-platsen och Azure-VPN Gateway i en virtuell hubb.

Vad händer om den lokala VPN-enheten bara har en tunnel till en Azure Virtual WAN VPN-gateway?

En Azure Virtual WAN-anslutning består av 2 tunnlar. En Virtual WAN VPN-gateway distribueras i en virtuell hubb i aktivt-aktivt läge, vilket innebär att det finns separata tunnlar från lokala enheter som avslutas på separata instanser. Det här är rekommendationen för alla användare. Men om användaren väljer att bara ha en tunnel till en av Virtual WAN VPN-gatewayinstanserna, om gatewayinstansen av någon anledning (underhåll, korrigeringar osv.) tas offline, flyttas tunneln till den sekundära aktiva instansen och användaren kan uppleva en återanslutning. BGP-sessioner flyttas inte mellan instanser.

Kan den lokala VPN-enheten ansluta till flera hubbar?

Ja. När trafikflödet kommer från den lokala enheten till den närmaste Microsoft-nätverkskanten och sedan till den virtuella hubben.

Finns nya Resource Manager-resurser tillgängliga för Virtual WAN?

Ja, Virtual WAN har nya Resource Manager resurser. Mer information finns i Översikt.

Kan jag distribuera och använda virtuell installation av mitt favoritnätverk (i ett virtuellt NVA-nätverk) med Azure Virtual WAN?

Ja, du kan ansluta önskat NVA-VNet (virtuell nätverksinstallation) till Azure Virtual WAN.

Kan jag skapa en virtuell nätverksinstallation i den virtuella hubben?

En virtuell nätverksinstallation (NVA) kan inte distribueras i en virtuell hubb. Du kan dock skapa den i ett virtuellt ekernätverk som är anslutet till den virtuella hubben och aktivera lämplig routning för att dirigera trafik efter dina behov.

Kan ett virtuellt ekernätverk ha en virtuell nätverksgateway?

Nej. Det virtuella ekernätverket kan inte ha en virtuell nätverksgateway om det är anslutet till den virtuella hubben.

Finns det stöd för BGP i VPN-anslutningen?

Ja, BGP stöds. När du skapar en VPN-plats kan du ange BGP-parametrarna i den. Detta innebär att alla anslutningar som skapats i Azure för den platsen kommer att aktiveras för BGP.

Finns det licens- eller prisinformation om Virtual WAN?

Ja. Se sidan med prissättning.

Är det möjligt att konstruera Azure Virtual WAN med en Resource Manager-mall?

En enkel konfiguration av en Virtual WAN med en hubb och en vpnsite kan skapas med hjälp av en snabbstartsmall. Virtual WAN är främst en REST- eller portaldriven tjänst.

Kan ekernätverk som är anslutna till en virtuell hubb kommunicera med varandra (V2V-överföring)?

Ja. Standard Virtual WAN stöder transitiv anslutning mellan virtuella nätverk via den Virtual WAN som de virtuella nätverken är anslutna till. I Virtual WAN terminologi refererar vi till dessa sökvägar som "lokal Virtual WAN VNet-överföring" för virtuella nätverk som är anslutna till en Virtual Wan-hubb inom en enda region och "global Virtual WAN VNet-överföring" för virtuella nätverk som är anslutna via flera Virtual WAN-hubbar i två eller flera regioner.

I vissa scenarier kan ekernätverk också peer-kopplades direkt med varandra med hjälp av peering för virtuella nätverk utöver lokal eller global Virtual WAN VNet-överföring. I det här fallet har VNet-peering företräde framför den transitiva anslutningen via Virtual WAN hubben.

Tillåts gren-till-gren-anslutningar i Virtual WAN?

Ja, det finns stöd för gren-till-gren-anslutningar i Virtual WAN. Gren gäller konceptuellt för VPN-plats, ExpressRoute-kretsar eller PUNKT-till-plats-/användar-VPN-användare. Aktivering av gren-till-gren är aktiverat som standard och kan finnas i WAN-konfigurationsinställningar. Detta gör att VPN-grenar/användare kan ansluta till andra VPN-grenar och överföringsanslutningen är också aktiverad mellan VPN- och ExpressRoute-användare.

Passerar trafik från gren till gren genom Azure Virtual WAN?

Ja. Trafik från gren till gren passerar genom Azure Virtual WAN.

Kräver Virtual WAN ExpressRoute från varje plats?

Nej. Virtual WAN kräver inte ExpressRoute från varje plats. Dina platser kan anslutas till ett providernätverk med hjälp av en ExpressRoute-krets. För platser som är anslutna med ExpressRoute till en virtuell hubb och IPsec VPN till samma hubb tillhandahåller den virtuella hubben överföringsanslutning mellan VPN- och ExpressRoute-användaren.

Finns det ett dataflöde eller en anslutningsgräns för nätverket när du använder Azure Virtual WAN?

Nätverkets dataflöde är per tjänst i en virtuell WAN-hubb. Du kan ha så många virtuella WAN som du vill, men varje Virtual WAN 1 hubb per region. I varje hubb är VPN-aggregerat dataflöde upp till 20 Gbit/s, ExpressRoute-aggregerat dataflöde är upp till 20 Gbit/s och användar-VPN/punkt-till-plats VPN-aggregerat dataflöde är upp till 20 Gbit/s. Routern i den virtuella hubben stöder upp till 50 Gbit/s för trafikflöden mellan virtuella nätverk och förutsätter totalt 2 000 VM-arbetsbelastningar för alla virtuella nätverk som är anslutna till en enda virtuell hubb. Den här gränsen kan ökas för att öppna en supportbegäran online. Kostnadskonsekvenser finns i Routing Infrastructure Unit cost (Kostnadskonsekvens för routning av infrastrukturenhet) Azure Virtual WAN sidan Med prisinformation.

När VPN-platser ansluter till en hubb gör de det med anslutningar. Virtual WAN upp till 1 000 anslutningar eller 2 000 IPsec-tunnlar per virtuell hubb. När fjärranslutna användare ansluter till en virtuell hubb ansluter de till P2S VPN-gatewayen, som har stöd för upp till 10 000 användare beroende på vilken skalningsenhet (bandbredd) som valts för P2S VPN-gatewayen i den virtuella hubben.

Vad är det totala VPN-dataflödet för en VPN-tunnel och en anslutning?

Det totala VPN-dataflödet för en hubb är upp till 20 Gbit/s baserat på den valda skalningsenheten för VPN-gatewayen. Dataflödet delas av alla befintliga anslutningar. Varje tunnel i en anslutning har stöd för upp till 1 Gbit/s.

Kan jag använda NAT-T på mina VPN-anslutningar?

Ja, NAT-traverserning (NAT-T) stöds. DEN Virtual WAN VPN-gatewayen utför INTE NAT-liknande funktioner på de inre paketen till/från IPsec-tunnlarna. I den här konfigurationen ser du till att den lokala enheten initierar IPsec-tunneln.

Jag ser inte inställningen 20 Gbit/s för den virtuella hubben i portalen. Hur gör jag för att konfigurera det?

Gå till VPN-gatewayen i en hubb på portalen och klicka sedan på skalningsenheten för att ändra den till lämplig inställning.

Tillåter Virtual WAN lokala enheten att använda flera Internetleverantörer parallellt, eller är det alltid en enda VPN-tunnel?

Lokala enhetslösningar kan tillämpa trafikprinciper för att styra trafiken över flera tunnlar till Azure Virtual WAN (VPN-gateway i den virtuella hubben).

Vad är global transit-arkitektur?

Information om global transit-arkitektur finns i Global transit network architecture and Virtual WAN.

Hur dirigeras trafiken i Azures stamnät?

Trafiken följer mönstret: grenenhet ->ISP->Microsoft network edge->Microsoft DC (hub VNet)->Microsoft network edge->ISP->branch device

Vad behöver du på varje plats i den här modellen? Bara en Internetanslutning?

Ja. En Internetanslutning och fysisk enhet som stöder IPsec, helst från våra integrerade Virtual WAN partner. Du kan också manuellt hantera konfigurationen och anslutningen till Azure från önskad enhet.

Hur gör jag för att aktivera standardväg (0.0.0.0/0) för en anslutning (VPN, ExpressRoute eller Virtual Network)?

En virtuell hubb kan sprida en inlärd standardväg till ett virtuellt nätverk/plats-till-plats-VPN/ExpressRoute-anslutning om flaggan är Aktiverad för anslutningen. Den här flaggan visas när användaren redigerar en virtuell nätverksanslutning, en VPN-anslutning eller en ExpressRoute-anslutning. Som standard är den här flaggan inaktiverad när en plats eller en ExpressRoute-krets är ansluten till en hubb. Den är aktiverad som standard när en virtuell nätverksanslutning läggs till för att ansluta ett virtuellt nätverk till en virtuell hubb.

Standardvägen kommer inte från den Virtual WAN hubben. Standardvägen sprids om den redan har lärts in av Virtual WAN-hubben på grund av att en brandvägg distribueras i hubben, eller om en annan ansluten plats har tvingad tunneling aktiverat. En standardväg sprids inte mellan hubbar (mellan hubbar).

Går det att skapa flera virtuella WAN-hubbar i samma region?

Ja. Kunder kan nu skapa fler än en hubb i samma region för samma Azure Virtual WAN.

Hur väljer den virtuella hubben i ett virtuellt WAN den bästa vägen för en väg från flera hubbar?

Om en virtuell hubb lär sig samma väg från flera fjärrhubar är ordningen som den bestämmer i följande ordning:

  1. Matchning med längst prefix.
  2. Lokala vägar via interhub.
  3. Statiska vägar över BGP: Detta är i kontexten till det beslut som fattas av den virtuella hubbrouter. Men om beslutsfattare är VPN-gatewayen där en plats annonserar vägar via BGP eller tillhandahåller statiska adressprefix, kan statiska vägar föredras framför BGP-vägar.
  4. ExpressRoute (ER) över VPN: ER prioriteras framför VPN när kontexten är en lokal hubb. Överföringsanslutning mellan ExpressRoute-kretsar är endast tillgänglig via Global Reach. I scenarier där ExpressRoute-kretsen är ansluten till en hubb och det finns en annan ExpressRoute-krets som är ansluten till en annan hubb med VPN-anslutning kan VPN därför föredras för scenarier mellan hubbar.
  5. AS-sökvägslängd (Virtuella hubbar förbereder vägar med AS-sökvägen 65520-65520 när de annonserar vägar till varandra).

Tillåter Virtual WAN anslutning mellan ExpressRoute-kretsar?

Överföringen mellan ER-till-ER sker alltid via global räckvidd. Virtuella hubbgatewayer distribueras i DC- eller Azure-regioner. När två ExpressRoute-kretsar ansluter via global räckvidd behöver trafiken inte komma hela vägen från gränsroutrar till den virtuella hubbdomänkontrollanten.

Finns det ett begrepp för vikt i Azure Virtual WAN ExpressRoute-kretsar eller VPN-anslutningar?

När flera ExpressRoute-kretsar är anslutna till en virtuell hubb ger routningsvikten för anslutningen en mekanism för att ExpressRoute i den virtuella hubben ska föredra den ena kretsen framför den andra. Det finns ingen mekanism för att ange en vikt för en VPN-anslutning. Azure föredrar alltid en ExpressRoute-anslutning framför en VPN-anslutning inom en enda hubb.

Föredrar Virtual WAN ExpressRoute framför VPN för utgående trafik i Azure

Ja. Virtual WAN föredrar ExpressRoute framför VPN för utgående trafik i Azure.

Vad skulle göra Virtual WAN VPN-anslutningsväg att föredra framför ExpressRoute när en Virtual WAN en ExpressRoute-krets och en VPN-plats är ansluten till den?

När en ExpressRoute-krets är ansluten till en virtuell hubb är Microsofts gränsroutrar den första noden för kommunikation mellan den lokala platsen och Azure. Dessa gränsroutrar kommunicerar med Virtual WAN ExpressRoute-gatewayer som i sin tur lär sig vägar från den virtuella hubbrouter som styr alla vägar mellan gatewayer i Virtual WAN. Microsoft-gränsroutrar bearbetar ExpressRoute-vägar för virtuella hubbar med högre prioritet över vägar som lärs in från en lokal plats.

Om VPN-anslutningen av någon anledning blir det primära mediet för den virtuella hubben att lära sig vägar från (till exempel redundansscenarier mellan ExpressRoute och VPN), såvida inte VPN-platsen har en längre AS Path-längd, fortsätter den virtuella hubben att dela VPN-inlärda vägar med ExpressRoute-gatewayen. Detta gör att Microsoft-gränsroutrar föredrar VPN-vägar framför lokala vägar.

Vad är sökvägen för ett VNet som är anslutet till hubb 1 för att nå ett VNet som är anslutet i hubb 2 när två hubbar (hubb 1 och 2) är anslutna och det finns en ExpressRoute-krets som är ansluten till båda hubbarna?

Det aktuella beteendet är att föredra ExpressRoute-kretssökvägen framför hubb-till-hubb för VNet-till-VNet-anslutning. Detta rekommenderas dock inte i en Virtual WAN konfiguration. Du kan lösa detta genom att göra en av två saker:

  • Konfigurera flera ExpressRoute-kretsar (olika leverantörer) för att ansluta till en hubb och använda hubb-till-hubb-anslutningen som tillhandahålls av Virtual WAN för trafikflöden mellan regioner.

  • Kontakta produktteamet för att delta i den offentliga förhandsversionen av gated. I den här förhandsversionen passerar trafik mellan de två hubbarna genom Azure Virtual WAN-routern i varje hubb och använder en hubb-till-hubb-sökväg i stället för ExpressRoute-sökvägen (som passerar genom Microsoft Edge-routrar/MSEE). Om du vill använda den här funktionen i previewpreferh2h@microsoft.com förhandsversionen skickar du e-Virtual WAN id:n, prenumerations-ID:t och Azure-regionen. Förvänta dig ett svar inom 48 timmar (måndag-fredag) med bekräftelse på att funktionen är aktiverad.

Kan hubbar skapas i olika resursgrupper i Virtual WAN?

Ja. Det här alternativet är för närvarande endast tillgängligt via PowerShell. För Virtual WAN-portalen måste hubbarna vara i samma resursgrupp som den Virtual WAN resursen.

Den rekommenderade Virtual WAN hubbens adressutrymme är /23. Virtual WAN tilldelar undernät till olika gatewayer (ExpressRoute, plats-till-plats-VPN, punkt-till-plats-VPN, Azure Firewall, virtuell hubbrouter). För scenarier där NVA:er distribueras i en virtuell hubb, tar en /28 vanligtvis ut för NVA-instanserna. Om användaren däremot etablerar flera NVA:er kan ett /27-undernät tilldelas. Därför bör du ha en framtida arkitektur i åtanke, Virtual WAN-hubbar distribueras med en minsta storlek på /24, men det rekommenderade hubbadressutrymmet vid skapandetiden för användaren att mata in är /23.

Kan du ändra storlek på eller ändra adressprefixen för en eker Virtual Network ansluten till Virtual WAN Hub?

Nej. Detta är för närvarande inte möjligt. Om du vill ändra adressprefixen för en eker-Virtual Network tar du bort anslutningen mellan eker-Virtual Network och Virtual WAN-hubben, ändrar adressutrymmena för eker-Virtual Network och skapar sedan anslutningen mellan eker-Virtual Network och Virtual WAN Hub.

Finns det stöd för IPv6 i Virtual WAN?

IPv6 stöds inte i Virtual WAN och dess gatewayer. Om du har ett VNet som har stöd för IPv4 och IPv6 och du vill ansluta det virtuella nätverket till Virtual WAN stöds inte det här scenariot för närvarande.

För punkt-till-plats-användar-VPN-scenariot med Internet-avbrott via Azure Firewall måste du förmodligen inaktivera IPv6-anslutningen på klientenhet för att tvinga trafik till Virtual WAN hubben. Det beror på att moderna enheter som standard använder IPv6-adresser.

Minst version 05-01-2020 (1 maj 2020) krävs.

Finns det några Virtual WAN gränser?

Se avsnittet Virtual WAN gränser på sidan Prenumerations- och tjänstbegränsningar.

Vilka är skillnaderna mellan Virtual WAN (Basic och Standard)?

Se Grundläggande och Standard virtuella WAN. Information om priser finns på sidan Prissättning.

Lagrar Virtual WAN kunddata?

Nej. Virtual WAN lagrar inga kunddata.

Finns det några leverantörer av hanterade tjänster som kan hantera Virtual WAN för användare som en tjänst?

Ja. En lista över MSP-lösningar (Managed Service Provider) som aktiverats via Azure Marketplace finns i Azure Marketplace erbjudanden från Azure-nätverkstjänster MSP-partner.

Hur skiljer Virtual WAN Hub-routning från Azure Route Server i ett VNet?

Azure Route Server tillhandahåller en Border Gateway Protocol-peeringtjänst (BGP) som kan användas av NVA:er (Network Virtual Appliance) för att lära sig vägar från vägservern i ett HUBB-hubbnätverk. Virtual WAN-routning innehåller flera funktioner, inklusive VNet-till-VNet-överföringsroutning, anpassad routningsassociation och spridning samt en helt nätad hubbtjänst med noll touch tillsammans med anslutningstjänster för ExpressRoute, Plats-VPN, P2S VPN för fjärranvändare/storskalig och säker hubb (Azure Firewall). När du upprättar en BGP-peering mellan din NVA och Azure Route Server kan du annonsera IP-adresser från din NVA till ditt virtuella nätverk. För alla avancerade routningsfunktioner, till exempel överföringsroutning, anpassad routning osv. kan du använda Virtual WAN routning.

Om jag använder en säkerhetsprovider från tredje part (Zscaler, iBoss eller Kontrollpunkt) för att skydda min Internettrafik, varför ser jag inte VPN-webbplatsen som är associerad med tredjepartssäkerhetsprovidern i Azure Portal?

När du väljer att distribuera en säkerhetspartnerprovider för att skydda Internetåtkomsten för dina användare skapar tredjepartssäkerhetsleverantören en VPN-webbplats för din räkning. Eftersom tredjepartssäkerhetsprovidern skapas automatiskt av providern och inte är en användarskapad VPN-plats visas inte den här VPN-platsen i Azure Portal.

Mer information om tillgängliga alternativ för säkerhetsproviders från tredje part och hur du ställer in detta finns i Distribuera en säkerhetspartnerprovider.

Nästa steg