Routering van verkeer in virtuele netwerken

  • Artikel
  • 27 minuten om te lezen

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

Standaard

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
Standaard Uniek voor het virtuele netwerk Virtueel netwerk
Standaard 0.0.0.0/0 Internet
Standaard 10.0.0.0/8 Geen
Standaard 172.16.0.0/12 Geen
Standaard 192.168.0.0/16 Geen
Standaard 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. Dit komt doordat elk subnetadresbereik zich binnen een adresbereik van de adresruimte van een virtueel netwerk bevindt.

  • 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, stuurt Azure verkeer voor een adres dat niet is opgegeven door een adresbereik binnen een virtueel netwerk, naar internet. Met één uitzondering. 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 is 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
Standaard Uniek is voor het virtuele netwerk, bijvoorbeeld: 10.1.0.0/16 VNet-peering Alles
Gateway van een virtueel netwerk Voorvoegsels geadverteerd van on-premises via BGP of geconfigureerd in de lokale netwerkgateway Gateway van een virtueel netwerk Alles
Standaard Meerdere VirtualNetworkServiceEndpoint Alleen het subnet waarvoor een service-eindpunt is ingeschakeld.

  • VNet-peering: wanneer u een VNet-peering maakt tussen twee virtuele netwerken, wordt er een route toegevoegd voor elk adresbereik in de adresruimte van elk virtueel netwerk waarvoor een peering wordt gemaakt. 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 Azure-netwerkgateway, wordt er een route toegevoegd voor elke route die wordt doorgegeven vanuit de on-premises netwerkgateway. Het is raadzaam dat u on-premises routes samenvat tot de grootst mogelijke adresbereiken, zodat het kleinste aantal routes wordt doorgegeven aan de 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 Azure-implementatiemodellen.

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.

Door de gebruiker gedefinieerde routes

U kunt aangepaste of door de gebruiker gedefinieerde (statische) routes in Azure maken om de standaardsysteemroutes van Azure te overschrijven 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 moet routeren naar een openbaar IP-adres, moet het een proxy uitvoeren op het verkeer of het netwerkadres omzetten in het privé IP-adres van het privé IP-adres van de bron in een eigen privé-IP-adres, waarvan Azure het netwerkadres vervolgens omzet in 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 vervolgens het toepassen van een routetabel op het subnet waarmee verkeer via het virtuele apparaat wordt gerouteerd, kan leiden tot routeringslussen waarbij verkeer het subnet nooit verlaat.

      Een privé-IP-adres van de volgende hop moet een directe verbinding hebben zonder te hoeven routeren via de ExpressRoute-gateway of Virtual WAN. 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 als het adresvoorvoegsel definiëren en het 'volgende hoptype' Virtueel apparaat. Het apparaat kan dan het gegevensverkeer inspecteren en bepalen of dit 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 het type ExpressRoute in een door de gebruiker gedefinieerde route, omdat u met ExpressRoute BGP moet gebruiken voor aangepaste routes. U kunt Virtual Network gateways niet opgeven als u beide VPN- en ExpressRoute-verbindingen 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: kies dit type wanneer u de standaardroutering binnen een virtueel netwerk wilt vervangen. Zie Voorbeeld van routering voor een voorbeeld van waarom u een route met het hoptype Virtueel netwerk zou maken.

  • Internet: gebruik dit type als u verkeer dat is bestemd voor een adresvoorvoegsel expliciet naar internet wilt routeren, of als u verkeer dat is bestemd voor Azure-services met openbare IP-adressen binnen het backbone-netwerk van Azure wilt houden.

U kunt VNet-peering of VirtualNetworkServiceEndpoint niet opgeven als het volgende hoptype in door de gebruiker gedefinieerde routes. Routes met het hoptype VNet-peering of VirtualNetworkServiceEndpoint worden alleen gemaakt door Azure, wanneer u peering van virtuele netwerken 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 servicelabel vertegenwoordigt een groep IP-adresvoorvoegsels van een bepaalde Azure-service. Microsoft beheert de adresvoorvoegsels die worden omsloten door de servicetag en werkt de servicetag automatisch bij wanneer adressen veranderen. Zo minimaliseert u de complexiteit van frequente updates van door de gebruiker gedefinieerde routes en vermindert u het aantal routes dat u moet maken. U kunt momenteel 25 of minder routes met servicetags maken in elke routetabel. In deze release wordt het gebruik van servicetags in routeringsscenario's voor containers ook ondersteund.

