Veelgestelde vragen over Virtual WAN

Is Azure Virtual WAN algemeen beschikbaar?

Ja, Azure Virtual WAN is algemeen beschikbaar. Virtual WAN bestaat echter uit verschillende functies en scenario's. Er zijn functies of scenario's in Virtual WAN waarop Microsoft de tag Preview toepast. In dergelijke gevallen is de specifieke functie of het scenario zelf een preview-versie. Als u geen specifieke preview-functie gebruikt, is sprake van normale algemene beschikbaarheid. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure-previews voor meer informatie over de ondersteuning van preview-versies.

Moet de gebruiker over hub en spoke beschikken met SD-WAN/VPN-apparaten om Azure Virtual WAN te kunnen gebruiken?

Virtual WAN biedt tal van functies die zijn ingebouwd in één onderdeel, zoals site-/site-naar-site-VPN-connectiviteit, gebruikers-/P2S-connectiviteit, ExpressRoute-connectiviteit, Virtual Network-connectiviteit, VPN ExpressRoute-interconnectiviteit, transitieve VNet-naar-VNet-connectiviteit, gecentraliseerde routering, Azure Firewall en Firewall Manager-beveiliging, bewaking, ExpressRoute-versleuteling en vele andere mogelijkheden. U hoeft niet al deze use-cases te hebben om Virtual WAN te gaan gebruiken. U kunt aan de slag met slechts één use-case.

De Virtual WAN-architectuur is een hub en spoke-architectuur met schaal en prestaties ingebouwd waarbij vertakkingen (VPN/SD-WAN-apparaten), gebruikers (Azure VPN-clients, openVPN- of IKEv2-clients), ExpressRoute-circuits, virtuele netwerken fungeren als spokes voor virtuele hubs. Alle hubs zijn verbonden in full mesh in een standaard virtuele WAN, waardoor de gebruiker de Microsoft-backbone eenvoudig kan gebruiken voor any-to-any-connectiviteit (elke willekeurige spoke). Voor hub en spoke met SD-WAN-/VPN-apparaten kunnen gebruikers het handmatig instellen in de Azure Virtual WAN-portal of gebruikmaken van de Azure Virtual-partner WAN CPE (SD-WAN/VPN) om connectiviteit met Azure in te stellen.

Virtual WAN-partners bieden automatisering voor connectiviteit, dus de mogelijkheid om de apparaatgegevens te exporteren naar Azure, de Azure-configuratie te downloaden en verbinding te maken met de Azure Virtual WAN-hub. Voor punt-naar-site-connectiviteit of VPN-connectiviteit voor gebruikers ondersteunen we Azure VPN Client, OpenVPN of IKEv2-client.

Kunnen volledig gemeshede hubs in een virtuele WAN worden uitgeschakeld?

Virtual WAN is beschikbaar in twee soorten: Basic en Standard. In Basic Virtual WAN worden hubs niet gemeshed. In een Standard Virtual WAN worden hubs gemeshed en automatisch verbonden wanneer de virtuele WAN voor het eerst wordt ingesteld. De gebruiker hoeft niets specifieks te doen. De gebruiker hoeft ook de functionaliteit niet in of uit te schakelen om gemeshede hubs te verkrijgen. Virtual WAN biedt een groot aantal routeringsopties om verkeer tussen spokes (VNet, VPN of ExpressRoute) te leiden. Het biedt het gemak van volledig gemeshede hubs en tevens de flexibiliteit om verkeer naar behoefte te leiden.

Hoe worden beschikbaarheidszones en tolerantie in Virtual WAN verwerkt?

Virtual WAN is een verzameling hubs en services die beschikbaar zijn in de hub. De gebruiker kan over net zoveel virtuele WAN beschikken als nodig is. In een Virtual WAN hub zijn er meerdere services, zoals VPN, ExpressRoute, enzovoort. Elk van deze services wordt automatisch geïmplementeerd in Beschikbaarheidszones (behalve Azure Firewall), als de regio ondersteuning biedt Beschikbaarheidszones. Als een regio na de eerste implementatie in de hub een beschikbaarheidszone wordt, kan de gebruiker de gateways opnieuw maken, waardoor de implementatie van een beschikbaarheidszone wordt geactiveerd. Alle gateways worden in een hub als actief-actief ingericht, wat inhoudt dat er tolerantie is ingebouwd in een hub. Gebruikers kunnen verbinding maken met meerdere hubs als ze tolerantie voor verschillende regio's willen.

Momenteel kunnen Azure Firewall worden geïmplementeerd ter ondersteuning van Beschikbaarheidszones met Azure Firewall Manager Portal, PowerShell of CLI. Er is momenteel geen manier om een bestaande firewall te configureren die moet worden geïmplementeerd in beschikbaarheidszones. U moet uw gegevens verwijderen en opnieuw implementeren Azure Firewall.

