Routering van verkeer in virtuele netwerken

  • Artikel

Lees hier hoe Azure verkeer routeert tussen Azure, on-premises en resources op internet. Azure maakt automatisch een routetabel voor elk subnet binnen een virtueel Azure-netwerk en voegt standaardsysteemroutes toe aan de tabel. Zie Azure Virtual Network voor meer informatie over virtuele netwerken en subnetten. U kunt enkele systeemroutes van Azure overschrijven met aangepaste routes en meer aangepaste routes toevoegen aan routetabellen. De route van uitgaand verkeer van een subnet wordt gebaseerd op de routes in de routetabel van een subnet.

Systeemroutes

Azure maakt automatisch systeemroutes en wijst de routes toe aan elk subnet in een virtueel netwerk. U kunt zelf geen systeemroutes maken en ook niet verwijderen. Het is wel mogelijk om bepaalde systeemroutes te vervangen door aangepaste routes. Azure maakt standaardsysteemroutes voor elk subnet en voegt meer optionele standaardroutes toe aan specifieke subnetten, of elk subnet, wanneer u specifieke Azure-mogelijkheden gebruikt.

Standaardinstelling

Elke route bevat een adresvoorvoegsel en het volgende hoptype. Wanneer uitgaand verkeer van een subnet wordt verzonden naar een IP-adres binnen het adresvoorvoegsel van een route, is de route met het voorvoegsel de route die door Azure wordt gebruikt. Lees hoe Azure een route selecteert wanneer meerdere routes dezelfde voorvoegsels bevatten, of overlappende voorvoegsels. Wanneer er een virtueel netwerk wordt gemaakt, maakt Azure automatisch de volgende standaardsysteemroutes voor elk subnet in het virtuele netwerk:

Bron Adresvoorvoegsels Volgend hoptype
Standaardinstelling Uniek voor het virtuele netwerk Virtueel netwerk
Standaardinstelling 0.0.0.0/0 Internet
Standaardinstelling 10.0.0.0/8 Geen
Standaardinstelling 172.16.0.0/12 Geen
Standaardinstelling 192.168.0.0/16 Geen
Standaardinstelling 100.64.0.0/10 Geen

De 'volgende hoptypen' in de bovenstaande tabel bepalen hoe Azure verkeer routeert dat bestemd is voor het vermelde adresvoorvoegsel. Hieronder worden de 'volgende hoptypen' toegelicht:

  • Virtueel netwerk: routeert verkeer tussen adresbereiken in de adresruimte van een virtueel netwerk. Azure maakt een route met een adresvoorvoegsel dat overeenkomt met elk-adresbereik dat is gedefinieerd in de adresruimte van een virtueel netwerk. Als in de adresruimte van het virtuele netwerk meerdere adresbereiken zijn gedefinieerd, maakt Azure een afzonderlijke route voor elk adresbereik. Verkeer tussen subnetten wordt door Azure automatisch gerouteerd met behulp van de routes die voor elk adresbereik zijn gemaakt. U hoeft geen gateways te definiëren voor Azure voor het routeren van verkeer tussen subnetten. Hoewel een virtueel netwerk subnetten bevat en elk subnet een gedefinieerd adresbereik heeft, maakt Azure geen standaardroutes voor subnetadresbereiken. Elk subnetadresbereik bevindt zich binnen een adresbereik van de adresruimte van een virtueel netwerk.

  • Internet: routeert verkeer dat is opgegeven met het adresvoorvoegsel naar internet. De standaardsysteemroute is gekoppeld aan het adresvoorvoegsel 0.0.0.0/0. Als u de standaardroutes van Azure niet overschrijft, routeert Azure verkeer voor een adres dat niet is opgegeven door een adresbereik binnen een virtueel netwerk naar internet. Er is één uitzondering op deze routering. Als het doeladres hoort bij een service van Azure, stuurt Azure het verkeer rechtstreeks naar de service. Het verkeer loopt dan via het backbone-netwerk van Azure en wordt dus niet naar internet gerouteerd. Verkeer tussen Azure-services gaat niet via internet, ongeacht in welke Azure-regio het virtuele netwerk bestaat of in welke Azure-regio een exemplaar van de Azure-service wordt geïmplementeerd. U kunt de standaardsysteemroute van Azure voor het adresvoorvoegsel 0.0.0.0/0 vervangen door een aangepaste route.

  • Geen: verkeer dat wordt doorgestuurd naar het 'volgende hoptype' Geen, wordt verwijderd en niet buiten het subnet gerouteerd. Azure maakt automatisch standaardroutes voor de volgende adresvoorvoegsels:

    • 10.0.0.0/8, 172.16.0.0/12 of 192.168.0.0/16: gereserveerd voor persoonlijk gebruik in RFC 1918.

    • 100.64.0.0/10: gereserveerd in RFC 6598.

    Als u een van de bovenstaande adresbereiken toewijst binnen de adresruimte van een virtueel netwerk, wijzigt Azure het 'volgende hoptype' voor de route automatisch van Geen in Virtueel netwerk. Als u een adresbereik toewijst aan de adresruimte van een virtueel netwerk dat weliswaar een van de vier gereserveerde adresvoorvoegsels bevat, maar dat niet hetzelfde is, verwijdert Azure de route voor het voorvoegsel en wordt er een route toegevoegd voor het adresvoorvoegsel dat u hebt toegevoegd, met Virtueel netwerk als het 'volgende hoptype'.

Optionele standaardroutes

