UDR's (User-Defined Routes) plannen en implementeren
U kunt aangepaste of door de gebruiker gedefinieerde (statische) routes maken in Azure 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 aan geen of één routetabel gekoppeld zijn. Zie Azure-limieten 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. Meer informatie 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 ofwel het verkeer proxieën of NAT (Network Address Translation) uitvoeren van het privé-IP-adres van de bron naar zijn 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 Informatie over uitgaande verbindingen in Azure voor meer informatie over uitgaande verbindingen.
- 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.
- 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. Meer informatie 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 ofwel het verkeer proxieën of NAT (Network Address Translation) uitvoeren van het privé-IP-adres van de bron naar zijn 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 Informatie over uitgaande verbindingen in Azure voor meer informatie over uitgaande verbindingen.
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.
- 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. Zie het voorbeeld van routering, voor een voorbeeld van waarom u een route kunt maken met het hoptype virtueel netwerk.
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:
- Regionale tags (bijvoorbeeld Storage.EastUS, AppService.AustraliaCentral)
- Tags op het hoogste niveau (bijvoorbeeld Storage, AppService)
- Regionale tags van AzureCloud (bijvoorbeeld AzureCloud.canadacentral, AzureCloud.eastasia)
- 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 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.
Tabel uitvouwen
| Volgend hoptype | Azure CLI en PowerShell (Resource Manager) | Klassieke Azure CLI 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) |
| Virtueel netwerk-peering | Virtueel netwerk-peering | 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 door aangepaste routes met een next hop-type van virtuele netwerkgateway. Zie Routedoorgifte van virtuele netwerkgateway uitschakelen voor meer informatie.
Opmerking
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
Opmerking
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:
Tabel uitvouwen
| Bron | Adresvoorvoegsels | Volgend hoptype |
|---|---|---|
| Verstek | 0.0.0.0/0 | Internet |
| Gebruiker | 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 een subnet wordt gemaakt, maakt Azure een standaardroute naar het adresprefix 0.0.0.0/0, met de volgende hoptype naar 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: Het apparaat moet:
- 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. Door dit te doen kan de gateway niet goed functioneren. 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.
Opmerking
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.
Behoeften
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.
Opmerking
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:
Tabel uitvouwen
| ID | Bron | Staat | Adresvoorvoegsels | Volgend hoptype | IP-adres van de volgende hop | UDR-naam |
|---|---|---|---|---|---|---|
| 1 | Verstek | 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 | Verstek | Ongeldig | 10.1.0.0/16 | Virtueel netwerk-peering | ||
| 5 | Verstek | Ongeldig | 10.2.0.0/16 | Virtueel netwerk-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 | Verstek | Ongeldig | 10.10.0.0/16 | Gateway voor 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 | Verstek | Actief | [X.X.X.X] | VirtualNetworkServiceEndpoint | ||
| 11 | Verstek | 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 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 toen een UDR voor het adresvoorvoegsel 10.0.0.0/16 werd gekoppeld aan het subnet Subnet1 in het virtuele netwerk Virtual-network-1. 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 nadat een UDR voor het adresvoorvoegsel 10.0.0.0/24 was 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. Deze route overschrijft effectief de ID2-route 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 aanmaakt in route-id's 6 en 7, wordt al het verkeer dat naar een adres wordt verzonden tussen 10.1.0.1-10.1.255.254 en 10.2.0.1-10.2.255.254 naar het gekoppelde virtuele netwerk gerouteerd. 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 virtueel netwerk peering 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 ID4- en ID5-routes voor verkeer dat subnet1 verlaat. De ID6- en ID7-routes bestaan om te voldoen aan vereiste 3 om verkeer te 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:
Tabel uitvouwen
| Bron | Staat | Adresvoorvoegsels | Volgend hoptype | IP-adres van de volgende hop |
|---|---|---|---|---|
| Verstek | Actief | 10.0.0.0/16 | Virtueel netwerk | |
| Verstek | Actief | 10.1.0.0/16 | Virtueel netwerk-peering | |
| Verstek | Actief | 10.2.0.0/16 | Virtueel netwerk-peering | |
| Verstek | Actief | 10.10.0.0/16 | Gateway voor een virtueel netwerk | [X.X.X.X] |
| Verstek | Actief | 0.0.0.0/0 | Internet | |
| Verstek | Actief | 10.0.0.0/8 | Geen | |
| Verstek | Actief | 100.64.0.0/10 | Geen | |
| Verstek | 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.