Hoewel het concept van Virtual WAN globaal is, is de daadwerkelijke Virtual WAN-resource gebaseerd op Resource Manager en regionaal gedistribueerd. Als de virtuele WAN-regio zelf een probleem kent, blijven alle hubs in die virtuele WAN functioneren, maar de gebruiker kan pas nieuwe hubs maken als de virtuele WAN-regio beschikbaar is.

Welke client wordt door de VPN voor gebruikers (punt-naar-site) van de Azure Virtual WAN ondersteund?

Virtual WAN ondersteunt Azure VPN Client, OpenVPN Client of een IKEv2-client. Azure AD-verificatie wordt ondersteund met Azure VPN Client. Er is minimaal Windows 10-client OS-versie 17763.0 of hoger vereist. OpenVPN-client(s) kunnen verificatie op basis van certificaten ondersteunen. Zodra op certificaten gebaseerde auth is geselecteerd op de gateway, ziet u het .ovpn*-bestand dat naar uw apparaat moet worden gedownload. IKEv2 ondersteunt zowel certificaat- als RADIUS-authenticatie.

Voor gebruikers-VPN (punt-naar-site) - waarom is de P2S-clientgroep opgesplitst in twee routes?

Elke gateway heeft twee exemplaren. De splitsing treedt op zodat elk exemplaar van de gateway onafhankelijk client-IP's kan toewijzen voor verbonden clients; verkeer afkomstig van het virtuele netwerk wordt teruggestuurd naar het juiste gateway-exemplaar om een exemplaar-hops tussen gateways te voorkomen.

Hoe kan ik DNS-servers voor P2S-clients toevoegen?

Er zijn twee opties om DNS-servers voor de P2S-clients toe te voegen. De eerste methode verdient de voorkeur omdat hiermee de aangepaste DNS-servers aan de gateway worden toegevoegd in plaats van de client.

1. Gebruik het volgende PowerShell-script om de aangepaste DNS-servers toe te voegen. Vervang de waarden voor uw omgeving.

   // 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. Als u de Azure VPN Client voor Windows 10 gebruikt, kunt u het gedownloade XML-profielbestand wijzigen en de tags <dnsservers><dnsserver> </dnsserver></dnsservers> toevoegen voordat u het importeert.

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

Voor VPN voor gebruikers (punt-naar-site): hoeveel clients worden ondersteund?

Elke VPN P2S-gateway van de gebruiker heeft twee exemplaren. Elk exemplaar ondersteunt maximaal een bepaald aantal verbindingen wanneer de schaaleenheden veranderen. Schaaleenheid 1-3 ondersteunt 500 verbindingen, schaaleenheid 4-6 ondersteunt 1000 verbindingen, schaaleenheid 7-12 ondersteunt 5000 verbindingen en schaaleenheid 13-18 ondersteunt maximaal 10.000 verbindingen.

Stel bijvoorbeeld dat de gebruiker 1 schaaleenheid kiest. Elke schaaleenheid impliceert een geïmplementeerde actief-actief-gateway en elk exemplaar (in dit geval twee) zou maximaal 500 verbindingen ondersteunen. Omdat u 500 verbindingen x 2 per gateway kunt verkrijgen, betekent dit niet dat u voor deze schaaleenheid voor 1000 gaat plannen in plaats van de 500. Het kan zijn dat er exemplaren moeten worden onderhouden, zodat de connectiviteit voor de extra 500 kan worden onderbroken als u het aantal aanbevolen verbindingen overschrijdt. Houd ook rekening met uitvaltijd voor het geval dat u de schaaleenheid omhoog of omlaag wilt schalen of de punt-naar-site-configuratie op de VPN-gateway wilt wijzigen.

Wat zijn Virtual WAN gatewayschaaleenheden?

Een schaaleenheid is een eenheid die is gedefinieerd om een geaggregeerde doorvoer van een gateway in een virtuele hub te kunnen kiezen. 1 VPN-schaaleenheid = 500 Mbps. 1 ExpressRoute-schaaleenheid = 2 Gbps. Voorbeeld: Voor 10 VPN-schaaleenheden geldt: 500 Mbps x 10 = 5 Gbps

Wat is het verschil tussen een virtuele Azure-netwerkgateway (VPN Gateway) en een Azure Virtual WAN VPN-gateway?

Virtual WAN biedt grootschalige site-naar-site-connectiviteit en is ontworpen met het oog op doorvoer, schaalbaarheid en gebruiksgemak. Wanneer u een site verbindt met een Virtual WAN-VPN-gateway, verschilt deze van een normale virtuele netwerk-gateway, die gebruikmaakt van het gatewaytype VPN. En wanneer u een ExpressRoute-circuit verbindt met een Virtual WAN-hub, wordt er ook een andere resource gebruikt voor de ExpressRoute-gateway dan de normale virtuele netwerk-gateway, die gebruikmaakt van het gatewaytype ExpressRoute.

