Routering van verkeer in virtuele netwerken
In dit artikel leert u hoe Azure verkeer routeert tussen Azure-, on-premises en internetbronnen. 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 geen systeemroutes maken en u kunt systeemroutes niet verwijderen, maar u kunt bepaalde systeemroutes overschrijven met 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 verkeer dat een subnet verlaat, wordt verzonden naar een IP-adres binnen het adresvoorvoegsel van een route, is de route die het voorvoegsel bevat de route die door Azure wordt gebruikt. Meer informatie over hoe Azure een route selecteert wanneer meerdere routes dezelfde voorvoegsels of overlappende voorvoegsels bevatten. 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. Hier volgen verklaringen voor de volgende hoptypen:
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. Standaard routeert Azure verkeer tussen subnetten. U hoeft geen routetabellen of gateways te definiëren voor Azure om verkeer tussen subnetten te routeren. Azure maakt geen standaardroutes voor subnetadresbereiken. Elk subnetadresbereik bevindt zich binnen een adresbereik van de adresruimte van een virtueel netwerk.
Internet: routeert verkeer dat is opgegeven door 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 voor een Azure-service is, routeert Azure het verkeer rechtstreeks naar de service via het Backbone-netwerk van Azure in plaats van het verkeer naar internet te routeren. Verkeer tussen Azure-services gaat niet via internet. Het maakt niet uit 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 overschrijven voor het adresvoorvoegsel 0.0.0.0/0 met een aangepaste route.
Geen: verkeer dat wordt doorgestuurd naar het type Volgende hop None wordt verwijderd in plaats van buiten het subnet te worden 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 aan specifieke subnetten binnen het virtuele netwerk of aan alle subnetten binnen een virtueel netwerk. De volgende tabel bevat de andere systeemroutes en volgende hoptypen die Azure kan toevoegen wanneer u verschillende mogelijkheden inschakelt.
| 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 | Peering op virtueel netwerk | Alle |
| Gateway voor een virtueel netwerk | Voorvoegsels die worden geadverteerd vanuit on-premises via Border Gateway Protocol (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 |
Peering van virtuele netwerken: wanneer u een peering van een virtueel netwerk tussen twee virtuele netwerken maakt, wordt er een route toegevoegd 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 een virtuele netwerkgateway omdat de gateway de routes aan het subnet toevoegt. Als uw on-premises netwerkgateway BGP-routes 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 grootste adresbereik dat mogelijk is, 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 Azure-limieten voor meer informatie.
VirtualNetworkServiceEndpoint: De openbare IP-adressen voor bepaalde services worden door Azure toegevoegd aan de routetabel wanneer u een service-eindpunt voor de service inschakelt. Service-eindpunten zijn 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. Meer informatie over service-eindpunten voor virtuele netwerken en de services waarvoor u service-eindpunten kunt maken.Notitie
De peering van virtuele netwerken en
VirtualNetworkServiceEndpointde volgende hoptypen worden alleen toegevoegd aan routetabellen van subnetten binnen virtuele netwerken die zijn gemaakt via het Azure Resource Manager-implementatiemodel. 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 (UDR's) te maken of BGP-routes uit te wisselen tussen uw on-premises netwerkgateway en een virtuele Azure-netwerkgateway.
Eigen definitie
Als u uw verkeersroutes wilt aanpassen, moet u de standaardroutes niet wijzigen. U moet aangepaste of door de gebruiker gedefinieerde (statische) routes maken, waardoor de standaardsysteemroutes van Azure worden overschreven. In Azure maakt u een routetabel en koppelt u de routetabel aan nul of meer subnetten van virtuele netwerken. Elk subnet kan zijn gekoppeld aan geen enkele of één routetabel. Zie Azure-limieten voor meer informatie over het maximum aantal routes dat u kunt toevoegen aan een routetabel en het maximum aantal UDR-tabellen dat u per Azure-abonnement kunt maken.
Standaard kan een routetabel maximaal 400 UDR's bevatten. Met de routeringsconfiguratie van Azure Virtual Network Manager kan dit aantal worden uitgebreid naar 1000 UDR's per routetabel. Deze verhoogde limiet biedt ondersteuning voor geavanceerdere routeringsinstellingen. Een voorbeeld is het omleiden van verkeer van on-premises datacenters via een firewall naar elk virtueel spoke-netwerk in een hub-and-spoke-topologie wanneer u een hoger aantal virtuele spoke-netwerken hebt.
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 UDR's de standaardroutes.
U kunt de volgende hoptypen opgeven wanneer u een UDR maakt:
Virtueel apparaat: een virtueel apparaat is een virtuele machine waarop meestal een netwerktoepassing wordt uitgevoerd, zoals een firewall. Zie 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 van het virtuele apparaat , geeft u ook een IP-adres voor de volgende hop op. 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. Met de instelling wordt de controle van de bron en het doel voor een netwerkinterface door Azure uitgeschakeld. Lees hier meer over het inschakelen van doorsturen via IP voor een netwerkinterface. Doorsturen via IP inschakelen is een Azure-instelling.
Mogelijk moet u doorsturen via IP inschakelen binnen 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. Als u het virtuele apparaat implementeert in hetzelfde subnet en vervolgens een routetabel toepast op het subnet waarmee verkeer via het virtuele apparaat wordt gerouteerd, kan dit leiden tot routeringslussen waarbij verkeer nooit het subnet verlaat.
Een privé-IP-adres van de volgende hop moet directe connectiviteit hebben zonder dat u hoeft te routeren via een Azure ExpressRoute-gateway of via Azure Virtual WAN. Als u de volgende hop instelt op een IP-adres zonder directe connectiviteit, resulteert dit in een ongeldige UDR-configuratie.
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 voor 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 een UDR wilt maken die het adresvoorvoegsel 0.0.0.0/0 bevat, leest u eerst het adresvoorvoegsel 0.0.0.0/0.
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 UDR, omdat u met ExpressRoute BGP moet gebruiken voor aangepaste routes. U kunt geen gateways voor virtuele netwerken opgeven als u vpn-verbindingen (virtual private network) en ExpressRoute 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 een UDR wilt maken voor het adresvoorvoegsel 0.0.0.0/0, leest u eerst het adresvoorvoegsel 0.0.0.0/0. In plaats van een UDR te configureren voor het adresvoorvoegsel 0.0.0.0/0, kunt u een route adverteren met het voorvoegsel 0.0.0.0/0 via BGP als de BGP voor een virtuele VPN-netwerkgateway is ingeschakeld.
Geen: gebruik dit type als u het verkeer naar een adresvoorvoegsel wilt verwijderen, in plaats van het verkeer door te sturen naar een bestemming. Azure kan Geen weergeven voor sommige optionele systeemroutes als een mogelijkheid niet is geconfigureerd. Als u bijvoorbeeld ziet dat het IP-adres van de volgende hop geen en het type Volgende hop de gateway of het virtuele apparaat weergeeft, kan dit zijn omdat het apparaat niet actief is 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 kunt maken met het type hop van het virtuele netwerk.
Internet: Geef de internetoptie op wanneer u verkeer dat is bestemd voor een adresvoorvoegsel naar internet expliciet wilt routeren. Of gebruik het als u verkeer wilt dat is bestemd voor Azure-services met openbare IP-adressen die binnen het Backbone-netwerk van Azure worden bewaard.
U kunt geen peering voor virtuele netwerken opgeven of VirtualNetworkServiceEndpoint als het type volgende hop in UDR's. Azure maakt routes met peering van virtuele netwerken of VirtualNetworkServiceEndpoint volgende hoptypen alleen wanneer u een 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 UDR in plaats van een expliciet IP-bereik. Een servicetag vertegenwoordigt een groep IP-adresvoorvoegsels van een specifieke Azure-service. Microsoft beheert de adresvoorvoegsels die worden omvat door de servicetag en werkt de servicetag automatisch bij wanneer adressen worden gewijzigd. Deze ondersteuning minimaliseert de complexiteit van frequente updates voor UDR's en vermindert 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 tussen een route met een expliciet IP-voorvoegsel en een route met een servicetag is. Wanneer meerdere routes met servicetags overeenkomende IP-voorvoegsels hebben, worden routes in de volgende volgorde geëvalueerd:
Regionale tags (bijvoorbeeld
Storage.EastUSofAppService.AustraliaCentral)Tags op het hoogste niveau (bijvoorbeeld
StorageofAppService)AzureCloudregionale tags (bijvoorbeeldAzureCloud.canadacentralofAzureCloud.eastasia)De
AzureCloudtag
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, door deze opdracht te gebruiken:
$param = @{
Name = 'StorageRoute'
AddressPrefix = 'Storage'
NextHopType = 'VirtualAppliance'
NextHopIpAddress = '10.0.100.4'
}
New-AzRouteConfig @param
Dezelfde opdracht voor de Azure CLI is:
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, verschilt tussen Azure Portal en opdrachtregelprogramma's, en de Resource Manager- en klassieke implementatiemodellen. De volgende tabel bevat de namen die worden gebruikt om naar elk volgend hoptype te verwijzen met 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 de klassieke implementatiemodelmodus) |
| Internet | Internet | Internet (niet beschikbaar in de klassieke CLI in de klassieke implementatiemodelmodus) |
| Virtueel apparaat | VirtualAppliance |
VirtualAppliance |
| Geen | Geen | Null (niet beschikbaar in de klassieke CLI in de klassieke implementatiemodelmodus) |
| Peering op virtueel netwerk | Peering op virtueel netwerk | Niet van toepassing |
| Service-eindpunt voor virtueel netwerk | VirtualNetworkServiceEndpoint |
Niet van toepassing |
Border Gateway Protocol
Een on-premises netwerkgateway kan routes uitwisselen met een virtuele Azure-netwerkgateway met behulp van de BGP. 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 UDR's maken om verkeer naar de gateway van het virtuele ExpressRoute-netwerk af te dwingen als u een virtuele netwerkgateway implementeert die is geïmplementeerd als het type ExpressRoute. U kunt UDR's gebruiken voor het afdwingen van verkeer van de expressroute naar bijvoorbeeld een virtueel netwerkapparaat.
- VPN: Optioneel kunt u BGP gebruiken. Zie BGP met site-naar-site-VPN-verbindingen voor meer informatie.
Wanneer u routes uitwisselt met Azure met behulp van BGP, wordt er een afzonderlijke route toegevoegd aan de routetabel van alle subnetten in een virtueel netwerk voor elk geadverteerd voorvoegsel. De route wordt toegevoegd met Gateway van virtueel netwerk als de bron en het 'volgende hoptype'.
U kunt ExpressRoute- en Azure VPN Gateway-routedoorgifte op een subnet uitschakelen met behulp van een eigenschap in een routetabel. 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 virtuele netwerkgateway. Zie Routedoorgifte van virtuele netwerkgateway uitschakelen voor meer informatie.
Notitie
Routedoorgifte mag niet worden uitgeschakeld op GatewaySubnet. De gateway werkt niet als deze instelling is uitgeschakeld.
Hoe Azure een route selecteert
Wanneer uitgaand verkeer vanuit een subnet wordt verzonden, selecteert Azure een route op basis van het doel-IP-adres met behulp van het langste algoritme voor het vergelijken van voorvoegsels. Een routetabel heeft bijvoorbeeld twee routes. Een route geeft het adresvoorvoegsel 10.0.0.0/24 op en de andere route geeft het adresvoorvoegsel 10.0.0.0/16 op.
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:
Door de gebruiker gedefinieerde route
BGP-route
Systeemroute
Notitie
Systeemroutes voor verkeer met betrekking tot virtueel netwerk, peerings van virtuele netwerken of service-eindpunten voor virtuele netwerken zijn voorkeursroutes. Ze hebben de voorkeur, zelfs als BGP-routes specifieker zijn. Routes met een service-eindpunt voor een virtueel netwerk als het volgende hoptype kunnen niet worden overschreven, zelfs niet wanneer u een routetabel gebruikt.
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 is bestemd voor een IP-adres buiten de adresvoorvoegsels van andere routes in de routetabel, selecteert Azure de route met de gebruikersbron . Azure maakt deze keuze omdat UDR's een hogere prioriteit hebben dan systeemstandaardroutes.
Zie het voorbeeld van routering voor een uitgebreide routeringstabel met uitleg over 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, routeert 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 wordt doorgestuurd naar internet. 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, loopt uitgaand verkeer van het subnet via de virtuele netwerkgateway of het virtuele apparaat. De volgende wijzigingen treden ook op bij 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, verlaat het verkeer van het subnet dat is bestemd voor de openbare IP-adressen van Azure-services nooit het Backbone-netwerk van Azure, ongeacht de Azure-regio waarin het virtuele netwerk of de Azure-serviceresource bestaat.
Wanneer u een UDR- of BGP-route maakt met een gateway van een virtueel netwerk of het volgende hoptype van het virtuele apparaat, wordt al het verkeer verzonden naar het volgende hoptype dat is opgegeven in de route. Dit omvat verkeer dat wordt verzonden naar openbare IP-adressen van Azure-services waarvoor u geen service-eindpunten hebt ingeschakeld.
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:
- Toegankelijk zijn via internet.
- Er is een openbaar IP-adres aan toegewezen.
- Er is geen netwerkbeveiligingsgroepregel aan gekoppeld die communicatie met het apparaat voorkomt.
- De communicatie niet weigeren.
- Kan netwerkadres vertalen en doorsturen, of proxy het verkeer naar de doelresource in het subnet en retourneer het verkeer terug naar internet.
Virtuele netwerkgateway: als de gateway een virtuele ExpressRoute-netwerkgateway is, kan een on-premises apparaat dat is verbonden met internet, het netwerkadres vertalen en doorsturen of het verkeer doorsturen naar de doelresource in het subnet, via persoonlijke ExpressRoute-peering.
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 Waarom worden bepaalde poorten geopend op mijn VPN-gateway? voor meer informatie.
Zie DMZ tussen Azure en uw on-premises datacenter voor informatie over de implementatie wanneer u virtuele netwerkgateways gebruikt tussen internet en Azure.
Voorbeeld van routering
Om de concepten in dit artikel te illustreren, beschrijven de volgende secties:
- Een scenario met vereisten.
- De aangepaste routes die nodig zijn om te voldoen aan de vereisten.
- De routetabel die bestaat voor één subnet dat de standaard- en aangepaste routes bevat die nodig zijn om te voldoen aan de vereisten.
Notitie
Dit voorbeeld is niet bedoeld om een aanbevolen of best practices-implementatie te zijn. Het is alleen beschikbaar om concepten in dit artikel te illustreren.
Vereisten
Implementeer twee virtuele netwerken in dezelfde Azure-regio en zorg dat resources kunnen communiceren tussen de virtuele netwerken.
Schakel een on-premises netwerk in om veilig te communiceren met beide virtuele netwerken via een VPN-tunnel via internet. U kunt ook een ExpressRoute-verbinding gebruiken, maar in dit voorbeeld wordt een VPN-verbinding gebruikt.
Voor één subnet in één virtueel netwerk:
- Routeer al het uitgaande verkeer van het subnet via een virtueel netwerkapparaat voor inspectie en logboekregistratie. Sluit verkeer uit naar Azure Storage en binnen het subnet van deze routering.
- 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.
- Schakel uitgaand verkeer naar Azure Storage in om rechtstreeks naar de opslag te stromen, zonder dit af te dwingen via een virtueel netwerkapparaat.
Sta al het verkeer tussen alle andere subnetten en virtuele netwerken toe.
Implementatie
In het volgende diagram ziet u een implementatie via het Resource Manager-implementatiemodel dat voldoet aan de vorige vereisten.
De pijlen geven de richting van het verkeer aan.
Routetabellen
Hier volgen de routetabellen voor het voorgaande routeringsvoorbeeld.
Subnet1
De routetabel voor Subnet1 in het voorgaande diagram bevat de volgende routes:
| Id | Bron | Provincie | Adresvoorvoegsels | Volgend hoptype | IP-adres van volgende hop | UDR-naam |
|---|---|---|---|---|---|---|
| 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 | Peering op virtueel netwerk | ||
| 5 | Standaardinstelling | Ongeldig | 10.2.0.0/16 | Peering op virtueel netwerk | ||
| 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 UDR niet in route ID2 maakt, wordt verkeer dat wordt verzonden naar een adres tussen 10.0.0.1 en 10.0.255.254 gerouteerd binnen het virtuele netwerk. Dit proces treedt op omdat 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, wanneer ID2, een UDR, is toegevoegd. Het heeft hetzelfde voorvoegsel als de standaardroute en UDR's overschrijven standaardroutes. De status van deze route is nog steeds actief voor Subnet2 omdat de routetabel waarin de UDR, ID2, zich bevindt, niet is gekoppeld aan Subnet2.
ID2: Azure heeft deze route toegevoegd wanneer een UDR voor het adresvoorvoegsel 10.0.0.0/16 is gekoppeld aan het subnet1-subnet in het virtuele netwerk-1 van het virtuele netwerk. De UDR geeft 10.0.100.4 op als het IP-adres van het virtuele apparaat, omdat het adres het privé-IP-adres is dat is toegewezen aan de virtuele machine van het virtuele apparaat. De routetabel waarin deze route bestaat, is niet gekoppeld aan Subnet2, dus de route 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, namelijk om al het uitgaande verkeer via een virtueel apparaat af te dwingen.
Id3: Azure heeft deze route toegevoegd wanneer een UDR 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. Het verkeer wordt niet doorgestuurd naar het virtuele apparaat dat is opgegeven in de vorige regel (ID2), omdat het een langer voorvoegsel heeft dan de ID2-route.
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 is 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, dus Azure heeft een route toegevoegd voor elk bereik. Als u de UDR's niet maakt in route-id's 6 en 7, wordt verkeer verzonden naar een adres tussen 10.1.0.1-10.1.255.254 en 10.2.0.1-10.2.255.254 naar het gekoppelde virtuele netwerk. Dit proces treedt op omdat 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 treedt op omdat ze dezelfde voorvoegsels hebben als de routes in id's 4 en 5, en UDR's standaardroutes overschrijven. De status van de routes in id's 4 en 5 is nog steeds actief voor Subnet2 omdat de routetabel waarin de UDR's in id's 6 en 7 niet zijn 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 UDR's 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 UDR's 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 er een UDR 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 bestemd is voor het on-premises netwerk naar een virtueel netwerkapparaat 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 om verkeer dat is bestemd voor Azure Storage, rechtstreeks naar Azure Storage te laten stromen.
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.
Standaard routeert Azure al het verkeer dat is bestemd voor andere adressen dan de adressen die zijn opgegeven in een van de andere routes naar internet. Azure heeft de status automatisch gewijzigd van Actief in Ongeldig voor het subnet1-subnet wanneer er een UDR voor het adresvoorvoegsel 0.0.0.0/0 (ID12) aan het subnet is gekoppeld. De status van deze route is nog steeds actief voor alle andere subnetten binnen beide virtuele netwerken, omdat de route niet is gekoppeld aan andere subnetten binnen andere virtuele netwerken.
ID12: Azure heeft deze route toegevoegd wanneer een UDR voor het adresvoorvoegsel 0.0.0.0/0 is gekoppeld aan het subnet1-subnet . De UDR geeft 10.0.100.4 op 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.
De toevoeging van deze route heeft de status van de standaardroute voor het adresvoorvoegsel 0.0.0.0/0 (ID11) gewijzigd van Actief in Ongeldig voor Subnet1 omdat een UDR een standaardroute overschrijft. Deze route bestaat om te voldoen aan vereiste 3.
Subnet2
De routetabel voor Subnet2 in het voorgaande diagram bevat de volgende routes:
| Bron | Provincie | 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 verwijderd voor de adresvoorvoegsels 10.0.0.0/8, 192.168.0.0/16 en 100.64.0.0/10 uit de routetabel Subnet1 wanneer de UDR voor het adresvoorvoegsel 0.0.0.0/0 is toegevoegd aan Subnet1.
Gerelateerde inhoud
- Maak een UDR-tabel met routes en een virtueel netwerkapparaat.
- Configureer BGP voor een Azure VPN Gateway.
- Gebruik BGP met ExpressRoute.
- Alle routes weergeven voor een subnet. In een UDR-tabel ziet u alleen de UDR's, niet de standaard- en BGP-routes voor een subnet. Als u alle routes bekijkt, ziet u de standaard-, BGP- en UDR's voor het subnet waarin een netwerkinterface zich bevindt.
- Het 'volgende hoptype' bepalen tussen een virtuele machine en een doel-IP-adres. U kunt de volgende hopfunctie van Azure Network Watcher gebruiken om te bepalen of verkeer een subnet verlaat en wordt gerouteerd naar de gewenste locatie.