Azure Virtual Networks verkennen

  • 10 minuten

Azure Virtual Networks (VNets) vormen de fundamentele bouwsteen van uw privénetwerk in Azure. Met VNets kunt u complexe virtuele netwerken bouwen die vergelijkbaar zijn met een on-premises netwerk, met andere voordelen van Azure-infrastructuur, zoals schalen, beschikbaarheid en isolatie.

Elk VNet dat u maakt, heeft een eigen CIDR-blok en kan worden gekoppeld aan andere VNets en on-premises netwerken zolang de CIDR-blokken elkaar niet overlappen. U hebt ook controle over DNS-serverinstellingen voor VNets en segmentatie van het virtuele netwerk in subnetten.

Mogelijkheden van virtuele Azure-netwerken

Met Azure VNets kunnen resources in Azure veilig communiceren met elkaar, internet en on-premises netwerken.

  • Communicatie met internet. Alle resources in een VNet kunnen standaard uitgaand communiceren met internet. U kunt binnenkomend communiceren met een resource door er een openbaar IP-adres of een openbare Load Balancer aan toe te wijzen. U kunt ook een openbaar IP-adres of een openbare Load Balancer gebruiken voor het beheren van uw uitgaande verbindingen.
  • Communicatie tussen Azure-resources. Er zijn drie belangrijke mechanismen waarmee Azure-resources kunnen communiceren: VNets, VNet-service-eindpunten en VNet-peering. Virtuele netwerken kunnen niet alleen virtuele machines verbinden, maar ook andere Azure-resources, zoals de App Service Environment, Azure Kubernetes Service en Azure Virtual Machine Scale Sets. U kunt service-eindpunten gebruiken om verbinding te maken met andere typen Azure-resources, zoals Azure SQL-databases en Azure-opslagaccounts. Wanneer u een VNet maakt, kunnen uw services en VM's binnen uw VNet rechtstreeks en veilig met elkaar communiceren in de cloud.
  • Communicatie tussen on-premises resources. Breid uw datacenter veilig uit. U kunt uw on-premises computers en netwerken verbinden met een virtueel netwerk met een van de volgende opties: punt-naar-site virtueel particulier netwerk (VPN), site-naar-site-VPN, Azure ExpressRoute.
  • Netwerkverkeer filteren. U kunt netwerkverkeer tussen subnetten filteren met behulp van een combinatie van netwerkbeveiligingsgroepen en virtuele netwerkapparaten.
  • Netwerkverkeer routeren. Azure routeert verkeer standaard tussen subnetten, verbonden virtuele netwerken, on-premises netwerken en internet. U kunt routetabellen of BGP-routes (Border Gateway Protocol) implementeren om de standaardroutes te overschrijven die Azure maakt.

Ontwerpoverwegingen voor virtuele Azure-netwerken

Adresruimte en subnetten

U kunt meerdere virtuele netwerken per regio per abonnement maken. U kunt meerdere subnetten binnen elk virtueel netwerk maken.

Virtuele netwerken

Wanneer u een VNet maakt, gebruikt u adresbereiken die zijn geïnventariseerd in RFC 1918. Deze adressen zijn voor privéadresruimten, niet-routabele adresruimten.

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

Bovendien kunt u de volgende adresbereiken niet toevoegen.

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