Virtual WAN ondersteunt maximaal 20 Gbps geaggregeerde doorvoer voor VPN en ExpressRoute. Virtual WAN beschikt ook over automatisering voor connectiviteit met een ecosysteem van CPE-vertakkingsapparaatpartners. CPE-vertakkingsapparaten beschikken over ingebouwde automatisering waarmee automatisch wordt ingericht en verbinding met Azure Virtual WAN wordt gemaakt. Deze apparaten zijn beschikbaar binnen een groeiend ecosysteem van SD-WAN- en VPN-partners. Zie de lijst met partners van voorkeur.

Waarin verschilt Virtual WAN van een virtuele Azure-netwerkgateway?

Een VPN in een virtuele netwerkgateway is beperkt tot dertig tunnels. U moet Virtual WAN gebruiken voor grootschalige VPN-verbindingen. U kunt maximaal 1000 vertakkingsverbindingen per virtuele hub verbinden met een totaal van 20 Gbps per hub. Een verbinding is een actief-actief-tunnel van het on-premises VPN-apparaat naar de virtuele hub. U kunt ook meerdere virtuele hubs per regio hebben, wat betekent dat u meer dan 1000 vertakkingen kunt verbinden met één Azure-regio door meerdere Virtual WAN-hubs in die Azure-regio te implementeren, elk met een eigen site-naar-site VPN-gateway.

Wat is de aanbevolen limiet voor pakketten per seconde per IPSEC-tunnel?

Het is raadzaam om ongeveer 95.000 PPS met GCMAES256-algoritme te verzenden voor zowel IPSEC-versleuteling als integriteit voor optimale prestaties. Hoewel verkeer niet wordt geblokkeerd als er meer dan 95.000 PPS wordt verzonden, kan prestatievermindering zoals latentie en pakketverminderingen worden verwacht. Maak extra tunnels als er meer PPS is vereist.

Welke apparaatproviders (Virtual WAN-partners) worden ondersteund?

Veel partners bieden momenteel ondersteuning voor de volledig geautomatiseerde Virtual WAN-ervaring. Zie Virtual WAN-partners voor meer informatie.

Wat zijn de stappen voor automatisering voor Virtual WAN-partners?

Zie Automatisering voor Virtual WAN-partners voor meer informatie.

Moet ik een apparaat van een voorkeurspartner gebruiken?

Nee. U kunt ieder VPN-apparaat gebruiken dat voldoet aan de Azure-vereisten voor IKEv2/IKEv1 IPSec-ondersteuning. Virtual WAN heeft ook CPE-partneroplossingen waarmee de connectiviteit met Azure Virtual WAN wordt geautomatiseerd, waardoor het eenvoudiger wordt om IPsec VPN-verbindingen op schaal in te stellen.

Hoe automatiseren Virtual WAN-partners connectiviteit met Azure Virtual WAN?

Softwarematige oplossingen voor netwerkconnectiviteit beheren hun vertakkingsapparaten doorgaans met behulp van een controller of een knooppunt voor apparaatinrichting. De controller kan Azure API’s gebruiken om de connectiviteit met Azure Virtual WAN te automatiseren. De automatisering omvat het uploaden van vertakkingsgegevens, het downloaden van de Azure-configuratie, het instellen van IPsec-tunnels in Virtuele Azure-hubs en het automatisch instellen van connectiviteit van het vertakkingsapparaat naar Azure Virtual WAN. Wanneer u honderden vertakkingen hebt, kunt u eenvoudig verbinding maken met behulp van Virtual WAN CPE-partners, omdat dankzij het onboarden het niet meer nodig is grootschalige IPsec-connectiviteit in te stellen, te configureren en te beheren. Raadpleeg Virtual WAN partner automation (Automatisering voor Virtual WAN-partners) voor meer informatie.

Wat gebeurt er als een apparaat dat ik gebruik niet voorkomt in de lijst met Virtual WAN-partners? Kan ik het nog steeds gebruiken om verbinding te maken met Azure Virtual WAN-VPN?

Ja, als het apparaat IPsec IKEv1 of IKEv2 ondersteunt. Virtual WAN-partners automatiseren de connectiviteit vanaf het apparaat tot Azure VPN-eindpunten. Dit impliceert de automatisering van stappen als het uploaden van vertakkingsgegevens, IPsec en configuratie en connectiviteit. Omdat uw apparaat niet afkomstig is van een Virtual WAN-partnerecosysteem, moet u het zware werk doen van het handmatig configureren van Azure en het bijwerken van uw apparaat om IPsec-connectiviteit in te kunnen stellen.