Exacte overeenkomst

Wanneer er een exacte overeenkomst is tussen een route met een expliciet IP-voorvoegsel en een route met een servicetag, wordt de voorkeur gegeven aan de route met het expliciete voorvoegsel. 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 AzureCloud-tags (bijvoorbeeld AzureCloud.canadacentral, AzureCloud.eastasia)
  4. De AzureCloud-tag

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

New-AzRouteConfig -Name "StorageRoute" -AddressPrefix "Storage" -NextHopType "VirtualAppliance" -NextHopIpAddress "10.0.100.4"

Dezelfde opdracht voor CLI is:

az network route-table route create -g MyResourceGroup --route-table-name MyRouteTable -n 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 van 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 servicebeheermodus)
Virtueel apparaat VirtualAppliance VirtualAppliance
Geen Geen Null (niet beschikbaar in de klassieke CLI in 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 de gateway van een virtueel Azure-netwerk is afhankelijk van het type dat u hebt geselecteerd tijdens het maken van de gateway. Als het geselecteerde type is:

  • 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 eventueel 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 virtuele netwerkgateway vermeld als het bron- en volgende hoptype.

Doorgave van ER- en VPN Gateway-route kan worden uitgeschakeld op een subnet met behulp van een eigenschap in een routeringstabel. Wanneer routedoorgifte is uitgeschakeld, worden routes niet toegevoegd aan de routetabel van alle subnetten waarvoor routering van virtuele netwerkgateway is uitgeschakeld (zowel statische routes als BGP-routes). Connectiviteit met VPN-verbindingen wordt bereikt met behulp van aangepaste routes met een volgend hoptype van virtuele netwerkgateway. Het doorgeven van routes moet niet worden uitgeschakeld in 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 omdat 10.0.0.0/24 een langer voorvoegsel is dan 10.0.0.0/16, ondanks dat 10.0.0.5 is opgenomen in 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 omdat 10.0.1.5 niet is opgenomen in het adresvoorvoegsel 10.0.0.0/24. Om die reden is de route met het adresvoorvoegsel 10.0.0.0/16 het langste overeenkomende voorvoegsel.

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
Standaard 0.0.0.0/0 Internet
Gebruiker 0.0.0.0/0 Gateway van 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 Azure instructies voor het routeren van verkeer dat is bestemd voor een IP-adres dat zich niet binnen het adresvoorvoegsel van een andere route in de routetabel van een subnet bevindt. Wanneer een subnet wordt gemaakt, maakt Azure een standaardroute naar het adresvoorvoegsel 0.0.0.0/0, met 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 is dat verkeer naar de openbare IP-adressen van Azure-services op het Azure-backbone-netwerk blijft en niet naar internet wordt gerouteerd. Als u deze route overschrijft door een aangepaste route, wordt verkeer dat is bestemd voor adressen die geen deel uitmaken van de adresvoorvoegsels van een andere route in de routetabel verzonden naar een virtueel netwerkapparaat of een virtuele netwerkgateway, afhankelijk van wat u opgeeft in de aangepaste route.

Wanneer u het adresvoorvoegsel 0.0.0.0/0 overschrijft, wordt de standaardroutering van Azure als volgt aangepast, in aanvulling op het omleiden van het uitgaande verkeer van het subnet via de virtuele netwerkgateway of het virtuele apparaat:

  • 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. Als u een service-eindpunt voor een service hebt ingeschakeld, wordt verkeer naar de service niet doorgestuurd naar het volgende hoptype in een route met het adresvoorvoegsel 0.0.0.0/0, omdat adresvoorvoegsels voor de service worden opgegeven in de route die Azure maakt wanneer u het service-eindpunt inschakelt, en de adresvoorvoegsels voor de service langer zijn dan 0.0.0.0/0.

  • U hebt geen rechtstreekse toegang meer tot resources in het subnet vanaf internet. U kunt indirect vanaf internet toegang krijgen tot resources in het subnet als binnenkomend verkeer wordt doorgegeven via het apparaat dat is opgegeven door het 'volgende hoptype' voor een route met het adresvoorvoegsel 0.0.0.0/0 voordat de resource in het virtuele netwerk wordt bereikt. 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 met een route met als doel 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 als een aanbevolen implementatie of best practice-implementatie. 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:

Netwerkdiagram

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 Standaard Ongeldig 10.0.0.0/16 Virtueel netwerk
2 Gebruiker Actief 10.0.0.0/16 Virtueel apparaat 10.0.100.4 Within-VNet1
3 Gebruiker Actief 10.0.0.0/24 Virtueel netwerk Within-Subnet1
4 Standaard Ongeldig 10.1.0.0/16 VNet-peering
5 Standaard Ongeldig 10.2.0.0/16 VNet-peering
6 Gebruiker Actief 10.1.0.0/16 Geen ToVNet2-1-Drop
7 Gebruiker Actief 10.2.0.0/16 Geen ToVNet2-2-Drop
8 Standaard Ongeldig 10.10.0.0/16 Gateway van een virtueel netwerk [X.X.X.X]
9 Gebruiker Actief 10.10.0.0/16 Virtueel apparaat 10.0.100.4 To-On-Prem
10 Standaard Actief [X.X.X.X] VirtualNetworkServiceEndpoint
11 Standaard Ongeldig 0.0.0.0/0 Internet
12 Gebruiker 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 de door de gebruiker gedefinieerde route in route ID2 niet zou zijn gemaakt, zou verkeer dat wordt verzonden naar een adres tussen 10.0.0.1 en 10.0.255.254 worden gerouteerd binnen het virtuele netwerk omdat het voorvoegsel langer is dan 0.0.0.0/0 en niet overeenkomt met de adresvoorvoegsels van een van de andere routes. 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 subnet Subnet1 in het virtuele netwerk Virtual-network-1 . 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 en wordt daarom 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 subnet Subnet1 . 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 in id's 4 en 5 toegevoegd voor alle subnetten in Virtual-network-1, toen het virtuele netwerk werd gekoppeld met 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 de door de gebruiker gedefinieerde routes in route-id's 6 en 7 niet zouden zijn gemaakt, zou 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 worden gerouteerd naar het via peering gekoppelde virtuele netwerk omdat het voorvoegsel langer is dan 0.0.0.0/0 en niet overeenkomt met de adresvoorvoegsels van een van de andere routes. Azure heeft de status automatisch gewijzigd van Actief in Ongeldig op het moment dat de routes in id's 6 en 7 werden toegevoegd. De reden hiervoor is dat deze routes hetzelfde voorvoegsel hebben als de routes in id's 4 en 5, en door de gebruiker gedefinieerde routes hebben prioriteit boven standaardroutes. 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 aan het subnet Subnet1 zijn gekoppeld. Verkeer dat is bestemd voor adressen tussen 10.1.0.1-10.1.255.254 en 10.2.0.1-10.2.255.254 wordt verwijderd door Azure, en wordt dus niet doorgestuurd naar de via peering gekoppelde virtuele netwerken. De reden hiervoor is dat door de gebruiker gedefinieerde routes standaardroutes vervangen. 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 toen een door de gebruiker gedefinieerde route voor het adresvoorvoegsel 10.10.0.0/16 werd 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 voor 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 subnet Subnet1 . 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
Standaard Actief 10.0.0.0/16 Virtueel netwerk
Standaard Actief 10.1.0.0/16 VNet-peering
Standaard Actief 10.2.0.0/16 VNet-peering
Standaard Actief 10.10.0.0/16 Gateway van een virtueel netwerk [X.X.X.X]
Standaard Actief 0.0.0.0/0 Internet
Standaard Actief 10.0.0.0/8 Geen
Standaard Actief 100.64.0.0/10 Geen
Standaard Actief 192.168.0.0/16 Geen

De routetabel voor Subnet2 bevat alle standaardroutes van Azure, plus de optionele routes Virtual network peering en VPN Gateway. 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 toen de door de gebruiker gedefinieerde route voor het adresvoorvoegsel 0.0.0.0/0 is toegevoegd aan Subnet1.

Volgende stappen