IP-adressering plannen

Het is belangrijk dat uw organisatie plannen voor IP-adressering in Azure. Planning zorgt ervoor dat de IP-adresruimte niet overlapt tussen on-premises locaties en Azure-regio's.

Overwegingen bij het ontwerpen:

• Overlappende IP-adresruimten in on-premises en Azure-regio's creëren grote conflicten.

• Azure VPN Gateway kan overlappende, on-premises sites verbinden met overlappende IP-adresruimten via nat-mogelijkheid (Network Address Translation). Deze functie is algemeen beschikbaar in Azure Virtual WAN en zelfstandige Azure VPN Gateway.

  

• U kunt adresruimte toevoegen nadat u een virtueel netwerk hebt gemaakt. Dit proces heeft geen storing nodig als het virtuele netwerk al is verbonden met een ander virtueel netwerk via peering van virtuele netwerken. In plaats daarvan moet elke externe peering een hersynchronisatiebewerking uitvoeren nadat de netwerkruimte is gewijzigd.

• Azure reserveert vijf IP-adressen binnen elk subnet. Houd rekening met deze adressen wanneer u de grootte van virtuele netwerken en de opgenomen subnetten wijzigt.

• Voor sommige Azure-services zijn toegewezen subnetten vereist. Deze services omvatten Azure Firewall en Azure VPN Gateway.

• U kunt subnetten delegeren aan bepaalde services om exemplaren van een service in het subnet te maken.

Ontwerpaanvelingen:

• Plan vooraf niet-overlappende IP-adresruimten in Azure-regio's en on-premises locaties.

• Gebruik IP-adressen van de adrestoewijzing voor privéinternet, ook wel RFC 1918-adressen genoemd.

• Gebruik niet de volgende adresbereiken:

  • 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)

• Voor omgevingen met beperkte beschikbaarheid van privé-IP-adressen kunt u overwegen IPv6 te gebruiken. Virtuele netwerken kunnen alleen IPv4 of dual stack IPv4+IPv6 zijn.

  

• Maak geen grote virtuele netwerken, zoals /16. Het zorgt ervoor dat de IP-adresruimte niet wordt verspild. Het kleinste ondersteunde IPv4-subnet is /29en het grootste is /2 bij het gebruik van CIDR-subnetdefinities (Classless Inter-Domain Routing). IPv6-subnetten moeten exact /64 in grootte zijn.

• Maak geen virtuele netwerken zonder vooraf de vereiste adresruimte te plannen.

• Gebruik geen openbare IP-adressen voor virtuele netwerken, met name als de openbare IP-adressen niet bij uw organisatie horen.

• Houd rekening met de services die u gaat gebruiken, er zijn enkele services met gereserveerde IP-adressen (IP-adressen), zoals AKS met CNI-netwerken

• Gebruik niet-routable landingszone spoke virtuele netwerken en Azure Private Link-service om IPv4-uitputting te voorkomen.

Overwegingen voor IPv6

Steeds meer organisaties gebruiken IPv6 in hun omgevingen. Deze acceptatie wordt veroorzaakt door de openbare IPv4-ruimteuitputting, particuliere IPv4-tekorten, met name binnen grootschalige netwerken, en de noodzaak om connectiviteit te bieden met alleen IPv6-clients. Er is geen universele benadering voor het aannemen van IPv6. Er zijn echter best practices die u kunt volgen wanneer u IPv6 plant en implementeert in uw bestaande Azure-netwerken.

Het Microsoft Cloud Adoption Framework voor Azure helpt u inzicht te hebben in de overwegingen waarmee u rekening moet houden wanneer u systemen in de cloud maakt. Zie ontwerpprincipes voor Azure-landingszones voor meer informatie over best practices voor architectuur voor het ontwerpen van duurzame systemen. Zie de Architecture Center-handleiding voor IPv6 voor uitgebreide aanbevelingen en aanbevolen procedures met betrekking tot uw cloudarchitectuur, inclusief referentiearchitectuurimplementaties, diagrammen en handleidingen.