Azure voegt meer standaardsysteemroutes toe voor verschillende Azure-mogelijkheden, maar alleen als u de mogelijkheden inschakelt. Afhankelijk van de mogelijkheid, voegt Azure optionele standaardroutes toe naar specifieke subnetten in het virtuele netwerk of naar alle subnetten in een virtueel netwerk. De andere systeemroutes en volgende hoptypen die Azure kan toevoegen wanneer u verschillende mogelijkheden inschakelt, zijn:

Bron Adresvoorvoegsels Volgend hoptype Subnet binnen het virtuele netwerk waarnaar een route wordt toegevoegd
Standaardinstelling Uniek is voor het virtuele netwerk, bijvoorbeeld: 10.1.0.0/16 VNet-peering Alle
Gateway voor een virtueel netwerk Voorvoegsels geadverteerd van on-premises via BGP of geconfigureerd in de lokale netwerkgateway Gateway voor een virtueel netwerk Alle
Standaardinstelling Meerdere VirtualNetworkServiceEndpoint Alleen het subnet waarvoor een service-eindpunt is ingeschakeld.

  • VNet-peering (virtueel netwerk): wanneer u een peering van een virtueel netwerk tussen twee virtuele netwerken maakt, voegt het systeem een route toe voor elk adresbereik binnen de adresruimte van elk virtueel netwerk dat betrokken is bij de peering. Meer informatie over peering van virtuele netwerken.

  • Gateway van een virtueel netwerk: er worden een of meer routes met Gateway van een virtueel netwerk als het 'volgende hoptype' toegevoegd wanneer er een gateway van een virtueel netwerk wordt toegevoegd aan een virtueel netwerk. De bron is ook Gateway van virtueel netwerk omdat de gateway de routes naar het subnet toevoegt. Als uw on-premises netwerkgateway BGP-routes (Border Gateway Protocol) uitwisselt met een virtuele netwerkgateway, voegt het systeem een route toe voor elke route. Deze routes worden doorgegeven vanuit de on-premises netwerkgateway. We raden u aan om on-premises routes samen te vatten naar het grootst mogelijke adresbereik, zodat u het minste aantal routes doorgeeft aan een gateway van een virtueel Azure-netwerk. Er gelden beperkingen voor het aantal routes dat kan worden doorgegeven aan de gateway van een virtueel Azure-netwerk. Zie Netwerkenlimieten voor meer informatie.

  • VirtualNetworkServiceEndpoint: de openbare IP-adressen voor bepaalde services worden door Azure aan de routetabel toegevoegd wanneer u een service-eindpunt voor de service inschakelt. Service-eindpunten worden ingeschakeld voor afzonderlijke subnetten in een virtueel netwerk, zodat de route alleen wordt toegevoegd aan de routetabel van een subnet waarvoor een service-eindpunt is ingeschakeld. De openbare IP-adressen van Azure-services worden periodiek gewijzigd. Azure beheert de adressen in de routetabel automatisch als de adressen worden gewijzigd. Lees hier meer over service-eindpunten van virtuele netwerken, en de services waarvoor u service-eindpunten kunt maken.

    Notitie

    De 'volgende hoptypen' VNet-peering en VirtualNetworkServiceEndpoint worden alleen toegevoegd aan routetabellen van subnetten in virtuele netwerken die zijn gemaakt via het implementatiemodel Azure Resource Manager. De volgende hoptypen worden niet toegevoegd aan routetabellen die zijn gekoppeld aan subnetten van virtuele netwerken die zijn gemaakt via het klassieke implementatiemodel. Meer informatie over implementatiemodellen van Azure.

Aangepaste routes

U maakt aangepaste routes door door de gebruiker gedefinieerde routes te maken of door BGP-routes (Border Gateway Protocol) uit te wisselen tussen de gateway van uw on-premises netwerk en de gateway van een virtueel Azure-netwerk.

Eigen definitie

U kunt aangepaste, of door de gebruiker gedefinieerde (statische), routes maken in Azure om de standaardsysteemroutes van Azure te vervangen of om meer routes toe te voegen aan de routetabel van een subnet. In Azure maakt u een routetabel, waarna u de routetabel koppelt aan nul of meer subnetten van een virtueel netwerk. Elk subnet kan zijn gekoppeld aan geen enkele of één routetabel. Zie Netwerklimieten voor meer informatie over het maximum aantal routes dat u kunt toevoegen aan een routetabel en het maximum aantal door de gebruiker gedefinieerde routetabellen dat u per Azure-abonnement kunt maken. Wanneer u een routetabel maakt en deze koppelt aan een subnet, worden de routes van de tabel gecombineerd met de standaardroutes van het subnet. Als er conflicterende routetoewijzingen zijn, overschrijven door de gebruiker gedefinieerde routes de standaardroutes.