Hoe worden nieuwe partners die nog niet zijn vermeld in de startlijst van partners, opgenomen?

Alle virtuele WAN API's zijn open API's. U kunt de documentatie Automatisering van Virtual WAN-partners raadplegen om de technische haalbaarheid vast te stellen. Een ideale partner is iemand die een apparaat heeft dat kan worden ingericht voor een IKEv1 of IKEv2 IPSec-verbinding. Zodra het bedrijf de automatiseringswerkzaamheden voor het CPE-apparaat heeft voltooid op basis van de hierboven beschreven automatiseringsrichtlijnen, kunt u contact opnemen met azurevirtualwan@microsoft.com om hier te worden vermeld: Connectiviteit via partners. Als u een klant bent die wilt dat een bepaalde bedrijfsoplossing wordt vermeld als een Virtual WAN-partner, moet u het bedrijf contact laten opnemen met de Virtual WAN door een e-mail te sturen naar azurevirtualwan@microsoft.com .

Hoe biedt Virtual WAN ondersteuning voor SD-WAN-apparaten?

Virtual WAN-partners automatiseren IPsec-connectiviteit voor Azure VPN-eindpunten. Als de Virtual WAN-partner een SD-WAN-provider is, wordt ervan uitgegaan dat de SD-WAN-controller de automatisering en IPsec-verbinding voor Azure VPN-eindpunten beheert. Als het SD-WAN-apparaat in plaats van Azure VPN een eigen eindpunt nodig heeft voor een eigen SD-WAN-functionaliteit, kunt u het SD-WAN-eindpunt in een Azure-VNet implementeren dat naast Azure Virtual WAN aanwezig kan zijn.

Hoeveel VPN-apparaten kunnen verbinding maken met één hub?

Per virtuele hub worden maximaal 1000 verbindingen ondersteund. Elke verbinding bestaat uit vier koppelingen en elke koppelingsverbinding ondersteunt twee tunnels die zich in een actief-actief-configuratie bevinden. De tunnels eindigen in een VPN-gateway van de virtuele Azure-hub. Koppelingen vertegenwoordigen de fysieke ISP-koppeling op het vertakkings-/VPN-apparaat.

Wat is een vertakkingsverbinding met Azure Virtual WAN?

Een verbinding van een vertakking of VPN-apparaat naar Azure Virtual WAN is een VPN-verbinding die virtueel verbinding maakt met de VPN-site en de Azure VPN Gateway in een virtuele hub.

Wat gebeurt er als het on-premises VPN-apparaat slechts één tunnel naar een Azure Virtual WAN VPN-gateway heeft?

Een Azure Virtual WAN verbinding bestaat uit 2 tunnels. Een Virtual WAN VPN-gateway wordt geïmplementeerd in een virtuele hub in de modus actief-actief, wat inhoudt dat er afzonderlijke tunnels zijn van on-premises apparaten die op afzonderlijke exemplaren worden beëindigen. Dit is de aanbeveling voor alle gebruikers. Als de gebruiker er echter voor kiest om slechts één tunnel naar een van de Virtual WAN VPN-gateway-exemplaren te hebben, wordt de tunnel om een of andere reden (onderhoud, patches, enzovoort) offline gehaald, wordt de tunnel verplaatst naar het secundaire actieve exemplaar en kan de gebruiker opnieuw verbinding maken. BGP-sessies worden niet verplaatst tussen exemplaren.

Kan het on-premises VPN-apparaat verbinding maken met meerdere hubs?

Ja. In het begin loopt de verkeersstroom van het on-premises apparaat naar de dichtstbijzijnde Microsoft-netwerkrand en vervolgens naar de virtuele hub.

Zijn er nieuwe Resource Manager-resources beschikbaar voor Virtual WAN?

Ja, Virtual WAN beschikt over nieuwe Resource Manager-resources. Zie voor meer informatie het Overzicht.

Kan ik mijn favoriete virtuele netwerkapparaat implementeren en gebruiken (in een NVA-VNet) met Azure Virtual WAN?

Ja, u kunt uw favoriete virtuele netwerkapparaat (NVA)-VNet verbinden met de Azure Virtual WAN.

Kan ik een virtueel netwerkapparaat binnen de virtuele hub maken?

Een virtueel netwerkapparaat (NVA) kan niet binnen een virtuele hub worden geïmplementeerd. U kunt het echter maken in een spoke-VNet dat is verbonden met de virtuele hub en de juiste routering inschakelen zodat het verkeer naar behoefte wordt doorgestuurd.

Kan een spoke-VNet een virtuele netwerkgateway hebben?

