Veelgestelde vragen over virtuele Azure-netwerken (FAQ)

Basisbeginselen van Virtual Network

Wat is een Azure Virtual Network (VNet)?

Een Azure Virtual Network (VNet) is een weergave van uw eigen netwerk in de cloud. Het is een logische isolatie van de Azure-cloud die is toegewezen aan uw abonnement. U kunt VNets gebruiken voor het inrichten en beheren van virtuele particuliere netwerken (VPN's) in Azure en, optioneel, de VNets koppelen aan andere VNets in Azure of aan uw on-premises IT-infrastructuur om hybride of cross-premises oplossingen te maken. Elk VNet dat u maakt, heeft een eigen CIDR-blok en kan worden gekoppeld aan andere VNets en on-premises netwerken zolang de CIDR-blokken elkaar niet overlappen. U hebt ook controle over de DNS-serverinstellingen voor VNets en de segmentatie van het VNet in subnetten.

Gebruik VNets voor het volgende:

  • Maak een toegewezen VNet in de privécloud. Soms hebt u geen cross-premises configuratie nodig voor uw oplossing. Wanneer u een VNet maakt, kunnen uw services en VM's binnen uw VNet rechtstreeks en veilig met elkaar communiceren in de cloud. Als onderdeel van uw oplossing kunt u nog steeds eindpuntverbindingen configureren voor de VM's en services waarvoor internetcommunicatie is vereist.

  • Breid uw datacentrum veilig uit. Met VNets kunt u traditionele site-naar-site -VPN's (S2S) bouwen om de capaciteit van uw datacenter veilig te schalen. S2S VPN's gebruiken IPSEC om een beveiligde verbinding te bieden tussen uw zakelijke VPN-gateway en Azure.

  • Hybride cloudscenario's inschakelen. VNets bieden u de flexibiliteit om een reeks hybride cloudscenario's te ondersteunen. U kunt cloudtoepassingen veilig verbinden met elk type on-premises systeem, zoals mainframes en Unix-systemen.

Hoe ga ik aan de slag?

Ga naar de documentatie voor virtueel netwerk om aan de slag te gaan. Deze inhoud biedt overzichts- en implementatie-informatie voor alle VNet-functies.

Kan ik VNets gebruiken zonder cross-premises connectiviteit?

Ja. U kunt een VNet gebruiken zonder het te verbinden met uw locatie. U kunt bijvoorbeeld Microsoft Windows Server Active Directory domeincontrollers en SharePoint-farms alleen in een Azure-VNet uitvoeren.

Kan ik WAN-optimalisatie uitvoeren tussen VNets of een VNet en mijn on-premises datacentrum?

Ja. U kunt een virtueel WAN-optimalisatienetwerkapparaat van verschillende leveranciers implementeren via de Azure Marketplace.

Configuratie

Welke hulpprogramma's gebruik ik om een VNet te maken?

U kunt de volgende hulpprogramma's gebruiken om een VNet te maken of te configureren:

Welke adresbereiken kan ik gebruiken in mijn VNets?

We raden u aan de adresbereiken te gebruiken die zijn opgesomd in RFC 1918, die door de IETF zijn gereserveerd voor privéadresruimten, niet-routeerbaar:

  • 10.0.0.0 - 10.255.255.255 (voorvoegsel 10/8)
  • 172.16.0.0 - 172.31.255.255 (voorvoegsel 172.16/12)
  • 192.168.0.0 - 192.168.255.255 (voorvoegsel 192.168/16)

U kunt ook de gedeelde adresruimte implementeren die is gereserveerd in RFC 6598, die wordt behandeld als privé-IP-adresruimte in Azure:

  • 100.64.0.0 - 100.127.255.255 (voorvoegsel 100.64/10)

Andere adresruimten, waaronder alle andere door IETF herkende privé-, niet-routeerbare adresruimten, kunnen werken, maar kunnen ongewenste bijwerkingen hebben.

Bovendien kunt u de volgende adresbereiken niet toevoegen:

  • 224.0.0.0/4 (Multicast)
  • 255.255.255.255/32 (Uitzending)
  • 127.0.0.0/8 (Loopback)
  • 169.254.0.0/16 (Link-local)
  • 168.63.129.16/32 (interne DNS)

Kan ik openbare IP-adressen in mijn VNets hebben?

Ja. Zie Een virtueel netwerk maken voor meer informatie over openbare IP-adresbereiken. Openbare IP-adressen zijn niet rechtstreeks toegankelijk via internet.

Is er een limiet voor het aantal subnetten in mijn VNet?

Ja. Zie Azure-limieten voor meer informatie. Subnetadresruimten mogen elkaar niet overlappen.

Zijn er beperkingen voor het gebruik van IP-adressen in deze subnetten?

Ja. Azure reserveert de eerste vier en laatste IP-adres voor een totaal van 5 IP-adressen binnen elk subnet.

Het IP-adresbereik 192.168.1.0/24 heeft bijvoorbeeld de volgende gereserveerde adressen:

  • 192.168.1.0 : Netwerkadres
  • 192.168.1.1 : Gereserveerd door Azure voor de standaardgateway
  • 192.168.1.2, 192.168.1.3 : Gereserveerd door Azure om de Azure DNS-IP's toe te wijzen aan de VNet-ruimte
  • 192.168.1.255 : Netwerkuitzendingsadres.

Hoe klein en hoe groot mogen VNet's en subnetten zijn?

Het kleinste ondersteunde IPv4-subnet is /29 en het grootste is /2 (met behulp van CIDR-subnetdefinities). IPv6-subnetten moeten exact /64 groot zijn.

Kan ik mijn VLAN's naar Azure brengen met behulp van VNets?

Nee. VNets zijn laag-3-overlays. Azure biedt geen ondersteuning voor layer-2-semantiek.

Kan ik aangepast routeringsbeleid opgeven voor mijn VNets en subnetten?

Ja. U kunt een routetabel maken en deze koppelen aan een subnet. Zie Overzicht van routering voor meer informatie over routering in Azure.

Wat zou het gedrag zijn wanneer ik zowel NSG als UDR op het subnet toepast?

Voor binnenkomend verkeer worden NSG-regels voor binnenkomend verkeer verwerkt. Voor uitgaand verkeer worden NSG-regels voor uitgaand verkeer verwerkt, gevolgd door UDR-regels.

Wat zou het gedrag zijn wanneer ik NSG op NIC en subnet voor een VM toepast?

Wanneer NSG's beide worden toegepast op NIC-subnetten & voor een VM, wordt NSG op subnetniveau gevolgd door NSG op NIC-niveau verwerkt voor NSG op inkomend en NIC-niveau, gevolgd door NSG op subnetniveau voor uitgaand verkeer.

Ondersteunen VNets multicast of broadcast?

Nee. Multicast en broadcast worden niet ondersteund.

Welke protocollen kan ik gebruiken in VNets?

U kunt TCP-, UDP- en ICMP TCP/IP-protocollen gebruiken in VNets. Unicast wordt ondersteund in VNets. Multicast-, broadcast-, IP-in-IP-ingekapselde pakketten en GRE-pakketten (General Routing Encapsulation) worden geblokkeerd in VNets. U kunt dhcp (Dynamic Host Configuration Protocol) niet gebruiken via Unicast (bronpoort UDP/68/doelpoort UDP/67). UDP-bronpoort 65330 die is gereserveerd voor de host. Zie 'Kan ik een DHCP-server in een VNet implementeren' voor meer informatie over wat wel en niet wordt ondersteund voor DHCP.

Kan ik een DHCP-server implementeren in een VNet?

Azure VNets bieden DHCP-service en DNS voor VM's en client/server DHCP (bronpoort UDP/68, doelpoort UDP/67) die niet worden ondersteund in een VNet. U kunt uw eigen DHCP-service niet implementeren om DHCP-verkeer voor unicast/broadcastclient/server te ontvangen en te leveren. U kunt een DHCP-server implementeren op een VM met de bedoeling dhcp-verkeer (bronpoort UDP/67, doelpoort UDP/67) DHCP-verkeer te ontvangen. Een mogelijk scenario is het configureren van DHCP-relay van on-premises apparaten naar een Azure-VM waarop een DHCP-server wordt uitgevoerd. De klant is verantwoordelijk voor het configureren van on-premises apparaten (bijvoorbeeld routerconfiguratie) om dit DHCP-relayverkeer te maken naar het IP-adres van de VM in Azure.

Kan ik de standaardgateway pingen binnen een VNet?

Nee. De door Azure geleverde standaardgateway reageert niet op ping. Maar u kunt pingen in uw VNets gebruiken om de connectiviteit en probleemoplossing tussen VM's te controleren.

Kan ik tracert gebruiken om connectiviteit te diagnosticeren?

Ja.

Kan ik subnetten toevoegen nadat het VNet is gemaakt?

Ja. Subnetten kunnen op elk gewenst moment worden toegevoegd aan VNets, zolang het subnetadresbereik geen deel uitmaakt van een ander subnet en er nog beschikbare ruimte over is in het adresbereik van het virtuele netwerk.

Kan ik de grootte van mijn subnet wijzigen nadat ik het heb gemaakt?

Ja. U kunt een subnet toevoegen, verwijderen, uitbreiden of verkleinen als hierin geen VM's of services zijn geïmplementeerd.

Kan ik het Vnet wijzigen nadat ik ze heb gemaakt?

Ja. U kunt de CIDR-blokken die door een VNet worden gebruikt toevoegen, verwijderen en wijzigen.

Kan ik verbinding maken met internet als ik mijn services in een VNet gebruik?

Ja. Alle services die binnen een VNet zijn geïmplementeerd, kunnen uitgaand verbinding maken met internet. Zie Uitgaande verbindingen voor meer informatie over uitgaande internetverbindingen in Azure. Als u inkomend wilt verbinden met een resource die is geïmplementeerd via Resource Manager, moet aan de resource een openbaar IP-adres zijn toegewezen. Zie Openbare IP-adressen voor meer informatie over openbare IP-adressen. Aan elke Azure-cloudservice die in Azure is geïmplementeerd, is een openbaar adresseerbaar VIP toegewezen. U definieert invoereindpunten voor PaaS-rollen en -eindpunten voor virtuele machines, zodat deze services verbindingen van internet kunnen accepteren.

Ondersteunen VNets IPv6?

Ja, VNets kunnen alleen IPv4 of dual stack (IPv4+IPv6) zijn. Zie Overzicht van IPv6 voor Azure Virtual Networks voor meer informatie.

Kan een VNet regio's omvatten?

Nee. Een VNet is beperkt tot één regio. Een virtueel netwerk omvat echter wel beschikbaarheidszones. Zie Overzicht van beschikbaarheidszones voor meer informatie over beschikbaarheidszones. U kunt virtuele netwerken in verschillende regio's verbinden met peering voor virtuele netwerken. Zie Overzicht van peering voor virtuele netwerken voor meer informatie

Kan ik een VNet verbinden met een ander VNet in Azure?

Ja. U kunt het ene VNet verbinden met een ander VNet met behulp van een van de volgende opties:

Naamomzetting (DNS)

Wat zijn mijn DNS-opties voor VNets?

Gebruik de beslissingstabel op de pagina Naamomzetting voor VM's en rolinstanties om u door alle beschikbare DNS-opties te leiden.

Kan ik DNS-servers opgeven voor een VNet?

Ja. U kunt IP-adressen van de DNS-server opgeven in de VNet-instellingen. De instelling wordt toegepast als de standaard-DNS-server(s) voor alle VM's in het VNet.

Hoeveel DNS-servers kan ik opgeven?

Verwijs naar Azure-limieten.

Kan ik mijn DNS-servers wijzigen nadat ik het netwerk heb gemaakt?

Ja. U kunt de lijst met DNS-servers voor uw VNet op elk gewenst moment wijzigen. Als u de lijst met DNS-servers wijzigt, moet u een DHCP-leaseverlenging uitvoeren op alle betrokken VM's in het VNet, zodat de nieuwe DNS-instellingen van kracht worden. Voor VM's met het Windows-besturingssysteem kunt u dit doen door rechtstreeks op de VM te typen ipconfig /renew . Raadpleeg de documentatie voor het verlengen van dhcp-leases voor het specifieke type besturingssysteem voor andere typen besturingssystemen.

Wat is door Azure geleverde DNS en werkt het met VNets?

Door Azure geleverde DNS is een DNS-service met meerdere tenants die wordt aangeboden door Microsoft. Azure registreert al uw VM's en exemplaren van cloudservicerollen in deze service. Deze service biedt naamomzetting op hostnaam voor VM's en rolinstanties in dezelfde cloudservice en op FQDN voor VM's en rolinstanties in hetzelfde VNet. Zie Naamomzetting voor VM's en Cloud Services rolinstanties voor meer informatie over DNS.

Er is een beperking voor de eerste 100 cloudservices in een VNet voor naamomzetting tussen tenants met behulp van door Azure geleverde DNS. Als u uw eigen DNS-server gebruikt, is deze beperking niet van toepassing.

Kan ik mijn DNS-instellingen per VM of cloudservice overschrijven?

Ja. U kunt DNS-servers per VM of cloudservice zo instellen dat de standaardnetwerkinstellingen worden overschreven. Het is echter raadzaam om dns voor het hele netwerk zoveel mogelijk te gebruiken.

Kan ik mijn eigen DNS-achtervoegsel meenemen?

Nee. U kunt geen aangepast DNS-achtervoegsel opgeven voor uw VNets.

Virtuele machines verbinden

Kan ik VM's implementeren in een VNet?

Ja. Alle netwerkinterfaces (NIC) die zijn gekoppeld aan een VM die is geïmplementeerd via het Resource Manager-implementatiemodel, moeten zijn verbonden met een VNet. VM's die zijn geïmplementeerd via het klassieke implementatiemodel, kunnen optioneel worden verbonden met een VNet.

Wat zijn de verschillende typen IP-adressen die ik aan VM's kan toewijzen?

  • Privé: Toegewezen aan elke NIC binnen elke VM. Het adres wordt toegewezen met behulp van de statische of dynamische methode. Privé-IP-adressen worden toegewezen uit het bereik dat u hebt opgegeven in de subnetinstellingen van uw VNet. Resources die zijn geïmplementeerd via het klassieke implementatiemodel, krijgen privé-IP-adressen toegewezen, zelfs als ze niet zijn verbonden met een VNet. Het gedrag van de toewijzingsmethode verschilt, afhankelijk van of een resource is geïmplementeerd met het Resource Manager- of klassieke implementatiemodel:

    • Resource Manager: een privé-IP-adres dat is toegewezen met de dynamische of statische methode blijft toegewezen aan een virtuele machine (Resource Manager) totdat de resource wordt verwijderd. Het verschil is dat u het adres selecteert dat u wilt toewijzen wanneer u statisch gebruikt en Azure kiest bij het gebruik van dynamisch.
    • Klassiek: een privé-IP-adres dat is toegewezen met de dynamische methode, kan worden gewijzigd wanneer een virtuele machine (klassiek) opnieuw wordt opgestart nadat deze de status Gestopt (toewijzing opgeheven) heeft. Als u ervoor wilt zorgen dat het privé-IP-adres voor een resource die is geïmplementeerd via het klassieke implementatiemodel nooit verandert, wijst u een privé-IP-adres toe met de statische methode.
  • Openbare: Optioneel toegewezen aan NIC's die zijn gekoppeld aan VM's die zijn geïmplementeerd via het Azure Resource Manager-implementatiemodel. Het adres kan worden toegewezen met de statische of dynamische toewijzingsmethode. Alle VM's en Cloud Services rolinstanties die zijn geïmplementeerd via het klassieke implementatiemodel, bestaan in een cloudservice, waaraan een dynamisch, openbaar VIP-adres (virtueel IP)-adres is toegewezen. Een openbaar statisch IP-adres, een gereserveerd IP-adres genoemd, kan optioneel als VIP worden toegewezen. U kunt openbare IP-adressen toewijzen aan afzonderlijke VM's of Cloud Services rolinstanties die zijn geïmplementeerd via het klassieke implementatiemodel. Deze adressen worden ILPIP-adressen (Public IP) op exemplaarniveau genoemd en kunnen dynamisch worden toegewezen.

Kan ik een privé-IP-adres reserveren voor een VM die ik later ga maken?

Nee. U kunt geen privé-IP-adres reserveren. Als er een privé-IP-adres beschikbaar is, wordt dit door de DHCP-server toegewezen aan een VM of een rolinstantie. De VM kan wel of niet de vm zijn waaraan u het privé-IP-adres wilt toewijzen. U kunt echter het privé-IP-adres van een reeds gemaakte VM wijzigen in elk beschikbaar privé-IP-adres.

Veranderen privé-IP-adressen voor VM's in een VNet?

Dat hangt ervan af. Als de VM is geïmplementeerd via Resource Manager, nee, ongeacht of het IP-adres is toegewezen met de statische of dynamische toewijzingsmethode. Als de VM is geïmplementeerd via het klassieke implementatiemodel, kunnen dynamische IP-adressen veranderen wanneer een VM wordt gestart nadat ze de status Gestopt (toewijzing opgeheven) hebben. Het adres wordt vrijgegeven van een VM die is geïmplementeerd via een van beide implementatiemodellen wanneer de VM wordt verwijderd.

Kan ik handmatig IP-adressen toewijzen aan NIC's binnen het VM-besturingssysteem?

Ja, maar dit wordt niet aanbevolen, tenzij dit nodig is, bijvoorbeeld bij het toewijzen van meerdere IP-adressen aan een virtuele machine. Zie Meerdere IP-adressen toevoegen aan een virtuele machine voor meer informatie. Als het IP-adres dat is toegewezen aan een Azure-NIC die is gekoppeld aan een VM verandert en het IP-adres in het VM-besturingssysteem anders is, verliest u de verbinding met de VM.

Wat gebeurt er met mijn IP-adressen als ik een cloudservice-implementatiesite stop of een VM vanuit het besturingssysteem afsluit?

Niets. De IP-adressen (openbaar VIP, openbaar en privé) blijven toegewezen aan de implementatiesite of VM van de cloudservice.

Kan ik VM's van het ene subnet naar het andere subnet in een VNet verplaatsen zonder opnieuw te implementeren?

Ja. Meer informatie vindt u in het artikel Een VM of rolinstantie verplaatsen naar een ander subnet .

Kan ik een statisch MAC-adres voor mijn VM configureren?

Nee. Een MAC-adres kan niet statisch worden geconfigureerd.

Blijft het MAC-adres hetzelfde voor mijn VM nadat deze is gemaakt?

Ja, het MAC-adres blijft hetzelfde voor een VM die is geïmplementeerd via zowel het Resource Manager- als het klassieke implementatiemodel totdat het wordt verwijderd. Voorheen werd het MAC-adres vrijgegeven als de VM was gestopt (de toewijzing ongedaan gemaakt), maar nu blijft het MAC-adres behouden, zelfs wanneer de VM de status Ongedaan gemaakt heeft. Het MAC-adres blijft toegewezen aan de netwerkinterface totdat de netwerkinterface wordt verwijderd of het privé-IP-adres dat is toegewezen aan de primaire IP-configuratie van de primaire netwerkinterface wordt gewijzigd.

Kan ik verbinding maken met internet vanaf een VM in een VNet?

Ja. Alle VM's en Cloud Services rolinstanties die binnen een VNet zijn geïmplementeerd, kunnen verbinding maken met internet.

Azure-services die verbinding maken met VNets

Kan ik Azure App Service Web Apps gebruiken met een VNet?

Ja. U kunt Web Apps in een VNet implementeren met behulp van een ASE (App Service Environment), de back-end van uw apps verbinden met uw VNets met VNet-integratie en binnenkomend verkeer naar uw app vergrendelen met service-eindpunten. Raadpleeg voor meer informatie de volgende artikelen:

Kan ik Cloud Services met web- en werkrollen (PaaS) implementeren in een VNet?

Ja. U kunt (optioneel) Cloud Services rolinstanties in VNets implementeren. Hiervoor geeft u de naam van het VNet en de rol-/subnettoewijzingen op in de sectie netwerkconfiguratie van uw serviceconfiguratie. U hoeft geen van uw binaire bestanden bij te werken.

Kan ik een virtuele-machineschaalset verbinden met een VNet?

Ja. U moet een virtuele-machineschaalset verbinden met een VNet.

Is er een volledige lijst met Azure-services waarmee ik resources in een VNet kan implementeren?

Ja, Zie Integratie van virtuele netwerken voor Azure-services voor meer informatie.

Hoe kan ik de toegang tot Azure PaaS-resources vanuit een VNet beperken?

Resources die zijn geïmplementeerd via sommige Azure PaaS-services (zoals Azure Storage en Azure SQL Database), kunnen de netwerktoegang tot VNet beperken door het gebruik van service-eindpunten voor virtuele netwerken of Azure Private Link. Zie Overzicht van service-eindpunten voor virtuelenetwerken Azure Private Link overzicht voor meer informatie

Kan ik mijn services in en uit VNets verplaatsen?

Nee. U kunt geen services van en naar VNets verplaatsen. Als u een resource naar een ander VNet wilt verplaatsen, moet u de resource verwijderen en opnieuw implementeren.

Beveiliging

Wat is het beveiligingsmodel voor VNets?

VNets zijn geïsoleerd van elkaar en andere services die worden gehost in de Azure-infrastructuur. Een VNet is een vertrouwensgrens.

Kan ik de binnenkomende of uitgaande verkeersstroom naar met VNet verbonden resources beperken?

Ja. U kunt netwerkbeveiligingsgroepen toepassen op afzonderlijke subnetten binnen een VNet, NIC's die zijn gekoppeld aan een VNet of beide.

Kan ik een firewall implementeren tussen met VNet verbonden resources?

Ja. U kunt een virtueel firewallnetwerkapparaat van verschillende leveranciers implementeren via de Azure Marketplace.

Is er informatie beschikbaar over het beveiligen van VNets?

Ja. Zie Overzicht van Azure-netwerkbeveiliging voor meer informatie.

Slaan virtuele netwerken klantgegevens op?

Nee. Virtual Networks slaat geen klantgegevens op.

Kan ik de eigenschap FlowTimeoutInMinutes instellen voor een volledig abonnement?

Nee. Dit moet worden ingesteld op het virtuele netwerk. Het volgende kan helpen bij het automatiseren van het instellen van deze eigenschap voor grotere abonnementen:

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be between 4 and 30 minutes (inclusive) to enable tracking, or null to disable tracking. $null to disable. 
ForEach ($vnet in $Allvnet)
{
    $vnet.FlowTimeoutInMinutes = $time
    $vnet | Set-AzVirtualNetwork
}

API's, schema's en hulpprogramma's

Kan ik VNets beheren vanuit code?

Ja. U kunt REST API's voor VNets gebruiken in de Azure Resource Manager en klassieke implementatiemodellen.

Is er ondersteuning voor hulpprogramma's voor VNets?

Ja. Meer informatie over het gebruik van:

VNet-peering

Wat is VNet-peering?

Met VNet-peering (of peering van virtuele netwerken) kunt u virtuele netwerken verbinden. Met een VNet-peeringverbinding tussen virtuele netwerken kunt u verkeer tussen virtuele netwerken privé routeren via IPv4-adressen. Virtuele machines in de gekoppelde VNets kunnen met elkaar communiceren alsof ze zich binnen hetzelfde netwerk bevinden. Deze virtuele netwerken kunnen zich in dezelfde regio of in verschillende regio's bevinden (ook wel globale VNet-peering genoemd). VNet-peeringverbindingen kunnen ook worden gemaakt tussen Azure-abonnementen.

Kan ik een peeringverbinding maken met een VNet in een andere regio?

Ja. Met globale VNet-peering kunt u VNet's in verschillende regio's koppelen. Wereldwijde VNet-peering is beschikbaar in alle openbare Azure-regio's, china-cloudregio's en cloudregio's voor de overheid. U kunt niet globaal peeren van openbare Azure-regio's naar nationale cloudregio's.

Als de twee virtuele netwerken in twee verschillende regio's zijn gekoppeld via globale VNet-peering, kunt u geen verbinding maken met resources die zich achter een Basic-Load Balancer bevinden via het front-end-IP-adres van de Load Balancer. Deze beperking bestaat niet voor een Standard Load Balancer. De volgende resources kunnen gebruikmaken van Basic Load Balancers, wat betekent dat u ze niet kunt bereiken via het front-end-IP-adres van de Load Balancer via globale VNet-peering. U kunt echter globale VNet-peering gebruiken om de resources rechtstreeks te bereiken via hun privé-VNet-IP-adressen, indien toegestaan.

  • VM's achter Basic Load Balancers
  • Virtuele-machineschaalsets met Basic Load Balancers
  • Redis Cache
  • Application Gateway (v1) SKU
  • Service Fabric
  • API Management (stv1)
  • Active Directory-domein Service (ADDS)
  • Logic Apps
  • HDInsight
  • Azure Batch
  • App Service-omgeving

U kunt verbinding maken met deze resources via ExpressRoute of VNet-naar-VNet via VNet-gateways.

Kan ik VNet-peering inschakelen als mijn virtuele netwerken deel uitmaken van abonnementen binnen verschillende Azure Active Directory-tenants?

Ja. Het is mogelijk om VNet-peering (lokaal of globaal) tot stand te brengen als uw abonnementen deel uitmaken van verschillende Azure Active Directory-tenants. U kunt dit doen via portal, PowerShell of CLI.

Mijn VNet-peeringverbinding heeft de status Gestart . Waarom kan ik geen verbinding maken?

Als uw peeringverbinding de status Gestart heeft, betekent dit dat u slechts één koppeling hebt gemaakt. Er moet een koppeling in twee richtingen worden gemaakt om een verbinding tot stand te brengen. Als u VNet A bijvoorbeeld wilt koppelen aan VNet B, moet er een koppeling worden gemaakt van VNetA naar VNetB en van VNetB naar VNetA. Als u beide koppelingen maakt, wordt de status gewijzigd in Verbonden.

Mijn VNet-peeringverbinding heeft de status Verbroken . Waarom kan ik geen peeringverbinding maken?

Als uw VNet-peeringverbinding de status Verbroken heeft, betekent dit dat een van de gemaakte koppelingen is verwijderd. Als u een peeringverbinding wilt herstellen, moet u de koppeling verwijderen en opnieuw maken.

Kan ik mijn VNet peeren met een VNet in een ander abonnement?

Ja. U kunt VNets peeren tussen abonnementen en regio's.

Kan ik twee VNets peeren met overeenkomende of overlappende adresbereiken?

Nee. Adresruimten mogen elkaar niet overlappen om VNet-peering in te schakelen.

Kan ik een VNet koppelen aan twee verschillende VNets met de optie Externe gateway gebruiken ingeschakeld voor beide peerings?

Nee. U kunt de optie 'Externe gateway gebruiken' alleen inschakelen voor één peering met een van de VNets.

Er worden geen kosten in rekening gebracht voor het maken van een VNet-peeringverbinding. Er worden kosten in rekening gebracht voor gegevensoverdracht tussen peeringverbindingen. Kijk hier.

Is verkeer van VNet-peering versleuteld?

Wanneer Azure-verkeer wordt verplaatst tussen datacenters (buiten fysieke grenzen die niet worden beheerd door Microsoft of namens Microsoft), wordt MACsec-gegevenskoppelingslaagversleuteling gebruikt op de onderliggende netwerkhardware. Dit is van toepassing op VNet-peeringverkeer.

Waarom heeft mijn peeringverbinding de status Verbroken ?

VNet-peeringverbindingen krijgen de status Verbroken wanneer één VNet-peeringkoppeling wordt verwijderd. U moet beide koppelingen verwijderen om een geslaagde peeringverbinding tot stand te brengen.

Als ik VNetA peer met VNetB en VNetB peer met VNetC, betekent dit dan dat VNetA en VNetC peering hebben?

Nee. Transitieve peering wordt niet ondersteund. U moet VNetA en VNetC peeren om dit te laten plaatsvinden.

Gelden er bandbreedtebeperkingen voor peeringverbindingen?

Nee. VNet-peering, lokaal of globaal, legt geen bandbreedtebeperkingen op. Bandbreedte wordt alleen beperkt door de VM of de rekenresource.

Hoe kan ik problemen met VNet-peering oplossen?

Hier volgt een probleemoplosser die u kunt proberen.

Virtual Network TAP

Welke Azure-regio's zijn beschikbaar voor TAP voor virtuele netwerken?

Tap preview van virtueel netwerk is beschikbaar in alle Azure-regio's. De bewaakte netwerkinterfaces, de TAP-resource van het virtuele netwerk en de collector- of analyseoplossing moeten in dezelfde regio worden geïmplementeerd.

Ondersteunt Virtual Network TAP filtermogelijkheden voor de gespiegelde pakketten?

Filtermogelijkheden worden niet ondersteund met de TAP-preview van het virtuele netwerk. Wanneer een TAP-configuratie wordt toegevoegd aan een netwerkinterface, wordt een diepe kopie van al het inkomend en uitgaand verkeer op de netwerkinterface gestreamd naar de TAP-bestemming.

Kunnen meerdere TAP-configuraties worden toegevoegd aan een bewaakte netwerkinterface?

Een bewaakte netwerkinterface kan slechts één TAP-configuratie hebben. Neem contact op met de afzonderlijke partneroplossing voor de mogelijkheid om meerdere kopieën van het TAP-verkeer te streamen naar de analysehulpprogramma's van uw keuze.

Kan hetzelfde virtuele netwerk TAP-resource verkeer van bewaakte netwerkinterfaces in meer dan één virtueel netwerk aggregeren?

Ja. Dezelfde TAP-resource voor het virtuele netwerk kan worden gebruikt om gespiegeld verkeer van bewaakte netwerkinterfaces in gekoppelde virtuele netwerken in hetzelfde abonnement of een ander abonnement te aggregeren. De TAP-resource van het virtuele netwerk en de doel load balancer of doelnetwerkinterface moeten zich in hetzelfde abonnement bevinden. Alle abonnementen moeten zich onder dezelfde Azure Active Directory-tenant bevinden.

Zijn er prestatieoverwegingen met betrekking tot productieverkeer als ik een TAP-configuratie van een virtueel netwerk inschakelen op een netwerkinterface?

Virtueel netwerk TAP is in preview. Tijdens de preview is er geen service level agreement. De mogelijkheid mag niet worden gebruikt voor productieworkloads. Wanneer een netwerkinterface van een virtuele machine is ingeschakeld met een TAP-configuratie, worden dezelfde resources op de Azure-host die aan de virtuele machine zijn toegewezen om het productieverkeer te verzenden, gebruikt om de spiegelingsfunctie uit te voeren en de gespiegelde pakketten te verzenden. Selecteer de juiste grootte van virtuele Linux - of Windows-machines om ervoor te zorgen dat er voldoende resources beschikbaar zijn voor de virtuele machine om het productieverkeer en het gespiegelde verkeer te verzenden.

Wordt versneld netwerken voor Linux of Windows ondersteund met TAP voor virtuele netwerken?

U kunt een TAP-configuratie toevoegen op een netwerkinterface die is gekoppeld aan een virtuele machine die is ingeschakeld met versneld netwerken. Maar de prestaties en latentie op de virtuele machine worden beïnvloed door het toevoegen van TAP-configuratie, omdat de offload voor het spiegelingsverkeer momenteel niet wordt ondersteund door versnelde netwerken van Azure.

Service-eindpunten voor virtueel netwerk

Wat is de juiste reeks bewerkingen voor het instellen van service-eindpunten voor een Azure-service?

Er zijn twee stappen om een Azure-serviceresource te beveiligen via service-eindpunten:

  1. Schakel service-eindpunten in voor de Azure-service.
  2. Stel VNet-ACL's in op de Azure-service.

De eerste stap is een bewerking aan de netwerkzijde en de tweede stap is een bewerking aan de serviceresourcezijde. Beide stappen kunnen worden uitgevoerd door dezelfde beheerder of verschillende beheerders op basis van de Azure RBAC-machtigingen die zijn verleend aan de beheerdersrol. We raden u aan om eerst service-eindpunten in te schakelen voor uw virtuele netwerk voordat u VNet-ACL's aan de Azure-servicezijde instelt. Daarom moeten de stappen worden uitgevoerd in de bovenstaande volgorde om VNet-service-eindpunten in te stellen.

Notitie

Beide hierboven beschreven bewerkingen moeten worden voltooid voordat u de toegang tot de Azure-service kunt beperken tot het toegestane VNet en subnet. Alleen het inschakelen van service-eindpunten voor de Azure-service aan de netwerkzijde biedt u geen beperkte toegang. Daarnaast moet u ook VNet-ACL's instellen aan de azure-servicezijde.

Bepaalde services (zoals Azure SQL en Azure Cosmos DB) staan uitzonderingen op de bovenstaande volgorde toe via de IgnoreMissingVnetServiceEndpoint vlag. Zodra de vlag is ingesteld Trueop , kunnen VNet-ACL's worden ingesteld aan de Azure-servicezijde voordat de service-eindpunten aan de netwerkzijde worden ingesteld. Azure-services bieden deze vlag om klanten te helpen in gevallen waarin de specifieke IP-firewalls zijn geconfigureerd in Azure-services en het inschakelen van de service-eindpunten aan de netwerkzijde kan leiden tot een afname van de connectiviteit omdat het bron-IP-adres wordt gewijzigd van een openbaar IPv4-adres in een privéadres. Het instellen van VNet-ACL's aan de Azure-servicezijde voordat u service-eindpunten aan de netwerkzijde instelt, kan helpen voorkomen dat de connectiviteit wordt onderbroken.

Bevinden alle Azure-services zich in het virtuele Azure-netwerk dat door de klant wordt geleverd? Hoe werkt het VNet-service-eindpunt met Azure-services?

Nee, niet alle Azure-services bevinden zich in het virtuele netwerk van de klant. De meeste Azure-gegevensservices, zoals Azure Storage, Azure SQL en Azure Cosmos DB, zijn services met meerdere tenants die toegankelijk zijn via openbare IP-adressen. Meer informatie over de integratie van virtuele netwerken voor Azure-services vindt u hier.

Wanneer u de functie VNet-service-eindpunten gebruikt (het inschakelen van het VNet-service-eindpunt aan de netwerkzijde en het instellen van de juiste VNet-ACL's aan de Azure-servicezijde), wordt de toegang tot een Azure-service beperkt vanaf een toegestaan VNet en subnet.

Hoe biedt het VNet-service-eindpunt beveiliging?

De functie voor VNet-service-eindpunten (het inschakelen van het VNet-service-eindpunt aan de netwerkzijde en het instellen van de juiste VNet-ACL's aan de Azure-servicezijde) beperkt de azure-servicetoegang tot het toegestane VNet en subnet, waardoor beveiliging en isolatie van het Azure-serviceverkeer op netwerkniveau worden geboden. Al het verkeer dat gebruikmaakt van VNet-service-eindpunten, loopt via Microsoft backbone, waardoor er nog een isolatielaag van het openbare internet wordt geboden. Bovendien kunnen klanten ervoor kiezen om de openbare internettoegang tot de Azure-serviceresources volledig te verwijderen en alleen verkeer van hun virtuele netwerk toe te staan via een combinatie van IP-firewall en VNet-ACL's, waardoor de Azure-serviceresources worden beschermd tegen onbevoegde toegang.

Wat beveiligt het VNet-service-eindpunt - VNet-resources of Azure-service?

VNet-service-eindpunten helpen Azure-serviceresources te beveiligen. VNet-resources worden beveiligd via netwerkbeveiligingsgroepen (NSG's).

Zijn er kosten voor het gebruik van VNet-service-eindpunten?

Nee, er zijn geen extra kosten verbonden aan het gebruik van VNet-service-eindpunten.

Kan ik VNet-service-eindpunten inschakelen en VNet-ACL's instellen als het virtuele netwerk en de Azure-serviceresources deel uitmaken van verschillende abonnementen?

Ja, dat is mogelijk. Virtuele netwerken en Azure-serviceresources kunnen zich in hetzelfde abonnement of in verschillende abonnementen bevinden. De enige vereiste is dat zowel het virtuele netwerk als de Azure-serviceresources zich onder dezelfde Active Directory-tenant (AD) moeten bevinden.

Kan ik VNet-service-eindpunten inschakelen en VNet-ACL's instellen als het virtuele netwerk en de Azure-serviceresources tot verschillende AD-tenants behoren?

Ja, dit is mogelijk wanneer u service-eindpunten gebruikt voor Azure Storage en Azure Key Vault. Voor de rest van services worden VNet-service-eindpunten en VNet-ACL's niet ondersteund in AD-tenants.

Kan het IP-adres van een on-premises apparaat dat is verbonden via Azure Virtual Network Gateway (VPN) of ExpressRoute-gateway toegang krijgen tot Azure PaaS Service via VNet-service-eindpunten?

Standaard zijn Azure-serviceresources die zijn beveiligd naar virtuele netwerken, niet bereikbaar vanaf on-premises netwerken. Als u on-premises verkeer wilt toestaan, moet u ook openbare IP-adressen (meestal NAT) van uw on-premises of ExpressRoute toestaan. Deze IP-adressen kunnen worden toegevoegd via de IP-firewallconfiguratie voor de Azure-serviceresources.

Kan ik de functie VNet-service-eindpunt gebruiken om de Azure-service te beveiligen naar meerdere subnetten binnen een virtueel netwerk of in meerdere virtuele netwerken?

Als u Azure-services wilt beveiligen naar meerdere subnetten binnen een virtueel netwerk of in meerdere virtuele netwerken, schakelt u service-eindpunten aan de netwerkzijde op elk van de subnetten afzonderlijk in en beveiligt u vervolgens Azure-serviceresources naar alle subnetten door de juiste VNet-ACL's in te stellen aan de Azure-servicezijde.

Hoe kan ik uitgaand verkeer van een virtueel netwerk naar Azure-services filteren en toch service-eindpunten gebruiken?

Als u het verkeer dat is bestemd voor een Azure-service vanaf het virtuele netwerk, wilt controleren of filteren, kunt u een virtueel netwerkapparaat implementeren binnen het virtuele netwerk. U kunt vervolgens service-eindpunten toepassen op het subnet waar het virtuele netwerkapparaat is geïmplementeerd en Azure-serviceresources alleen op dit subnet beveiligen via VNet-ACL's. Dit scenario kan ook handig zijn als u de azure-servicetoegang van uw virtuele netwerk wilt beperken tot specifieke Azure-resources met behulp van het filteren van virtuele netwerkapparaten. Zie Egress with network virtual appliances (Uitgaand verkeer met virtueel-netwerkapparaten) voor meer informatie.

Wat gebeurt er wanneer u toegang krijgt tot een Azure-serviceaccount waarvoor een toegangsbeheerlijst voor virtuele netwerken (ACL) is ingeschakeld van buiten het VNet?

De HTTP 403- of HTTP 404-fout wordt geretourneerd.

Hebben subnetten van een virtueel netwerk die in verschillende regio's zijn gemaakt, toegang tot een Azure-serviceaccount in een andere regio?

Ja, voor de meeste Azure-services hebben virtuele netwerken die in verschillende regio's zijn gemaakt, toegang tot Azure-services in een andere regio via de VNet-service-eindpunten. Als een Azure Cosmos DB-account zich bijvoorbeeld in VS - west of VS - oost bevindt en virtuele netwerken zich in meerdere regio's bevinden, heeft het virtuele netwerk toegang tot Azure Cosmos DB. Opslag en SQL zijn uitzonderingen en zijn regionaal van aard en zowel het virtuele netwerk als de Azure-service moeten zich in dezelfde regio bevinden.

Kan een Azure-service zowel een VNet-ACL als een IP-firewall hebben?

Ja, een VNet-ACL en een IP-firewall kunnen naast elkaar bestaan. Beide functies vullen elkaar aan om isolatie en beveiliging te garanderen.

Wat gebeurt er als u een virtueel netwerk of subnet verwijdert waarvoor het service-eindpunt is ingeschakeld voor de Azure-service?

Het verwijderen van VNets en subnetten zijn onafhankelijke bewerkingen en worden zelfs ondersteund wanneer service-eindpunten zijn ingeschakeld voor Azure-services. In gevallen waarin voor de Azure-services VNet-ACL's zijn ingesteld, worden voor die VNets en subnetten de VNet-ACL-gegevens die zijn gekoppeld aan die Azure-service uitgeschakeld wanneer een VNet of subnet met VNet-service-eindpunt is ingeschakeld, wordt verwijderd.

Wat gebeurt er als een Azure-serviceaccount waarvoor een VNet Service-eindpunt is ingeschakeld, wordt verwijderd?

Het verwijderen van een Azure-serviceaccount is een onafhankelijke bewerking en wordt zelfs ondersteund wanneer het service-eindpunt is ingeschakeld aan de netwerkzijde en VNet-ACL's zijn ingesteld aan de Azure-servicezijde.

Wat gebeurt er met het bron-IP-adres van een resource (zoals een VM in een subnet) waarvoor het VNet-service-eindpunt is ingeschakeld?

Wanneer service-eindpunten voor virtuele netwerken zijn ingeschakeld, schakelen de bron-IP-adressen van de resources in het subnet van uw virtuele netwerk over van het gebruik van openbare IPV4-adressen naar de privé-IP-adressen van het virtuele Azure-netwerk voor verkeer naar de Azure-service. Houd er rekening mee dat dit ertoe kan leiden dat specifieke IP-firewalls die eerder op de Azure-services zijn ingesteld op een openbaar IPV4-adres, mislukken.

Heeft de route van het service-eindpunt altijd voorrang?

Service-eindpunten voegen een systeemroute toe die voorrang heeft op BGP-routes en een optimale routering biedt voor het service-eindpuntverkeer. Service-eindpunten brengen serviceverkeer altijd rechtstreeks van uw virtuele netwerk naar de service op het Microsoft Azure-backbonenetwerk. Zie Azure Virtual Network Traffic Routing voor meer informatie over hoe Azure een route selecteert.

Werken service-eindpunten met ICMP?

Nee, ICMP-verkeer dat afkomstig is van een subnet waarvoor service-eindpunten zijn ingeschakeld, leidt niet naar het servicetunnelpad naar het gewenste eindpunt. Service-eindpunten verwerken alleen TCP-verkeer. Dit betekent dat als u latentie of connectiviteit met een eindpunt wilt testen via service-eindpunten, hulpprogramma's zoals ping en tracert niet het werkelijke pad weergeven dat de resources in het subnet nemen.

Hoe werkt NSG in een subnet met service-eindpunten?

Om de Azure-service te bereiken, moeten NSG's uitgaande connectiviteit toestaan. Als uw NSG's zijn geopend voor al het uitgaande internetverkeer, moet het service-eindpuntverkeer werken. U kunt ook het uitgaande verkeer naar service-IP's beperken met behulp van de servicetags.

Welke machtigingen heb ik nodig om service-eindpunten in te stellen?

Service-eindpunten kunnen onafhankelijk in een virtueel netwerk worden geconfigureerd door een gebruiker met schrijftoegang tot het virtuele netwerk. Als u Azure-serviceresources naar een VNet wilt beveiligen, moet de gebruiker machtigingen hebben Microsoft. Network/virtualNetworks/subnets/joinViaServiceEndpoint/action voor de subnetten die worden toegevoegd. Deze machtiging is standaard opgenomen in de ingebouwde rol van servicebeheerder en kan worden gewijzigd door aangepaste rollen te maken. Meer informatie over ingebouwde rollen en het toewijzen van specifieke machtigingen voor aangepaste rollen.

Kan ik virtueel netwerkverkeer naar Azure-services filteren, zodat alleen specifieke Azure-serviceresources worden toegestaan via VNet-service-eindpunten?

Met beleid voor service-eindpunten voor virtuele netwerken (VNet) kunt u verkeer van virtuele netwerken naar Azure-services filteren, waardoor alleen specifieke Azure-serviceresources via de service-eindpunten worden toegestaan. Eindpuntbeleid biedt gedetailleerd toegangsbeheer van het verkeer van het virtuele netwerk naar de Azure-services. Meer informatie over het beleid voor service-eindpunten vindt u hier.

Ondersteunt Azure Active Directory (Azure AD) VNet-service-eindpunten?

Azure Active Directory (Azure AD) biedt geen systeemeigen ondersteuning voor service-eindpunten. De volledige lijst met Azure-services die VNet-service-eindpunten ondersteunen, vindt u hier. Merk op dat de 'Microsoft. De tag AzureActiveDirectory' die wordt vermeld onder services die service-eindpunten ondersteunen, wordt gebruikt voor het ondersteunen van service-eindpunten voor ADLS Gen 1. Voor ADLS Gen 1 maakt de integratie van virtuele netwerken voor Azure Data Lake Storage Gen1 gebruik van de beveiliging van het service-eindpunt van het virtuele netwerk tussen uw virtuele netwerk en Azure Active Directory (Azure AD) om aanvullende beveiligingsclaims in het toegangstoken te genereren. Deze claims worden vervolgens gebruikt om het virtuele netwerk te verifiëren bij het Data Lake Storage Gen1-account en toegang toe te staan. Meer informatie over VNet-integratie van Azure Data Lake Store Gen 1

Zijn er limieten voor het aantal VNet-service-eindpunten dat ik kan instellen vanuit mijn VNet?

Er is geen limiet voor het totale aantal VNet-service-eindpunten in een virtueel netwerk. Voor een Azure-serviceresource (zoals een Azure Storage-account) kunnen services limieten afdwingen voor het aantal subnetten dat wordt gebruikt voor het beveiligen van de resource. In de volgende tabel ziet u enkele voorbeeldlimieten:

Azure-service Limieten voor VNet-regels
Azure Storage 200
Azure SQL 128
Azure Synapse Analytics 128
Azure KeyVault 200
Azure Cosmos DB 64
Azure Event Hub 128
Azure Service Bus 128
Azure Data Lake Store V1 100

Notitie

De limieten worden naar goeddunken van de Azure-service gewijzigd. Raadpleeg de betreffende servicedocumentatie voor meer informatie over de services.

Klassieke netwerkresources migreren naar Resource Manager

Wat is Azure Service Manager en de term klassiek gemiddelde?

Azure Service Manager is het oude implementatiemodel van Azure dat verantwoordelijk is voor het maken, beheren en verwijderen van resources. Het woord klassiek in een netwerkservice verwijst naar resources die worden beheerd door het Azure Service Manager-model. Zie Vergelijking tussen implementatiemodellen voor meer informatie.

Wat is Azure Resource Manager?

Azure Resource Manager is het nieuwste implementatie- en beheermodel in Azure dat verantwoordelijk is voor het maken, beheren en verwijderen van resources in uw Azure-abonnement. Zie Wat is Azure Resource Manager? voor meer informatie.

Kan ik de migratie terugdraaien nadat resources zijn doorgevoerd naar Resource Manager?

U kunt de migratie annuleren zolang resources zich nog in de voorbereide status bevinden. Terugdraaien naar het vorige implementatiemodel wordt niet ondersteund nadat resources zijn gemigreerd via de doorvoerbewerking.

Kan ik de migratie herstellen als de doorvoerbewerking is mislukt?

U kunt een migratie niet ongedaan maken als de doorvoerbewerking is mislukt. Alle migratiebewerkingen, inclusief de doorvoerbewerking, kunnen niet worden gewijzigd nadat ze zijn gestart. Het is raadzaam om de bewerking na een korte periode opnieuw uit te voeren. Als de bewerking blijft mislukken, dient u een ondersteuningsaanvraag in.

Kan ik mijn abonnement of resources valideren om te ontdekken of ze geschikt zijn voor migratie?

Ja. Als onderdeel van de migratieprocedure bestaat de eerste stap bij het voorbereiden van de migratie uit het valideren of resources kunnen worden gemigreerd. Als de validatiebewerking mislukt, ontvangt u berichten om alle redenen waarom de migratie niet kan worden voltooid.

Worden Application Gateway resources gemigreerd als onderdeel van de klassieke naar Resource Manager VNet-migratie?

Application Gateway resources worden niet automatisch gemigreerd als onderdeel van het VNet-migratieproces. Als er een aanwezig is in het virtuele netwerk, wordt de migratie niet voltooid. Als u een Application Gateway resource naar Resource Manager wilt migreren, moet u de Application Gateway verwijderen en opnieuw maken zodra de migratie is voltooid.

Wordt de VPN Gateway gemigreerd als onderdeel van de klassieke naar Resource Manager VNet-migratie?

VPN Gateway resources worden gemigreerd als onderdeel van het VNet-migratieproces. De migratie wordt met één virtueel netwerk tegelijk voltooid zonder andere vereisten. De migratiestappen zijn hetzelfde als het migreren van een virtueel netwerk zonder een VPN-gateway.

Is er een serviceonderbreking gekoppeld aan het migreren van klassieke VPN-gateways naar Resource Manager?

U ondervindt geen serviceonderbreking met uw VPN-verbinding wanneer u migreert naar Resource Manager. Daarom blijven bestaande workloads werken zonder verlies van on-premises connectiviteit tijdens de migratie.

Moet ik mijn on-premises apparaat opnieuw configureren nadat de VPN Gateway is gemigreerd naar Resource Manager?

Het openbare IP-adres dat is gekoppeld aan de VPN-gateway, blijft hetzelfde, zelfs na de migratie. U hoeft uw on-premises router niet opnieuw te configureren.

Wat zijn de ondersteunde scenario's voor klassieke VPN Gateway migratie naar Resource Manager?

De meeste veelvoorkomende SCENARIO's voor VPN-connectiviteit worden behandeld door de klassieke migratie naar Resource Manager. De ondersteunde scenario's zijn onder andere:

  • Punt-naar-site-connectiviteit

  • Site-naar-site-connectiviteit met een VPN Gateway verbonden met een on-premises locatie

  • VNet-naar-VNet-connectiviteit tussen twee virtuele netwerken met behulp van VPN-gateways

  • Meerdere VNets die zijn verbonden met dezelfde on-premises locatie

  • Connectiviteit met meerdere sites

  • Virtuele netwerken waarvoor geforceerde tunneling is ingeschakeld

Welke scenario's worden niet ondersteund voor migratie van klassieke VPN Gateway naar Resource Manager?

Scenario's die niet worden ondersteund, zijn onder andere:

  • Virtueel netwerk met zowel een ExpressRoute-gateway als een VPN Gateway wordt momenteel niet ondersteund.

  • Virtueel netwerk met een ExpressRoute-gateway die is verbonden met een circuit in een ander abonnement.

  • Transitscenario's waarbij VM-extensies zijn verbonden met on-premises servers.

Waar vind ik meer informatie over migratie van klassiek naar Azure Resource Manager?

Zie Veelgestelde vragen over migratie van klassiek naar Azure Resource Manager voor meer informatie.

Hoe kan ik een probleem melden?

U kunt uw vragen over uw migratieproblemen posten op de Microsoft Q&A-pagina. Het is raadzaam dat u al uw vragen op dit forum plaatst. Als u een ondersteuningscontract hebt, kunt u ook een ondersteuningsaanvraag indienen.