U kunt de onderstaande 'volgende hoptypen' opgeven wanneer u een door de gebruiker gedefinieerde route maakt:

  • Virtueel apparaat: een virtueel apparaat is een virtuele machine waarop meestal een netwerktoepassing wordt uitgevoerd, zoals een firewall. Zie De Azure Marketplace voor meer informatie over verschillende vooraf geconfigureerde virtuele netwerkapparaten die u in een virtueel netwerk kunt implementeren. Wanneer u een route maakt met het hoptype Virtueel apparaat, moet u ook het IP-adres van de volgende hop opgeven. Het IP-adres kan bestaan uit:

    • Het privé-IP-adres van een netwerkinterface die is gekoppeld aan een virtuele machine. Als een netwerkinterface is gekoppeld aan een virtuele machine die netwerkverkeer doorstuurt naar een ander adres dan het eigen adres, moet in Azure de optie Doorsturen via IP inschakelen zijn ingeschakeld voor de interface. Deze instelling zorgt ervoor dat Azure de bron en bestemming voor een netwerkinterface niet controleert. Lees hier meer over het inschakelen van doorsturen via IP voor een netwerkinterface. Hoewel Doorsturen via IP inschakelen een instelling van Azure is, moet u doorsturen via IP mogelijk ook inschakelen in het besturingssysteem van de virtuele machine voor het apparaat om verkeer door te sturen tussen privé-IP-adressen die zijn toegewezen aan Azure-netwerkinterfaces. Als het apparaat verkeer naar een openbaar IP-adres moet routeren, moet het verkeer proxyn of NAT (Network Address Translation) uitvoeren van het privé-IP-adres van de bron naar een eigen privé-IP-adres. Vervolgens voert Azure NAT uit naar een openbaar IP-adres voordat het verkeer naar internet wordt verzonden. Raadpleeg de documentatie voor uw besturingssysteem of netwerktoepassing om de vereiste instellingen voor de virtuele machine te bepalen. Zie Uitleg over uitgaande verbindingen voor meer informatie over uitgaande verbindingen in Azure.

      Notitie

      Implementeer een virtueel apparaat in een ander subnet dan de resources die via het virtuele apparaat worden gerouteerd. Het implementeren van het virtuele apparaat in hetzelfde subnet en het toepassen van een routetabel op het subnet dat verkeer door het virtuele apparaat routeert, kan leiden tot routeringslussen waarbij verkeer nooit het subnet verlaat.

      Een privé-IP-adres van de volgende hop moet directe connectiviteit hebben zonder dat u via ExpressRoute Gateway of Virtual WAN hoeft te routeren. Als u de volgende hop instelt op een IP-adres zonder directe connectiviteit, resulteert dit in een ongeldige door de gebruiker gedefinieerde routeringsconfiguratie.

    • Het privé IP-adres van een interne load balancer van Azure. Een load balancer wordt vaak gebruikt als onderdeel van een strategie voor hoge beschikbaarheid van virtuele netwerkapparaten.

    U kunt een route met 0.0.0.0.0/0 definiëren als het adresvoorvoegsel en een volgend hoptype van het virtuele apparaat. Met deze configuratie kan het apparaat het verkeer inspecteren en bepalen of het verkeer moet worden doorgestuurd of verwijderd. Als u van plan bent een door de gebruiker gedefinieerde route te maken met het adresvoorvoegsel 0.0.0.0/0, moet u eerst Adresvoorvoegsel 0.0.0.0/0 lezen.

  • Gateway van virtueel netwerk: gebruik dit type als u verkeer dat is bestemd voor specifieke adresvoorvoegsels wilt doorsturen naar de gateway van een virtueel netwerk. De gateway van het virtuele netwerk moet worden gemaakt met het type VPN. U kunt geen virtuele netwerkgateway opgeven die is gemaakt als type ExpressRoute in een door de gebruiker gedefinieerde route, omdat u met ExpressRoute BGP moet gebruiken voor aangepaste routes. U kunt virtuele netwerkgateways niet opgeven als u vpn- en ExpressRoute-verbindingen naast elkaar hebt. U kunt een route definiëren om ervoor te zorgen dat verkeer dat is bestemd voor het adresvoorvoegsel 0.0.0.0/0 wordt omgeleid naar de gateway van een virtueel netwerk die op routes is gebaseerd. Het is mogelijk dat u on-premises een apparaat hebt dat het verkeer inspecteert en vervolgens bepaalt of dit moet worden doorgestuurd of verwijderd. Als u van plan bent een door de gebruiker gedefinieerde route te maken voor het adresvoorvoegsel 0.0.0.0/0, moet u eerst Adresvoorvoegsel 0.0.0.0/0 lezen. In plaats van een door de gebruiker gedefinieerde route te configureren voor het adresvoorvoegsel 0.0.0.0/0, kunt u een route met het voorvoegsel 0.0.0.0/0 adverteren via BGP, maar alleen als u BGP hebt ingeschakeld voor de gateway van een virtueel netwerk.

  • Geen: gebruik dit type als u het verkeer naar een adresvoorvoegsel wilt verwijderen, in plaats van het verkeer door te sturen naar een bestemming. Als u een mogelijkheid van Azure niet volledig hebt geconfigureerd, kan voor sommige optionele systeemroutes Geen worden vermeld. Als u bijvoorbeeld Geen ziet staan bij IP-adres van volgende hop met Volgende hoptype ingesteld op Gateway van virtueel netwerk of Virtueel apparaat, kan het zijn dat het apparaat niet wordt uitgevoerd of niet volledig is geconfigureerd. Azure maakt standaardsysteemroutes voor gereserveerde adresvoorvoegsels met Geen als het 'volgende hoptype'.

  • Virtueel netwerk: geef de optie Virtueel netwerk op wanneer u de standaardroutering binnen een virtueel netwerk wilt overschrijven. Zie Voorbeeld van routering voor een voorbeeld van waarom u een route met het hoptype Virtueel netwerk zou maken.

  • Internet: Geef de internetoptie op wanneer u verkeer dat is bestemd voor een adresvoorvoegsel expliciet naar internet wilt routeren of als u verkeer wilt dat bestemd is voor Azure-services met openbare IP-adressen die in het Backbone-netwerk van Azure worden bewaard.