Nee. Het spoke-VNet kan geen virtuele netwerkgateway hebben als deze is verbonden met de virtuele hub.

Is er ondersteuning voor BGP in VPN-connectiviteit?

Ja, BGP wordt ondersteund. Wanneer u een VPN-site maakt, kunt u er de BGP-parameters opgeven. Dit betekent dat alle verbindingen die in Azure zijn gemaakt voor die site, voor BGP worden ingeschakeld.

Is er informatie over licentieverlening of prijzen beschikbaar voor Virtual WAN?

Ja. Zie de prijzenpagina.

Is het mogelijk om een Azure Virtual WAN te maken met een Resource Manager-sjabloon?

Een eenvoudige configuratie van één virtuele WAN met één hub en één VPN-site kan met behulp van een quickstart-sjabloon worden gemaakt. Virtual WAN is voornamelijk een service op basis van REST of de portal.

Kunnen spoke-VNets die zijn verbonden met een virtuele hub met elkaar communiceren (V2V Transit)?

Ja. Standard Virtual WAN ondersteunt transitieve VNet-naar-VNet-connectiviteit via de Virtual WAN-hub waarmee de VNets zijn verbonden. In Virtual WAN terminologie verwijzen we naar deze paden als 'lokale Virtual WAN VNet-doorvoer' voor VNets die zijn verbonden met een Virtual Wan-hub binnen één regio, en 'global Virtual WAN VNet transit' voor VNets die zijn verbonden via meerdere Virtual WAN-hubs in twee of meer regio's.

In sommige scenario's kunnen spoke-VNets ook rechtstreeks met elkaar worden verbonden met behulp van peering voor virtuele netwerken, naast lokale of Virtual WAN VNet-doorvoer. In dit geval heeft VNet-peering voorrang op de transitieve verbinding via de Virtual WAN-hub.

Is een vertakking-naar-vertakking-verbinding toegestaan in Virtual WAN?

Ja, een vertakking-naar-vertakking-verbinding is beschikbaar in Virtual WAN. Vertakking is conceptueel toepasbaar op gebruikers van VPN-sites, ExpressRoute-circuits of punt-naar-site-/gebruikers-VPN's. Het inschakelen van vertakking naar vertakking is standaard ingeschakeld en kan zich in de WAN-configuratie-instellingen bevinden. Hierdoor kunnen VPN-vertakkingen/-gebruikers verbinding maken met andere VPN-vertakkingen en wordt transitconnectiviteit ook ingeschakeld tussen VPN- en ExpressRoute-gebruikers.

Loopt vertakking-naar-vertakking-verkeer via Azure Virtual WAN?

Ja. Vertakking-naar-vertakking-verkeer passeert Azure Virtual WAN.

Is voor Virtual WAN vanaf elke site ExpressRoute nodig?

Nee. Voor Virtual WAN is niet vanaf elke locatie ExpressRoute nodig. Uw sites kunnen worden verbonden met een providernetwerk met behulp van een ExpressRoute-circuit. Voor sites die via ExpressRoute zijn verbonden met een virtuele hub en IPsec VPN in dezelfde hub, biedt de virtuele hub transitconnectiviteit tussen de VPN- en ExpressRoute-gebruiker.

Is er een netwerkdoorvoer- of verbindingslimiet bij gebruik van Azure Virtual WAN?

Netwerkdoorvoer vindt per service in een virtuele WAN-hub plaats. Hoewel u zoveel virtuele WAN's kunt hebben als u wilt, staat elke virtuele WAN één hub per regio toe. In elke hub is de geaggregeerde VPN-doorvoer maximaal 20 Gbps. De geaggregeerde ExpressRoute-doorvoer is maximaal 20 Gbps en de geaggregeerde gebruikers-VPN-/punt-naar-sitedoorvoer is maximaal 20 Gbps. De router in de virtuele hub ondersteunt maximaal 50 Gbps voor VNet-naar-VNet-verkeersstromen en gaat uit van een totaal van 2000 VM-workloads voor alle VNets die zijn verbonden met één virtuele hub. Deze limiet kan worden verhoogd door een online klantondersteuningsaanvraag te openen. Zie Kosten voor routeringsinfrastructuureenheid op de pagina Azure Virtual WAN kosten voor kosteninfrastructuren.

Wanneer VPN-sites verbinding maken met een hub, doen ze dit met verbindingen. Virtual WAN ondersteunt maximaal 1000 verbindingen of 2000 IPsec-tunnels per virtuele hub. Wanneer externe gebruikers verbinding maken met de virtuele hub, maken ze verbinding met de P2S VPN-gateway. Deze biedt ondersteuning voor maximaal 10.000 gebruikers, afhankelijk van de schaaleenheid (bandbreedte) die voor de P2S VPN-gateway in de virtuele hub is gekozen.