Overwegingen bij het ontwerpen:

• Faseer uw IPv6-acceptatie. Implementeer waar nodig IPv6 op basis van uw bedrijfsbehoeften. Vergeet niet dat IPv4 en IPv6 naast elkaar kunnen bestaan zolang dat nodig is.

• In scenario's waarin toepassingen afhankelijk zijn van IaaS-services (Infrastructure as a Service) met volledige IPv6-ondersteuning, zoals virtuele machines (VM's), is systeemeigen end-to-end gebruik van IPv4 en IPv6 mogelijk. Deze configuratie voorkomt vertaalcomplicaties en biedt de meeste informatie aan de server en toepassing.

  U kunt Basic-SKU internetgerichte Azure Load Balancers implementeren met een IPv6-adres. Deze configuratie maakt systeemeigen end-to-end IPv6-connectiviteit mogelijk tussen het openbare internet en azure-VM's via de load balancer. Deze aanpak vereenvoudigt ook systeemeigen end-to-end uitgaande verbindingen tussen VM's en clients met IPv6-functionaliteit op het openbare internet. Houd er rekening mee dat voor deze aanpak elk apparaat in het pad is vereist om IPv6-verkeer te verwerken.

  De systeemeigen end-to-end-benadering is het handigst voor directe server-naar-server- of client-naar-server-communicatie. Het is niet handig voor de meeste webservices en toepassingen, die doorgaans worden beveiligd door firewalls, webtoepassingsfirewalls of omgekeerde proxy's.

• Sommige complexe implementaties en toepassingen die gebruikmaken van een combinatie van services van derden, PaaS-services (Platform as a Service) en back-endoplossingen bieden mogelijk geen ondersteuning voor systeemeigen IPv6. In deze gevallen moet u NAT/NAT64 of een IPv6-proxyoplossing gebruiken om communicatie tussen IPv6 en IPv4 mogelijk te maken.

• Wanneer de complexiteit van de toepassingsarchitectuur of andere factoren, zoals trainingskosten, aanzienlijk wordt beschouwd, wilt u mogelijk de infrastructuur met alleen IPv4 op de back-end blijven gebruiken en een nvA (network virtual appliance) met twee stacks (NVA) voor servicelevering implementeren.

  Een typische implementatie die gebruikmaakt van een NVA kan er als volgt uitzien:

  

Ontwerpaanvelingen:

Hier volgt een nader overzicht van hoe een typische architectuur eruit kan zien:

• Implementeer de NVA in virtuele-machineschaalsets met flexibele indeling (VMSS Flex) voor tolerantie en maak ze beschikbaar op internet via Azure Load-Balancer, dat een front-end voor een openbaar IP-adres heeft.

  De NVA's accepteren IPv4- en IPv6-verkeer en vertalen dit in IPv4-verkeer om toegang te krijgen tot de toepassing in het subnet van de toepassing. De aanpak vermindert de complexiteit voor het toepassingsteam en vermindert de kwetsbaarheid voor aanvallen.

• Azure Front Door implementeren om wereldwijde routering voor webverkeer te bieden.

  Azure Front Door-mogelijkheden omvatten het proxyen van IPv6-clientaanvragen en verkeer naar een IPv4-back-end, zoals hier wordt weergegeven:

  

Dit zijn de belangrijkste verschillen tussen de NVA-benadering en de Azure Front Door-benadering:

• NVA's worden door de klant beheerd, werken op Laag 4 van het OSI-model en kunnen worden geïmplementeerd in hetzelfde virtuele Azure-netwerk als de toepassing, met een persoonlijke en openbare interface.
• Azure Front Door is een wereldwijde Azure PaaS-service en werkt op Laag 7 (HTTP/HTTPS). De back-end van de toepassing is een internetgerichte service die kan worden vergrendeld om alleen verkeer van Azure Front Door te accepteren.