U kunt peering van virtuele netwerken of VirtualNetworkServiceEndpoint niet opgeven als het volgende hoptype in door de gebruiker gedefinieerde routes. Routes met peering van virtuele netwerken of VirtualNetworkServiceEndpoint volgende hoptypen worden alleen gemaakt door Azure wanneer u peering van een virtueel netwerk of een service-eindpunt configureert.

Servicetags voor door de gebruiker gedefinieerde routes

U kunt nu een servicetag opgeven als het adresvoorvoegsel voor een door de gebruiker gedefinieerde route in plaats van een expliciet IP-bereik. Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Microsoft beheert de adresvoorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij wanneer adressen worden gewijzigd. Zo minimaliseert u de complexiteit van frequente updates voor door de gebruiker gedefinieerde routes en vermindert u het aantal routes dat u moet maken. U kunt momenteel 25 of minder routes maken met servicetags in elke routetabel. In deze release wordt het gebruik van servicetags in routeringsscenario's voor containers ook ondersteund.

Exacte overeenkomst

Het systeem geeft voorkeur aan de route met het expliciete voorvoegsel wanneer er een exacte overeenkomst is tussen een route met een expliciet IP-voorvoegsel en een route met een servicetag. Wanneer meerdere routes met servicetags overeenkomende IP-voorvoegsels hebben, worden routes in de volgende volgorde geëvalueerd:

  1. Regionale tags (bijvoorbeeld Storage.EastUS, AppService.AustraliaCentral)

  2. Tags op het hoogste niveau (bijvoorbeeld Storage, AppService)

  3. Regionale tags van AzureCloud (bijvoorbeeld AzureCloud.canadacentral, AzureCloud.eastasia)

  4. De AzureCloud-tag

Als u deze functie wilt gebruiken, geeft u een servicetagnaam op voor de parameter voor het adresvoorvoegsel in routetabelopdrachten. In PowerShell kunt u bijvoorbeeld een nieuwe route maken om verkeer dat naar een IP-voorvoegsel van Azure Storage naar een virtueel apparaat wordt verzonden, te leiden met behulp van: 