Wat is de totale VPN-doorvoer van een VPN-tunnel en een -verbinding?

De totale VPN-doorvoer van een hub is maximaal 20 Gbps op basis van de gekozen schaaleenheid van de VPN-gateway. De doorvoer wordt gedeeld door alle bestaande verbindingen. Elke tunnel in een verbinding kan maximaal 1 Gbps ondersteunen.

Kan ik NAT-T gebruiken voor mijn VPN-verbindingen?

Ja, NAT-traversal (NAT-T) wordt ondersteund. De Virtual WAN VPN-gateway voert GEEN NAT-achtige functionaliteit uit op de binnenste pakketten van/naar de IPsec-tunnels. Zorg ervoor dat in deze configuratie het on-premises apparaat de IPsec-tunnel initieert.

De instelling van 20 Gbps wordt niet weergeven voor de virtuele hub in de portal. Hoe kan ik dit configureren?

Navigeer naar de VPN-gateway in een hub in de portal en klik vervolgens op de schaaleenheid om deze te wijzigen in de juiste instelling.

Kan het on-premises apparaat in Virtual WAN meerde ISP's parallel gebruiken of is er altijd sprake van één VPN-tunnel?

On-premises apparaat-oplossingen kunnen verkeersbeleid toepassen om verkeer via meerdere tunnels naar de Azure Virtual WAN-hub (VPN-gateway in de virtuele hub) te sturen.

Wat is wereldwijde doorvoerarchitectuur?

Zie Wereldwijde architectuur voor doorvoernetwerk en Virtual WAN voor meer informatie over wereldwijde doorvoerarchitectuur.

Hoe wordt het verkeer naar de Azure-backbone geleid?

Het verkeer volgt het volgende patroon: vertakkingsapparaat->ISP->Microsoft-netwerkrand>Microsoft DC (hub-VNet)->Microsoft-netwerkrand->ISP->vertakkingsapparaat

Wat is er met dit model op elke locatie nodig? Alleen een internetverbinding?

Ja. Een internetverbinding en een fysiek apparaat dat IPsec ondersteunt, bij voorkeur van onze geïntegreerde Virtual WAN-partners. Optioneel kunt u de configuratie en verbinding met Azure vanaf het apparaat van voorkeur handmatig beheren.

Hoe kan ik standaardroute (0.0.0.0/0) inschakelen voor een verbinding (VPN, ExpressRoute of Virtual Network)?

In een virtuele hub kan een inmiddels bekende standaardroute worden doorgegeven naar een virtuele netwerk-/site-naar-site-VPN-/ExpressRoute-verbinding als de vlag voor de verbinding de status Ingeschakeld heeft. Deze vlag wordt weergegeven als de gebruiker een verbinding met een virtueel netwerk, een VPN-verbinding of een ExpressRoute aanpast. Deze vlag wordt standaard uitgeschakeld wanneer een site of een ExpressRoute-circuit met een hub wordt verbonden. De vlag is standaard ingeschakeld wanneer een virtuele netwerkverbinding wordt toegevoegd om een VNet te verbinden met een virtuele hub.

De standaardroute is niet afkomstig van de Virtual WAN-hub. De standaardroute wordt doorgegeven als deze al bekend is bij de virtuele WAN-hub als gevolg van het implementeren van een firewall in de hub, of als voor een andere verbonden site geforceerd tunnelen is ingeschakeld. Een standaardroute wordt niet doorgegeven tussen hubs (tussen hubs).

Is het mogelijk om meerdere virtuele WAN-hubs in dezelfde regio te maken?

Ja. Klanten kunnen nu meer dan één hub in dezelfde regio maken voor dezelfde Azure Virtual WAN.

Hoe selecteert de virtuele hub in een virtueel WAN het beste pad voor een route van meerdere hubs?

Als een virtuele hub dezelfde route van meerdere externe hubs leert, is de volgorde waarin deze besluit als volgt:

1. Overeenkomst met langste voorvoegsel.
2. Lokale routes in plaats van interhub.
3. Statische routes via BGP: dit is in context van de beslissing die wordt genomen door de virtuele hubrouter. Als de beslisser echter de VPN-gateway is waar een site routes via BGP adverteert of statische adres voorvoegsels biedt, kunnen statische routes de voorkeur hebben boven BGP-routes.
4. ExpressRoute (ER) in plaats van VPN: ER heeft de voorkeur boven VPN wanneer de context een lokale hub is. Overgangsconnectiviteit tussen ExpressRoute-circuits is alleen beschikbaar via Global Reach. In scenario's waarin het ExpressRoute-circuit is verbonden met één hub en er een ander ExpressRoute-circuit is verbonden met een andere hub met EEN VPN-verbinding, heeft VPN mogelijk de voorkeur voor scenario's tussen hubs.
5. AS-padlengte (virtuele hubs maken routes met het AS-pad 65520-65520 bij het adverteren van routes naar elkaar).