In complexe omgevingen kunt u een combinatie van beide gebruiken. NVA's worden gebruikt binnen een regionale implementatie. Azure Front Door wordt gebruikt om verkeer te routeren naar een of meer regionale implementaties in verschillende Azure-regio's of andere internetgerichte locaties. Om de beste oplossing te bepalen, raden we u aan de mogelijkheden van Azure Front Door en de productdocumentatie te bekijken.

CIDR-blokken voor virtueel IPv6-netwerk:

• U kunt één CIDR-blok (IPv6 Classless Inter-Domain Routing) koppelen wanneer u een nieuw virtueel netwerk maakt in een bestaande Azure-implementatie in uw abonnement. De grootte van het subnet voor IPv6 moet /64 zijn. Als u deze grootte gebruikt, zorgt u voor toekomstige compatibiliteit als u besluit om routering van het subnet naar een on-premises netwerk in te schakelen. Sommige routers kunnen alleen /64 IPv6-routes accepteren.
• Als u een bestaand virtueel netwerk hebt dat alleen IPv4 ondersteunt en resources in uw subnet die zijn geconfigureerd om alleen IPv4 te gebruiken, kunt u IPv6-ondersteuning inschakelen voor uw virtuele netwerk en resources. Uw virtuele netwerk kan worden uitgevoerd in de modus dual-stack, waardoor uw resources kunnen communiceren via IPv4, IPv6 of beide. IPv4- en IPv6-communicatie zijn onafhankelijk van elkaar.
• U kunt IPv4-ondersteuning voor uw virtuele netwerk en subnetten niet uitschakelen. IPv4 is het standaard-IP-adresseringssysteem voor virtuele Azure-netwerken.
• Koppel een IPv6 CIDR-blok aan uw virtuele netwerk en subnet of BYOIP IPv6. CIDR-notatie is een methode voor het weergeven van een IP-adres en het bijbehorende netwerkmasker. De indelingen van deze adressen zijn als volgt:
  • Een afzonderlijk IPv4-adres is 32 bits, met vier groepen van maximaal drie decimalen. Bijvoorbeeld: 10.0.1.0.
  • Een IPv4 CIDR-blok heeft vier groepen van maximaal drie decimalen, van 0 tot en met 255, gescheiden door punten, gevolgd door een slash en een getal van 0 tot en met 32. Bijvoorbeeld: 10.0.0.0/16.
  • Een afzonderlijk IPv6-adres is 128 bits. Het heeft acht groepen van vier hexadecimale cijfers. Bijvoorbeeld: 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Een IPv6 CIDR-blok heeft vier groepen van maximaal vier hexadecimale cijfers, gescheiden door dubbele punten, gevolgd door een dubbele dubbele punt, gevolgd door een slash en een getal van 1 tot en met 128. Bijvoorbeeld: 2001:db8:1234:1a00::/64.
• Werk uw routetabellen bij om IPv6-verkeer te routeren. Maak voor openbaar verkeer een route waarmee al het IPv6-verkeer van het subnet naar vpn-gateway of een Azure ExpressRoute-gateway wordt gerouteerd.
• Werk de beveiligingsgroepsregels bij zodat deze regels voor IPv6-adressen bevatten. Hierdoor kan IPv6-verkeer naar en van uw exemplaren stromen. Als u regels voor netwerkbeveiligingsgroepen hebt om de verkeersstroom van en naar uw subnet te beheren, moet u regels voor IPv6-verkeer opnemen.
• Als uw exemplaartype IPv6 niet ondersteunt, gebruikt u dubbele stack of implementeert u een NVA, zoals eerder beschreven, die wordt omgezet van IPv4 naar IPv6.

hulpprogramma's voor IP-adresbeheer (IPAM)