Azure wijst resources in een virtueel netwerk een privé-IP-adres toe vanuit de adresruimte die u inricht. Als u bijvoorbeeld een virtuele machine in een VNet implementeert met subnetadresruimte 192.168.1.0/24, krijgt de virtuele machine een privé-IP-adres, zoals 192.168.1.4. Azure reserveert het eerste vier en laatste IP-adres voor in totaal vijf IP-adressen binnen elk subnet. Deze adressen zijn x.x.x.0-x.x.x.3 en het laatste adres van het subnet.

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

  • 192.168.1.0
  • 192.168.1.1 (Gereserveerd door Azure voor de standaardgateway.)
  • 192.168.1.2, 192.168.1.3 (Gereserveerd door Azure om de Azure DNS-IP's toe te wijzen aan de VNet-ruimte.)
  • 192.168.1.255 (Network broadcast address.)

Wanneer u van plan bent om virtuele netwerken te implementeren, moet u rekening houden met het volgende:

  • Zorg ervoor dat niet-overlapping van adresruimten wordt gegarandeerd. Zorg ervoor dat uw VNet-adresruimte (CIDR-blok) niet overlapt met de andere netwerkbereiken van uw organisatie.
  • Is er beveiligingsisolatie vereist?
  • Moet u beperkingen voor IP-adressering beperken?
  • Zijn er verbindingen tussen Azure VNets en on-premises netwerken?
  • Is er isolatie vereist voor administratieve doeleinden?
  • Gebruikt u Azure-services die hun eigen VNets maken?

Subnetten

Een subnet is een bereik van IP-adres in het VNet. U kunt VNets segmenteren in subnetten met verschillende grootten en zo veel subnetten maken als u nodig hebt voor de organisatie en beveiliging binnen de abonnementslimiet. Vervolgens kunt u Azure-resources implementeren in een specifiek subnet. Net als in een traditioneel netwerk kunt u met subnetten uw VNet-adresruimte segmenteren in segmenten die geschikt zijn voor het interne netwerk van de organisatie. Het kleinste ondersteunde IPv4-subnet is /29 en de grootste is /2 (met CIDR-subnetdefinities). IPv6-subnetten moeten exact /64 groot zijn. Wanneer u van plan bent subnetten te implementeren, kunt u het volgende overwegen:

  • Elk subnet moet een uniek adresbereik hebben dat is opgegeven in CIDR-indeling (Classless Inter-Domain Routing).
  • Voor bepaalde Azure-services is een eigen subnet vereist.
  • Subnetten kunnen worden gebruikt voor verkeerbeheer. U kunt bijvoorbeeld subnetten maken om verkeer te routeren via een virtueel netwerkapparaat.
  • U kunt de toegang tot Azure-resources beperken tot specifieke subnetten met een service-eindpunt voor een virtueel netwerk. U kunt meerdere subnetten maken en een service-eindpunt inschakelen voor sommige subnetten, maar niet voor andere.

Een naamconventie bepalen

Als onderdeel van uw Azure-netwerkontwerp is het belangrijk dat u uw naamconventie voor uw resources plant. Een effectieve naamconventie stelt resourcenamen samen op basis van belangrijke informatie over elke resource. Met een goed gekozen naam kunt u snel het type resource, de bijbehorende workload, de implementatieomgeving en de Azure-regio identificeren die als host fungeert. Een openbare IP-resource voor een SharePoint-productieworkload die zich in de regio VS - west bevindt, kan bijvoorbeeld pip-sharepoint-prod-westus-001 zijn

Diagram van een voorbeeld van een resourcenaamgeving.

Alle Azure-resourcetypen hebben een bereik dat het niveau definieert dat resourcenamen uniek moeten zijn. Een resource moet een unieke naam hebben binnen het bereik. Er zijn vier niveaus die u kunt opgeven voor een bereik: beheergroep, abonnement, resourcegroep en resource. Bereiken zijn hiërarchisch, waarbij elk niveau van de hiërarchie het bereik specifieker maakt.

Een virtueel netwerk heeft bijvoorbeeld een resourcegroepbereik, wat betekent dat er slechts één netwerk met de naam vnet-prod-westus-001 in elke resourcegroep kan zijn. Andere resourcegroepen kunnen een eigen virtueel netwerk hebben met de naam vnet-prod-westus-001. Subnetten zijn gericht op virtuele netwerken, dus elk subnet binnen een virtueel netwerk moet een afzonderlijke naam hebben.

Regio's en abonnementen begrijpen

Alle Azure-resources worden gemaakt in een Azure-regio en -abonnement. Een resource kan alleen worden gemaakt in een virtueel netwerk dat zich in dezelfde regio en hetzelfde abonnement bevindt als de resource. U kunt echter virtuele netwerken verbinden die in verschillende abonnementen en regio's bestaan. Azure-regio's zijn belangrijk om rekening mee te houden bij het ontwerpen van uw Azure-netwerk met betrekking tot uw infrastructuur, gegevens, toepassingen en eindgebruikers.

U kunt zoveel virtuele netwerken implementeren als u nodig hebt binnen elk abonnement, tot aan de abonnementslimiet. Sommige grotere organisaties met wereldwijde implementaties hebben bijvoorbeeld meerdere virtuele netwerken die zijn verbonden tussen regio's.

Diagram van een wereldkaart met het wereldwijde Azure-netwerk.

Azure-beschikbaarheidszones

Met een Azure-beschikbaarheidszone kunt u unieke fysieke locaties binnen een regio definiëren. Elke zone bestaat uit een of meer datacenters met onafhankelijke stroomvoorziening, koeling en netwerken. Ontworpen om hoge beschikbaarheid van uw Azure-services te garanderen, beschermt de fysieke scheiding van Beschikbaarheidszones binnen een regio toepassingen en gegevens tegen datacenterfouten.

Diagram van een Azure-regio met drie beschikbaarheidszones.

Overweeg beschikbaarheidszones bij het ontwerpen van uw Azure-netwerk en plan services die beschikbaarheidszones ondersteunen.

Azure-services die ondersteuning bieden voor Beschikbaarheidszones vallen in drie categorieën:

  • Zonegebonden services. Resources kunnen worden vastgemaakt aan een specifieke zone. Virtuele machines, beheerde schijven of standaard-IP-adressen kunnen bijvoorbeeld worden vastgemaakt aan een specifieke zone. Met deze planning kunt u meer tolerantie krijgen door een of meer exemplaren van resources te verdelen over zones.
  • Zone-redundante services. Resources worden automatisch gerepliceerd of gedistribueerd over zones. Azure repliceert de gegevens over drie zones, zodat een zonefout geen invloed heeft op de beschikbaarheid.
  • Niet-regionale diensten. De service is beschikbaar in Azure-geografische gebieden en is bestand tegen storingen in de hele zone.