Staat de Virtual WAN-hub connectiviteit tussen ExpressRoute-circuits toe?

Overgang van ER-naar-ER vindt altijd via Global Reach plaats. Virtuele hubgateways worden geïmplementeerd in DC- of Azure-regio's. Wanneer twee ExpressRoute-circuits verbinding maken via Global Reach, hoeft het verkeer niet de hele weg af te leggen van de Edge-routers tot de virtuele hub-DC.

Speelt het concept gewicht een rol bij Azure Virtual WAN ExpressRoute-circuits or VPN-verbindingen

Wanneer meerdere ExpressRoute-circuits met een virtuele hub zijn verbonden, biedt de mate van routering (gewicht) voor de verbinding een mechanisme waarmee ExpressRoute in de virtuele hub een voorkeur heeft voor het ene circuit boven het andere. Er is geen mechanisme om een gewicht in te stellen voor een VPN-verbinding. Azure geeft binnen één hub altijd de voorkeur aan een ExpressRoute-verbinding boven een VPN-verbinding.

Is er een voorkeur van Virtual WAN voor ExpressRoute boven VPN voor verkeer dat Azure verlaat?

Ja. Virtual WAN geeft de voorkeur aan ExpressRoute boven VPN voor verkeer dat Naar Azure gaat.

Als een Virtual WAN-hub verbonden is met zowel een ExpressRoute-circuit als een VPN-site, wat zou dan de reden zijn dat er een voorkeur voor de route via de VPN-verbinding is boven ExpressRoute?

Wanneer een ExpressRoute-circuit is verbonden met een virtuele hub, vormen de Microsoft-randrouters het eerste knooppunt voor communicatie tussen on-premises en Azure. Deze randrouters communiceren met de Virtual WAN ExpressRoute-gateways die op hun beurt routes bewaren van de virtuele hubrouter waarmee alle routes tussen gateways in Virtual WAN worden beheerd. De Microsoft-randrouters verwerken virtuele ExpressRoute-hubroutes met prioriteit hoger dan die voor routes die on-premises worden overgenomen.