$param = @{
    Name = 'StorageRoute'
    AddressPrefix = 'Storage'
    NextHopType = 'VirtualAppliance'
    NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param

Dezelfde opdracht voor CLI is als volgt:

az network route-table route create \
    --resource-group MyResourceGroup \
    --route-table-name MyRouteTable \
    --name StorageRoute \
    --address-prefix Storage \
    --next-hop-type VirtualAppliance \
    --next-hop-ip-address 10.0.100.4

'Volgende hoptypen' in Azure-hulpprogramma's

De naam die wordt weergegeven en waarnaar wordt verwezen voor 'volgende hoptypen' is verschillend voor de Azure-portal en voor opdrachtregelprogramma's, evenals voor het implementatiemodel Azure Resource Manager en het klassieke implementatiemodel. De onderstaande tabel bevat de namen die worden gebruikt om te verwijzen naar elk 'volgend hoptype' in de verschillende hulpprogramma's en implementatiemodellen:

Volgend hoptype Azure CLI en PowerShell (Resource Manager) Azure CLI (klassiek) en PowerShell (klassiek)
Gateway voor een virtueel netwerk VirtualNetworkGateway VPNGateway
Virtueel netwerk VNetLocal VNETLocal (niet beschikbaar in de klassieke CLI in servicebeheermodus)
Internet Internet Internet (niet beschikbaar in de klassieke CLI in de servicebeheermodus)
Virtueel apparaat VirtualAppliance VirtualAppliance
Geen Geen Null (niet beschikbaar in de klassieke CLI in de servicebeheermodus)
Peering op virtueel netwerk VNet-peering Niet van toepassing
Service-eindpunt voor virtueel netwerk VirtualNetworkServiceEndpoint Niet van toepassing

Border Gateway Protocol

Een on-premises netwerkgateway kan via BGP (Border Gateway Protocol) routes uitwisselen met de gateway van een virtueel Azure-netwerk. Het gebruik van BGP met een virtuele Azure-netwerkgateway is afhankelijk van het type dat u hebt geselecteerd bij het maken van de gateway:

  • ExpressRoute: U moet BGP gebruiken om on-premises routes te adverteren naar de Microsoft Edge-router. U kunt geen door de gebruiker gedefinieerde routes maken om af te dwingen dat verkeer naar de gateway van een virtueel ExpressRoute-netwerk wordt geleid, wanneer u de gateway van een virtueel netwerk implementeert als het type ExpressRoute. U kunt door de gebruiker gedefinieerde routes gebruiken om af te dwingen dat verkeer van Express Route naar bijvoorbeeld een Network Virtual Appliance wordt geleid.

  • VPN: u kunt desgewenst BGP gebruiken. Zie Overzicht van BGP met Azure VPN-gateways voor meer informatie.

Wanneer u routes met Azure uitwisselt via BGP, wordt er voor elk geadverteerd voorvoegsel een afzonderlijke route toegevoegd aan de routetabel van alle subnetten in een virtueel netwerk. De route wordt toegevoegd met Gateway van virtueel netwerk als de bron en het 'volgende hoptype'.

Doorgave van ER- en VPN Gateway-route kan worden uitgeschakeld op een subnet met behulp van een eigenschap in een routeringstabel. Wanneer u routepropagatie uitschakelt, voegt het systeem geen routes toe aan de routeringstabel van alle subnetten als routepropagatie van virtuele netwerkgateway is uitgeschakeld. Dit proces is van toepassing op zowel statische routes als BGP-routes. Connectiviteit met VPN-verbindingen wordt bereikt met behulp van aangepaste routes met een volgend hoptype van Virtueel-netwerkgateway. Routedoorgifte mag niet worden uitgeschakeld op het GatewaySubnet. De gateway werkt niet als deze instelling is uitgeschakeld. Zie Routedoorgifte van virtuele netwerkgateway uitschakelen voor meer informatie.

Hoe Azure een route selecteert

Als er uitgaand verkeer wordt verzonden vanuit een subnet, selecteert Azure een route op basis van het doel-IP-adres, met behulp van een algoritme voor het matchen van het langste voorvoegsel. Een routetabel heeft bijvoorbeeld twee routes: één route met het adresvoorvoegsel 10.0.0.0/24 en een andere route met het adresvoorvoegsel 10.0.0.0/16. Azure stuurt verkeer dat is bestemd voor 10.0.0.5 naar het volgende hoptype dat is opgegeven in de route met het adresvoorvoegsel 10.0.0.0/24. Dit proces treedt op omdat 10.0.0.0/24 een langer voorvoegsel is dan 10.0.0.0/16, ook al valt 10.0.0.5 binnen beide adresvoorvoegsels. Azure stuurt verkeer dat is bestemd voor 10.0.1.5 naar het volgende hoptype dat is opgegeven in de route met het adresvoorvoegsel 10.0.0.0/16. Dit proces treedt op omdat 10.0.1.5 niet is opgenomen in het adresvoorvoegsel 10.0.0.0/24, waardoor de route met het adresvoorvoegsel 10.0.0.0/16 het langste overeenkomende voorvoegsel is.

Als meerdere routes hetzelfde adresvoorvoegsel bevatten, selecteert Azure het routetype op basis van de volgende prioriteit:

  1. Door de gebruiker gedefinieerde route

  2. BGP-route

  3. Systeemroute

Notitie

Systeemroutes voor verkeer dat is gerelateerd aan virtuele netwerken, peerings voor virtuele netwerken of service-eindpunten voor virtuele netwerken zijn voorkeursroutes, zelfs als BGP-routes specifieker zijn.

Een routetabel bevat bijvoorbeeld de volgende routes:

Bron Adresvoorvoegsels Volgend hoptype
Standaardinstelling 0.0.0.0/0 Internet
User 0.0.0.0/0 Gateway voor een virtueel netwerk

Wanneer verkeer bestemd is voor een IP-adres buiten de adresvoorvoegsels van alle andere routes in de routetabel, selecteert Azure de route met de bron Gebruiker omdat door de gebruiker gedefinieerde routes een hogere prioriteit hebben dan standaardsysteemroutes.

Zie Voorbeeld van routering voor een uitgebreide routeringstabel met uitleg van de routes in de tabel.

Adresvoorvoegsel 0.0.0.0/0

Een route met het adresvoorvoegsel 0.0.0.0/0 geeft instructies voor Azure. Azure gebruikt deze instructies om verkeer te routeren dat is bestemd voor een IP-adres dat niet binnen het adresvoorvoegsel van een andere route in de routetabel van een subnet valt. Wanneer er een subnet wordt gemaakt, maakt Azure een standaardroute naar het adresvoorvoegsel 0.0.0.0/0 van het 'volgende hoptype' Internet. Als u deze route niet overschrijft, stuurt Azure al het verkeer dat is bestemd voor IP-adressen die niet zijn opgenomen in het adresvoorvoegsel van een andere route naar internet. De uitzondering hierop is dat verkeer naar de openbare IP-adressen van Azure-services in het Backbone-netwerk van Azure blijft en niet naar internet wordt gerouteerd. Wanneer u deze route overschrijft met een aangepaste route, wordt verkeer dat bestemd is voor adressen die niet binnen de adresvoorvoegsels van een andere route in de routetabel vallen, omgeleid. De bestemming is afhankelijk van of u een virtueel netwerkapparaat of virtuele netwerkgateway opgeeft in de aangepaste route.

Wanneer u het adresvoorvoegsel 0.0.0.0/0 overschrijft, wordt niet alleen uitgaand verkeer van de subnetstroom via de virtuele netwerkgateway of het virtuele apparaat overschreven, maar treden de volgende wijzigingen ook op met de standaardroutering van Azure:

  • Azure verzendt alle verkeer naar het 'volgende hoptype' dat is opgegeven in de route, om ook verkeer op te nemen dat is bestemd voor openbare IP-adressen van Azure-services. Wanneer het 'volgende hoptype' voor de route met het adresvoorvoegsel 0.0.0.0/0 Internet is, blijft verkeer van het subnet dat is bestemd voor de openbare IP-adressen van Azure-services altijd in het backbone-netwerk, ongeacht de Azure-regio waarin het virtuele netwerk of de Azure-serviceresource zich bevindt. Wanneer u echter een door de gebruiker gedefinieerde route of BGP-route maakt met Gateway van virtueel netwerk of Virtueel apparaat als het 'volgende hoptype', wordt al het verkeer, dus ook het verkeer dat wordt verzonden naar openbare IP-adressen van Azure services waarvoor u geen service-eindpunten hebt ingeschakeld, verzonden naar het 'volgende hoptype' dat is opgegeven in de route. Wanneer u een service-eindpunt voor een service inschakelt, maakt Azure een route met adresvoorvoegsels voor de service. Verkeer naar de service routeert niet naar het volgende hoptype in een route met het adresvoorvoegsel 0.0.0.0/0. De adresvoorvoegsels voor de service zijn langer dan 0.0.0.0/0.

  • U hebt geen rechtstreeks toegang meer tot resources in het subnet vanaf internet. U hebt indirect toegang tot resources in het subnet vanaf internet. Het apparaat dat is opgegeven door het volgende hoptype voor een route met het adresvoorvoegsel 0.0.0.0/0, moet binnenkomend verkeer verwerken. Nadat het verkeer het apparaat doorkruist, bereikt het verkeer de resource in het virtuele netwerk. Als de route de volgende waarden voor het 'volgende hoptype' bevat:

    • Virtueel apparaat: de volgende voorwaarden moeten van toepassing zijn op het apparaat:

      • Het apparaat is toegankelijk vanaf internet

      • Het apparaat heeft een openbaar IP-adres

      • Er mag geen regel uit een netwerkbeveiligingsgroep zijn gekoppeld aan het apparaat waarmee communicatie met het apparaat wordt voorkomen

      • De communicatie mag niet worden geweigerd

      • Het apparaat moet het netwerkadres kunnen omzetten en doorsturen, of het verkeer via een proxy omleiden naar de doelresource in het subnet, en het verkeer terugleiden naar internet.

    • Gateway van virtueel netwerk: als de gateway een ExpressRoute-gateway is, kan een on-premises apparaat dat met internet is verbonden het netwerkadres omzetten en doorsturen, of het verkeer via een proxy omleiden naar de doelresource in het subnet, via privé-peering van ExpressRoute.

Als uw virtuele netwerk is verbonden met een Azure VPN-gateway, koppelt u geen routetabel aan het gatewaysubnet dat een route bevat met een bestemming van 0.0.0.0/0. Als u dit wel doet, functioneert de gateway mogelijk niet juist. Zie de vraag Waarom zijn bepaalde poorten geopend op mijn VPN-gateway? in de Veelgestelde vragen over VPN Gateways voor meer informatie.

Zie DMZ tussen Azure en uw on-premises datacenter voor implementatiedetails bij het gebruik van virtuele netwerkgateways tussen internet en Azure.

Voorbeeld van routering

Ter illustratie van de concepten in dit artikel, wordt in de volgende secties aandacht besteed aan:

  • Een scenario, inclusief vereisten

  • De aangepaste routes die nodig zijn om te voldoen aan de vereisten

  • De routetabel voor een subnet, met inbegrip van de standaard- en aangepaste routes die nodig zijn om aan de vereisten te voldoen

Notitie

Dit voorbeeld is niet bedoeld om een aanbevolen of best practice-implementatie te zijn. maar uitsluitend ter illustratie van de concepten in dit artikel.

Vereisten

  1. Implementeer twee virtuele netwerken in dezelfde Azure-regio en zorg dat resources kunnen communiceren tussen de virtuele netwerken.

  2. Zorg dat een on-premises netwerk veilig kan communiceren met beide virtuele netwerken via een VPN-tunnel over internet. U kunt ook een ExpressRoute-verbinding gebruiken, maar in dit voorbeeld wordt een VPN-verbinding gebruikt.

  3. Voor één subnet in één virtueel netwerk:

    • Laat al het uitgaande verkeer vanuit het subnet, behalve naar Azure Storage en binnen het subnet, geforceerd langs een virtueel netwerkapparaat lopen, voor controle en logboekregistratie.

    • Inspecteer geen verkeer tussen privé-IP-adressen binnen het subnet; verkeer rechtstreeks tussen alle resources laten stromen.

    • Verwijder al het uitgaande verkeer dat is bestemd voor het andere virtuele netwerk.

    • Zorg dat uitgaand verkeer naar Azure Storage rechtstreeks naar de opslag wordt geleid, zonder geforceerde omleiding via een virtueel netwerkapparaat.

  4. Sta al het verkeer tussen alle andere subnetten en virtuele netwerken toe.

Implementatie

De volgende afbeelding laat een implementatie via het Azure Resource Manager-implementatiemodel zien die voldoet aan de bovenstaande vereisten:

Diagram of network.

De pijlen geven de richting van het verkeer aan.

Routetabellen

Subnet1

De routetabel voor Subnet1 in de afbeelding bevat de volgende routes:

Id Bron Staat Adresvoorvoegsels Volgend hoptype IP-adres van volgende hop Naam van door gebruiker gedefinieerde route
1 Standaardinstelling Ongeldig 10.0.0.0/16 Virtueel netwerk
2 User Actief 10.0.0.0/16 Virtueel apparaat 10.0.100.4 Within-VNet1
3 User Actief 10.0.0.0/24 Virtueel netwerk Within-Subnet1
4 Standaardinstelling Ongeldig 10.1.0.0/16 VNet-peering
5 Standaardinstelling Ongeldig 10.2.0.0/16 VNet-peering
6 User Actief 10.1.0.0/16 Geen ToVNet2-1-Drop
7 User Actief 10.2.0.0/16 Geen ToVNet2-2-Drop
8 Standaardinstelling Ongeldig 10.10.0.0/16 Gateway voor een virtueel netwerk [X.X.X.X]
9 User Actief 10.10.0.0/16 Virtueel apparaat 10.0.100.4 To-On-Prem
10 Standaardinstelling Actief [X.X.X.X] VirtualNetworkServiceEndpoint
11 Standaardinstelling Ongeldig 0.0.0.0/0 Internet
12 User Actief 0.0.0.0/0 Virtueel apparaat 10.0.100.4 Default-NVA

Hier volgt een uitleg van elke route-id:

  • ID1: Azure heeft deze route automatisch toegevoegd voor alle subnetten in Virtual-network-1, omdat 10.0.0.0/16 het enige adresbereik is dat is gedefinieerd in de adresruimte voor het virtuele netwerk. Als u de door de gebruiker gedefinieerde route niet in route-id2 maakt, wordt verkeer dat wordt verzonden naar een adres tussen 10.0.0.1 en 10.0.255.254 binnen het virtuele netwerk gerouteerd. Dit proces komt doordat het voorvoegsel langer is dan 0.0.0.0/0 en niet binnen de adresvoorvoegsels van andere routes valt. Azure heeft de status automatisch gewijzigd van Actief in Ongeldig op het moment dat ID2, een door de gebruiker gedefinieerde route, werd toegevoegd. De reden hiervoor is dat de route hetzelfde voorvoegsel heeft als de standaardroute, en door de gebruiker gedefinieerde routes hebben prioriteit boven standaardroutes. De status van deze route is nog steeds Actief voor Subnet2, omdat de routetabel waarin die door de gebruiker gedefinieerde route zich bevindt, ID2, niet is gekoppeld aan Subnet2.

  • ID2: Azure heeft deze route toegevoegd wanneer een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 10.0.0.0/16 is gekoppeld aan het subnet1-subnet in het virtuele netwerk-1 van het virtuele netwerk. In de door de gebruiker gedefinieerde route is 10.0.100.4 ingesteld als het IP-adres van het virtuele apparaat omdat het adres het privé IP-adres is dat is toegewezen aan het virtuele apparaat. De routetabel waarin deze route bestaat, is niet gekoppeld aan Subnet2, dus wordt niet weergegeven in de routetabel voor Subnet2. Deze route overschrijft de standaardroute voor het adresvoorvoegsel 10.0.0.0/16 (ID1), waarmee verkeer dat is geadresseerd aan 10.0.0.1 en 10.0.255.254 automatisch binnen het virtuele netwerk wordt doorgestuurd via het 'volgende hoptype' Virtueel netwerk. Deze route bestaat om te voldoen aan vereiste 3; al het uitgaande verkeer geforceerd omleiden via een virtueel apparaat.

  • Id3: Azure heeft deze route toegevoegd wanneer een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 10.0.0.0/24 is gekoppeld aan het subnet1-subnet . Verkeer dat is bestemd voor adressen tussen 10.0.0.1 en 10.0.0.254 blijft binnen het subnet en wordt niet doorgestuurd naar het virtuele apparaat dat is opgegeven in de vorige regel (ID2). De reden hiervoor is dat deze route een langer voorvoegsel heeft dan de route ID2. Deze route is niet gekoppeld aan Subnet2, dus de route wordt niet weergegeven in de routetabel voor Subnet2. In feite vervangt deze route de route ID2 voor verkeer binnen Subnet1. Deze route bestaat om te voldoen aan vereiste 3.

  • ID4: Azure heeft automatisch de routes toegevoegd in id's 4 en 5 voor alle subnetten in Virtual-network-1, toen het virtuele netwerk werd gekoppeld aan Virtual-network-2.Virtual-network-2 heeft twee adresbereiken in de adresruimte: 10.1.0.0/16 en 10.2.0.0/16, zodat Azure een route voor elk bereik heeft toegevoegd. Als u de door de gebruiker gedefinieerde routes niet maakt in route-id's 6 en 7, wordt verkeer dat wordt verzonden naar een adres tussen 10.1.0.1-10.1.255.254 en 10.2.0.1-10.2.255.254, doorgestuurd naar het gekoppelde virtuele netwerk. Dit proces komt doordat het voorvoegsel langer is dan 0.0.0.0/0 en niet binnen de adresvoorvoegsels van andere routes valt. Wanneer u de routes in id's 6 en 7 hebt toegevoegd, heeft Azure de status automatisch gewijzigd van Actief in Ongeldig. Dit proces komt doordat ze dezelfde voorvoegsels hebben als de routes in id's 4 en 5, en door de gebruiker gedefinieerde routes standaardroutes overschrijven. De status van de routes in id's 4 en 5 is nog steeds actief voor Subnet2, omdat de routetabel waarin de door de gebruiker gedefinieerde routes in id's 6 en 7 zich bevinden, niet is gekoppeld aan Subnet2. Er is een peering van virtuele netwerken gemaakt om te voldoen aan vereiste 1.

  • ID5: Dezelfde uitleg als ID4.

  • ID6: Azure heeft deze route en de route in ID7 toegevoegd wanneer door de gebruiker gedefinieerde routes voor de adresvoorvoegsels 10.1.0.0/16 en 10.2.0.0/16 zijn gekoppeld aan het subnet1-subnet . Azure verwijdert verkeer dat is bestemd voor adressen tussen 10.1.0.1-10.1.255.254 en 10.2.0.1-10.2.255.254, in plaats van te worden doorgestuurd naar het gekoppelde virtuele netwerk, omdat door de gebruiker gedefinieerde routes standaardroutes overschrijven. De routes zijn niet gekoppeld aan Subnet2, dus de routes worden niet weergegeven in de routetabel voor Subnet2. De routes overschrijven de routes ID4 en ID5 voor verkeer dat Subnet1 verlaat. De routes ID6 en ID7 bestaan om te voldoen aan vereiste 3; verkeer verwijderen dat is bestemd voor het andere virtuele netwerk.

  • ID7: Dezelfde uitleg als ID6.

  • ID8: Azure heeft deze route automatisch toegevoegd voor alle subnetten in Virtual-network-1 wanneer een virtuele netwerkgateway van het VPN-type is gemaakt in het virtuele netwerk. Azure heeft het openbare IP-adres van de virtuele netwerkgateway toegevoegd aan de routetabel. Verkeer dat wordt verzonden naar een adres tussen 10.10.0.1 en 10.10.255.254 wordt doorgestuurd naar de virtuele netwerkgateway. Het voorvoegsel is langer dan 0.0.0.0/0 en komt niet overeen met de adresvoorvoegsels van een van de andere routes. Er is een virtuele netwerkgateway gemaakt om te voldoen aan vereiste 2.

  • Id9: Azure heeft deze route toegevoegd wanneer een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 10.10.0.0/16 is toegevoegd aan de routetabel die is gekoppeld aan Subnet1. Deze route vervangt ID8. De route verzendt al het verkeer dat is bestemd voor het on-premises netwerk naar een NVA voor inspectie, in plaats van verkeer rechtstreeks on-premises te routeren. Deze route is gemaakt om te voldoen aan vereiste 3.

  • ID10: Azure heeft deze route automatisch toegevoegd aan het subnet wanneer een service-eindpunt aan een Azure-service is ingeschakeld voor het subnet. Verkeer vanuit het subnet wordt door Azure omgeleid naar een openbaar IP-adres van de service, via het infrastructuurnetwerk van Azure. Het voorvoegsel is langer dan 0.0.0.0/0 en komt niet overeen met de adresvoorvoegsels van een van de andere routes. Er is een service-eindpunt gemaakt om te voldoen aan vereiste 3, waarmee verkeer dat is bestemd voor Azure Storage rechtstreeks naar Azure-opslag kan worden gestuurd.

  • ID11: Azure heeft deze route automatisch toegevoegd aan de routetabel van alle subnetten in Virtual-network-1 en Virtual-network-2. Het adresvoorvoegsel 0.0.0.0/0 is het kortste voorvoegsel. Verkeer dat wordt verzonden naar adressen met een langer adresvoorvoegsel worden gerouteerd op basis van andere routes. De standaardinstelling is dat Azure al het verkeer dat is bestemd voor andere adressen dan de adressen die zijn opgegeven in een van de andere routes naar internet stuurt. Azure heeft de status voor Subnet1 automatisch gewijzigd van Actief in Ongeldig op het moment dat een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 0.0.0.0/0 (ID12) werd gekoppeld aan het subnet. De status van deze route is nog steeds Actief voor alle andere subnetten in beide virtuele netwerken. De reden hiervoor is dat de route niet is gekoppeld aan andere subnetten van andere virtuele netwerken.

  • ID12: Azure heeft deze route toegevoegd wanneer een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 0.0.0.0/0 is gekoppeld aan het subnet1-subnet . In de door de gebruiker gedefinieerde route is 10.0.100.4 ingesteld als het IP-adres van het virtuele apparaat. Deze route is niet gekoppeld aan Subnet2, dus de route wordt niet weergegeven in de routetabel voor Subnet2. Al het verkeer voor adressen die niet overeenkomen met de adresvoorvoegsels van een andere route wordt verzonden naar het virtuele apparaat. Door het toevoegen van deze route is de status van de standaardroute voor het adresvoorvoegsel 0.0.0.0/0 (ID11) gewijzigd van Actief in Ongeldig voor Subnet1. De reden hiervoor is dat een door de gebruiker gedefinieerde route prioriteit heeft boven een standaardroute. Deze route bestaat om te voldoen aan de derde vereiste.

Subnet2

De routetabel voor Subnet2 in de afbeelding bevat de volgende routes:

Bron Staat Adresvoorvoegsels Volgend hoptype IP-adres van volgende hop
Standaardinstelling Actief 10.0.0.0/16 Virtueel netwerk
Standaardinstelling Actief 10.1.0.0/16 Peering op virtueel netwerk
Standaardinstelling Actief 10.2.0.0/16 Peering op virtueel netwerk
Standaardinstelling Actief 10.10.0.0/16 Gateway voor een virtueel netwerk [X.X.X.X]
Standaardinstelling Actief 0.0.0.0/0 Internet
Standaardinstelling Actief 10.0.0.0/8 Geen
Standaardinstelling Actief 100.64.0.0/10 Geen
Standaardinstelling Actief 192.168.0.0/16 Geen

De routetabel voor Subnet2 bevat alle door Azure gemaakte standaardroutes en de optionele peering van virtuele netwerken en optionele routes voor virtuele netwerkgateway. Azure heeft de optionele routes toegevoegd aan alle subnetten in het virtuele netwerk op het moment dat de gateway en peering werden toegevoegd aan het virtuele netwerk. Azure heeft de routes voor de adresvoorvoegsels 10.0.0.0/8, 192.168.0.0/16 en 100.64.0.0/10 uit de routetabel Subnet1 verwijderd wanneer de door de gebruiker gedefinieerde route voor het adresvoorvoegsel 0.0.0.0/0 is toegevoegd aan Subnet1.

Volgende stappen