Het gebruik van een IPAM-hulpprogramma kan u helpen bij het plannen van IP-adressen in Azure, omdat het gecentraliseerd beheer en zichtbaarheid biedt, waardoor overlappingen en conflicten in IP-adresruimten worden voorkomen. In deze sectie wordt u begeleid bij essentiële overwegingen en aanbevelingen bij het aannemen van een IPAM-hulpprogramma.

Overwegingen bij het ontwerpen:

Er zijn talloze IPAM-hulpprogramma's beschikbaar voor uw overweging, afhankelijk van uw vereisten en de grootte van uw organisatie. De opties omvatten het hebben van een basisinventaris op basis van Excel tot opensource-communitygestuurde oplossingen of uitgebreide bedrijfsproducten met geavanceerde functies en ondersteuning.

• Houd rekening met deze factoren bij het evalueren van welk IPAM-hulpprogramma moet worden geïmplementeerd:

  • Minimale functies die zijn vereist voor uw organisatie
  • Totale eigendomskosten (TCO), inclusief licenties en doorlopend onderhoud
  • Audittrails, logboekregistratie en op rollen gebaseerd toegangsbeheer
  • Verificatie en autorisatie via Microsoft Entra-id
  • Toegankelijk via API
  • Integraties met andere hulpprogramma's en systemen voor netwerkbeheer
  • Actieve communityondersteuning of het ondersteuningsniveau van de softwareprovider

• Overweeg om een opensource IPAM-hulpprogramma te evalueren, zoals Azure IPAM. Azure IPAM is een lichtgewicht oplossing die is gebouwd op het Azure-platform. Het detecteert automatisch het IP-adresgebruik in uw Azure-tenant en stelt u in staat om alles te beheren vanuit een gecentraliseerde gebruikersinterface of via een RESTful-API.

• Houd rekening met het operationele model van uw organisatie en het eigendom van het IPAM-hulpprogramma. Het doel van het implementeren van een IPAM-hulpprogramma is het stroomlijnen van het proces van het aanvragen van nieuwe IP-adresruimten voor toepassingsteams zonder afhankelijkheden en knelpunten.

• Een belangrijk onderdeel van de functionaliteit van het IPAM-hulpprogramma is het inventariseren van ip-adresruimtegebruik en het logisch organiseren ervan.

Ontwerpaanvelingen:

• Het proces voor het reserveren van niet-overlappende IP-adresruimten moet ondersteuning bieden voor het aanvragen van verschillende grootten op basis van de behoeften van de afzonderlijke landingszones van de toepassing.

  • U kunt bijvoorbeeld de grootte van T-shirt gebruiken om het eenvoudig te maken voor toepassingsteams om hun behoeften te beschrijven:
    • Klein - /24 256 IP-adressen
    • Gemiddeld - /22 1024 IP-adressen
    • Groot - /20 4.096 IP-adressen

• Uw IPAM-hulpprogramma moet een API hebben voor het reserveren van niet-overlappende IP-adresruimten ter ondersteuning van een IaC-benadering (Infrastructure as Code). Deze functie is ook van cruciaal belang voor een naadloze integratie van IPAM in uw abonnementsautomaat proces, waardoor het risico op fouten en de noodzaak van handmatige interventie wordt verminderd.

  • Een voorbeeld van een IaC-benadering is Bicep met de functionaliteit van het implementatiescript of terraform-gegevensbronnen om gegevens dynamisch op te halen uit de IPAM-API.

• Maak een systematische rangschikking voor uw IP-adresruimten door ze te structureren op basis van Azure-regio's en workload archetypen, waardoor een schone en traceerbare netwerkinventaris wordt gegarandeerd.

• Het buiten gebruik stellen van workloads moet het verwijderen van IP-adresruimten bevatten die niet meer worden gebruikt, wat later opnieuw kan worden gebruikt voor toekomstige nieuwe workloads, waardoor efficiënt resourcegebruik wordt bevorderd.