Als de VPN-verbinding het primaire medium voor de virtuele hub wordt om routes van te leren (bijvoorbeeld failoverscenario's tussen ExpressRoute en VPN), tenzij de VPN-site een langere padlengte heeft, blijft de virtuele hub via VPN geleerde routes delen met de ExpressRoute-gateway. Dit zorgt ervoor dat de Microsoft-randrouters de voorkeur geven aan VPN-routes boven on-premises routes.

Wanneer twee hubs (hub 1 en 2) zijn verbonden en er een ExpressRoute-circuit als een strik met beide hubs is verbonden, wat is dan het pad voor een VNet dat is verbonden met hub 1 om een VNet te bereiken dat is aangesloten op hub 2?

Het huidige gedrag is om de voorkeur te geven aan het ExpressRoute-circuit boven hub-naar-hub voor VNet-naar-VNet-connectiviteit. Dit wordt echter niet aangemoedigd in een Virtual WAN installatie. Om dit op te lossen, kunt u een van de volgende twee dingen doen:

• Configureer meerdere ExpressRoute-circuits (verschillende providers) om verbinding te maken met één hub en gebruik de hub-naar-hub-connectiviteit van Virtual WAN voor verkeersstromen tussen regio's.

• Neem contact op met het productteam om deel te nemen aan de gated openbare preview. In deze preview passeert verkeer tussen de twee hubs de Azure Virtual WAN-router in elke hub en gebruikt een hub-naar-hub-pad in plaats van het ExpressRoute-pad (dat door de Microsoft-randrouters/MSEE gaat). Als u deze functie tijdens de preview wilt gebruiken, e-mailt u een previewpreferh2h@microsoft.com e-mail Virtual WAN de id's, de abonnements-id en de Azure-regio. U kunt binnen 48 werkdagen (maandag tot vrijdag) een antwoord verwachten met de bevestiging dat de functie is ingeschakeld.

Kunnen hubs worden gemaakt in een andere resourcegroep in Virtual WAN?

Ja. Deze optie is momenteel alleen beschikbaar via PowerShell. De Virtual WAN portal vereist dat de hubs zich in dezelfde resourcegroep als de Virtual WAN resource zelf.

Wat is de aanbevolen adresruimte van de hub tijdens het maken van de hub?

De aanbevolen Virtual WAN hubadresruimte is /23. Virtual WAN hub wijst subnetten toe aan verschillende gateways (ExpressRoute, site-naar-site-VPN, punt-naar-site-VPN, Azure Firewall, virtuele hubrouter). Voor scenario's waarin NVA's worden geïmplementeerd binnen een virtuele hub, wordt meestal een /28 voor de NVA-exemplaren geïmplementeerd. Als de gebruiker echter meerdere NNET's zou inrichten, kan er een /27-subnet worden toegewezen. Houd daarom rekening met een toekomstige architectuur, terwijl Virtual WAN-hubs worden geïmplementeerd met een minimale grootte van /24, de aanbevolen hub-adresruimte op het moment dat de gebruiker invoert is /23.

Kunt u de grootte wijzigen van de adres voorvoegsels van een spoke-Virtual Network verbonden met de Virtual WAN Hub?

Nee. Dit is momenteel niet mogelijk. Als u de adres voorvoegsels van een spoke-Virtual Network wilt wijzigen, verwijdert u de verbinding tussen de spoke-Virtual Network en de Virtual WAN-hub, wijzigt u de adresruimten van de spoke-Virtual Network en maakt u vervolgens de verbinding tussen de spoke-Virtual Network en de Virtual WAN Hub opnieuw.

Is er ondersteuning voor IPv6 in Virtual WAN?

IPv6 wordt niet ondersteund in de Virtual WAN hub en de gateways. Dit scenario wordt momenteel niet ondersteund als u een VNet hebt met IPv4- en IPv6-ondersteuning en u het VNet wilt verbinden met Virtual WAN.

Voor het punt-naar-site-gebruikers-VPN-scenario met internetverplaatsing via Azure Firewall moet u waarschijnlijk IPv6-connectiviteit op uw clientapparaat uitschakelen om verkeer naar de Virtual WAN-hub af te dwingen. Dit komt doordat moderne apparaten standaard IPv6-adressen gebruiken.

Wat is de aanbevolen API-versie die door scripts moet worden gebruikt om verschillende Virtual WAN-functionaliteit te automatiseren?

Er is minimaal de versie van 05-01-2020 (1 mei 2020) vereist.

Zijn er limieten voor Virtual WAN van toepassing?

Raadpleeg het gedeelte Limieten voor Virtual WAN op de pagina Abonnements- en servicebeperkingen.

Wat zijn de verschillen tussen de Virtual WAN-typen (Basic en Standard)?

Zie Virtual WAN's: Basic en Standard. Zie de pagina Prijzen voor prijsopgaven.

Slaat Virtual WAN klantgegevens op?

Nee. Virtual WAN slaat geen klantgegevens op.

Zijn er Managed Service Providers die Virtual WAN voor gebruikers kunnen beheren als een service?

Ja. Raadpleeg Azure Marketplace-aanbiedingen van Azure-netwerken MSP-partners voor een lijst met MSP-oplossingen (Managed Service Provider) die beschikbaar zijn via Azure Marketplace.

Hoe verschilt Virtual WAN hubroutering van Azure Route Server in een VNet?

Azure Route Server biedt een Border Gateway Protocol (BGP)-peeringservice die kan worden gebruikt door NNA's (virtueel netwerkapparaat) om routes te leren van de routeserver in een DOEI-hub-VNet. Virtual WAN-routering biedt meerdere mogelijkheden, waaronder VNet-naar-VNet-transitroutering, aangepaste routering, aangepaste routekoppeling en doorsturen, en een zero-touch volledig meshed hub-service samen met connectiviteitsservices van ExpressRoute, Site VPN, P2S VPN op afstand/grootschalige P2S-VPN en beveiligde hub (Azure Firewall). Wanneer u een BGP-peering tot stand brengen tussen uw NVA en Azure Route Server, kunt u IP-adressen van uw NVA adverteren naar uw virtuele netwerk. Voor alle geavanceerde routeringsmogelijkheden, zoals transitroutering, aangepaste routering, enzovoort, kunt u Virtual WAN gebruiken.

Als ik een externe beveiligingsprovider (Zscaler, iBoss of Checkpoint) gebruik om mijn internetverkeer te beveiligen, waarom zie ik dan niet de VPN-site die is gekoppeld aan de externe beveiligingsprovider in de Azure Portal?

Wanneer u ervoor kiest om een beveiligingspartnerprovider te implementeren om internettoegang voor uw gebruikers te beveiligen, maakt de externe beveiligingsprovider namens u een VPN-site. Omdat de externe beveiligingsprovider automatisch wordt gemaakt door de provider en geen door de gebruiker gemaakte VPN-site is, wordt deze VPN-site niet in de Azure Portal.

Zie Deploy a security partner provider (Een beveiligingspartnerprovider implementeren) voor meer informatie over de beschikbare opties van externe beveiligingsproviders en hoe u dit in kunt stellen.

Volgende stappen

• Zie Over Virtual WAN voor meer informatie over Virtual WAN.