IPv4-uitputting voorkomen in Azure

In dit artikel wordt beschreven hoe u het verbruik van privéadresruimte minimaliseert wanneer u grote netwerken in Azure bouwt. Mogelijk moet u het verbruik van adresruimte minimaliseren als er geen correct toewijzingsbeleid tot stand is gebracht en u geen privé-IP-adressen meer hebt om toe te wijzen aan virtuele Azure-netwerken. Dit artikel bevat twee methoden voor het juiste IP-adresbeheer in Azure.

Scenariodetails

Bedrijfsnetwerken gebruiken doorgaans adresruimten die zich in de privé-IPv4-adresbereiken bevinden die zijn gedefinieerd in RFC 1918. De adresbereiken zijn 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16. In on-premises omgevingen bieden deze bereiken voldoende IP-adressen om te voldoen aan de vereisten van zelfs de grootste netwerken. Als gevolg hiervan ontwikkelen veel organisaties adresbeheerprocedures die prioriteit geven aan eenvoudige routeringsconfiguraties en flexibele processen voor IP-toewijzing. Efficiënt gebruik van de adresruimte is geen prioriteit.

In de cloud zijn grote hybride netwerken eenvoudig te bouwen en sommige algemene architectuurpatronen, zoals microservices of containerisatie, kunnen leiden tot een verhoogd IP-adresverbruik. Het is dus belangrijk om deze werkwijzen voor adresbeheer aan te passen. In een cloudomgeving behandelt u privé-IPv4-adressen als een beperkte resource.

IP-adresbereiken van Azure Virtual Network

In uw virtuele Azure-netwerken raden we u aan de adresblokken te gebruiken die zijn gedefinieerd door RFC 1918. Deze adresblokken zijn bedoeld voor particuliere netwerken voor algemeen gebruik en zijn nietroutabel op het openbare internet.

U kunt andere bereiken gebruiken, maar voordat u deze bereiken in uw virtuele netwerk gebruikt, leest u de IANA-documentatie (Internet Assigned Numbers Authority) om inzicht te krijgen in de mogelijke gevolgen voor uw omgeving. U kunt de volgende bereiken gebruiken:

• Gedeelde adresruimte die is gedefinieerd door RFC 6598 voor nat (Network Address Translation) van providerniveau, die wordt behandeld als privéadresruimte in Azure Virtual Network. Het adresblok is 100.64.0.0/10.
• Openbare, internetrouteerbare IP-adressen die uw organisatie niet bezit. Deze procedure wordt afgeraden omdat resources in het virtuele netwerk geen toegang hebben tot interneteindpunten die worden weergegeven via de openbare IP-adressen.
• Speciaal doeladresblokken die zijn gedefinieerd door IANA, zoals 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 en 233.252.0.0/24.

U kunt de volgende IP-adresbereiken niet gebruiken in virtuele Azure-netwerken:

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

Uitlijning van Azure-landingszone

De aanbevelingen in dit artikel zijn bedoeld voor scenario's die zijn gebaseerd op de architectuur van de Azure-landingszone. In de richtlijnen wordt ervan uitgegaan dat:

• Elke regio heeft een hub-and-spoke-topologie.
• Hub-and-spoke-netwerken die zich in verschillende regio's bevinden, zijn met elkaar verbonden via wereldwijde peering van virtuele netwerken of verbindingen met hetzelfde Azure ExpressRoute-circuit of -circuits.
• Hub-and-spoke-netwerken zijn verbonden met on-premises sites via een combinatie van ExpressRoute-circuits en site-naar-site-VPN's.

In het volgende diagram ziet u een voorbeeldarchitectuur. De aanbevelingen zijn even van toepassing op netwerken die zijn gebouwd op Azure Virtual WAN, die ook hub-and-spoke-netwerken in elke regio heeft.

Download een PowerPoint-bestand van deze architectuur.

In een scenario dat is gebaseerd op de architectuur van de Azure-landingszone, worden toepassingen geïmplementeerd in hun eigen landingszone. Elke landingszone bevat een virtueel spoke-netwerk dat is gekoppeld aan een regionale hub. Virtuele spoke-netwerken vormen een integraal onderdeel van het bedrijfsnetwerk en worden routeerbare IPv4-adressen toegewezen. Deze adressen zijn uniek in het hele bedrijfsnetwerk. Alle architectuuronderdelen die zijn geïmplementeerd in Azure Virtual Network verbruiken dus IPv4-adressen in de adresruimte van het bedrijfsnetwerk, zelfs als slechts enkele onderdelen eindpunten beschikbaar maken die bereikbaar moeten zijn vanuit het hele bedrijfsnetwerk. Deze architectuuronderdelen kunnen virtuele machines, virtuele netwerkapparaten (NVA's) van derden of virtuele PaaS-services (Platform-as-a-Service) met een virtueel netwerk zijn.

Voor de rest van dit artikel verwijst front-endonderdeel naar een toepassingsonderdeel dat bereikbaar is vanuit het hele bedrijfsnetwerk of van buiten de landingszone van het onderdeel. Back-endonderdeel verwijst naar een toepassingsonderdeel dat geen eindpunten beschikbaar maakt in het bedrijfsnetwerk en alleen bereikbaar hoeft te zijn vanuit een eigen landingszone. Een webtoepassing die een eindpunt beschikbaar maakt, is bijvoorbeeld een front-endonderdeel en een database die geen eindpunt beschikbaar maakt, is een back-endonderdeel.

In de volgende secties worden twee methoden beschreven om het verbruik van privéadresruimte te minimaliseren wanneer u grote netwerken in Azure bouwt.

Methode 1: Niet-routable landingszone spoke virtuele netwerken

RFC 1918 carves IP-adres blokkeert uit de IPv4 32-bits adresruimte en maakt ze nietroutable op het openbare internet, zodat u ze in meerdere particuliere netwerken opnieuw kunt gebruiken voor interne communicatie. Deze methode is gebaseerd op hetzelfde principe dat van toepassing is op privéadresruimte. Een of meer adresbereiken worden uitgesneden uit de volledige privéadresruimte die door uw organisatie wordt gebruikt en die niet-routable zijn verklaard binnen het bedrijfsnetwerk van uw organisatie. De adresbereiken worden opnieuw gebruikt in meerdere landingszones. Als gevolg hiervan, elke landingszone:

• Er wordt een routeerbare adresruimte toegewezen die is gemaakt van een of meer adresbereiken. Uw organisatie beheert de adresbereiken centraal en wijst ze uniek toe aan een landingszone voor communicatie met het bedrijfsnetwerk. Adressen in de routeerbare ruimte worden toegewezen aan front-endonderdelen.
• U kunt de niet-routabele adresruimte gebruiken. Dit zijn de adresbereiken die uw organisatie niet-routable in het bedrijfsnetwerk declareert. U kunt deze gereserveerde bereiken gebruiken voor interne communicatie in alle landingszones. Adressen in de niet-routabele ruimte worden toegewezen aan back-endonderdelen.

In een Azure-hub-and-spoke-netwerk dat door de klant wordt beheerd of op basis van Virtual WAN, kunnen twee of meer spoke-virtuele netwerken geen overlappende IP-adresruimten hebben. Niet-routable-adresblokken kunnen niet worden toegewezen aan een spoke in een landingszone. Peering van virtuele netwerken is niettransitief, dus een virtueel netwerk met een spaak in een landingszone kan peeren met een virtueel netwerk op het tweede niveau dat een niet-routabele adresruimte heeft. In het volgende diagram ziet u de topologie van twee virtuele netwerken voor landingszones.

Download een PowerPoint-bestand van deze architectuur.

Elke landingszone van de toepassing bevat twee gekoppelde virtuele netwerken. Eén virtueel netwerk heeft routeerbare IP-adressen en host front-endonderdelen. Het andere virtuele netwerk heeft niet-routable IP-adressen en hosts back-endonderdelen. De routeerbare landingszone-spokes zijn gekoppeld aan de regionale hub. De niet-routable landingszone-spokes met de routeerbare landingszone-spoke. Peering van virtuele netwerken is niettransitief, dus niet-routable voorvoegsels zijn niet zichtbaar voor de regionale hub of de rest van het bedrijfsnetwerk. De routeerbare virtuele netwerken kunnen de niet-routabele adresbereiken niet gebruiken. Sommige organisaties hebben gefragmenteerde adresruimte die al is toegewezen aan routeerbare netwerken. Het kan lastig zijn om ongebruikte grote adresblokken te identificeren en deze niet-routable te declareren. In dat geval kunt u ongebruikte adressen overwegen die niet zijn opgenomen in de RFC 1918-adresruimte. In het vorige diagram ziet u een voorbeeld van NAT-adressen van providerklasse, zoals RFC 6598, in niet-routable virtuele spoke-netwerken.

Migratie van één virtuele netwerklandingszone

Peering van virtuele netwerken biedt volledige laag-3-connectiviteit tussen twee gekoppelde virtuele netwerken. Toepassingsonderdelen die zijn geïmplementeerd in traditionele landingszones voor één virtueel netwerk die met elkaar communiceren via IP kunnen vrij worden verplaatst tussen routeerbare en niet-routable virtuele spoke-netwerken in een landingszone. In deze sectie worden twee typische migratiepatronen beschreven.

De volgende toepassingen worden weergegeven via bezorgingscontrollers voor toepassingen in laag 7:

Download een PowerPoint-bestand van deze architectuur.

Toepassingen die beschikbaar worden gesteld via leveringscontrollers voor toepassingen op laag 7 kunnen worden verplaatst naar de niet-routable spoke. De toepassingsleveringscontroller is het enige front-endonderdeel dat zich in de routeerbare landingszone-spoke moet bevinden.

De volgende toepassingen worden weergegeven via een Azure Load Balancer:

Download een PowerPoint-bestand van deze architectuur.

Als een toepassing de eindpunten beschikbaar maakt via een Azure Load Balancer, moeten de rekeninstanties die deel uitmaken van de back-endpool van de load balancer in hetzelfde virtuele netwerk blijven. Azure Load Balancers bieden alleen ondersteuning voor back-end-exemplaren in hun eigen virtuele netwerk.

Uitgaande afhankelijkheden

De back-endonderdelen van een toepassing hoeven niet bereikbaar te zijn of binnenkomende verbindingen te ontvangen van het bedrijfsnetwerk, maar ze hebben vaak uitgaande afhankelijkheden. Back-endonderdelen moeten mogelijk verbinding maken met eindpunten die zich buiten hun landingszones bevinden in exemplaren zoals DNS-resolutie, Active Directory-domein Services-domeincontrollers, toegang krijgen tot toepassingseindpunten die worden weergegeven door andere landingszones of toegang krijgen tot logboekregistratie- of back-upfaciliteiten.

Wanneer services verbindingen in niet-routable spoke virtuele netwerken initiëren, moet u bron-NAT (SNAT) implementeren voor verbindingen achter een routeerbaar IP-adres. Als u SNAT wilt implementeren, implementeert u een nat-geschikt apparaat in het routeerbare virtuele spoke-netwerk. Elke landingszone voert een eigen toegewezen NAT NVA uit. Er zijn twee opties voor het implementeren van SNAT in een landingszone: Azure Firewall of NVA's van derden. In beide gevallen moeten alle subnetten in de niet-routable spoke worden gekoppeld aan een aangepaste routetabel. Zoals in het volgende diagram wordt weergegeven, stuurt de routetabel verkeer door naar bestemmingen buiten de landingszone naar het SNAT-apparaat. Azure NAT Gateway biedt geen ondersteuning voor SNAT voor verkeer dat is bestemd voor privé-IP-adresruimte, zoals RFC 1918-ruimte.

Download een PowerPoint-bestand van deze architectuur.

SNAT implementeren via Azure Firewall

Azure Firewall:

• Biedt hoge beschikbaarheid.
• Biedt systeemeigen schaalbaarheid en drie verschillende SKU's. SNAT is geen resource-intensieve taak, dus overweeg eerst de basis-SKU. Gebruik de standaard-SKU voor landingszones waarvoor grote hoeveelheden uitgaand verkeer van de niet-routabele adresruimte is vereist.
• Voert SNAT uit voor verkeer achter de privé-IP-adressen van een van de exemplaren. Elk exemplaar kan alle niet-gemachtigde poorten gebruiken.

In het volgende diagram ziet u de indeling van de landingszone voor het implementeren van SNAT in een hub-and-spoke-netwerktopologie met behulp van Azure Firewall.

Download een PowerPoint-bestand van deze architectuur.

U moet alle subnetten in de niet-routable spoke koppelen aan een aangepaste routetabel om verkeer naar bestemmingen buiten de landingszone naar Azure Firewall te verzenden.

In het volgende diagram ziet u de indeling van de landingszone voor het implementeren van SNAT in een hub-and-spoke-netwerk op basis van Virtual WAN met behulp van Azure Firewall.

Download een PowerPoint-bestand van deze architectuur.

U moet alle subnetten in de niet-routable spoke of de spokes die niet zijn verbonden met Virtual WAN, koppelen aan een aangepaste routetabel om verkeer te verzenden naar bestemmingen buiten de landingszone naar Azure Firewall.

Als u voor beide indelingen resources in de niet-routable spoke-toegang wilt bieden tot routeerbare IP-adressen buiten de landingszone, moet u Azure Firewall implementeren met de optie SNAT uitvoeren ingesteld op Altijd in de routeerbare spoke van elke landingszone. U vindt instructies over het configureren van Azure Firewall voor het implementeren van SNAT op alle ontvangen verbindingen in openbare documentatie. In de volgende schermopname ziet u de vereiste configuratie voor het gebruik van Azure Firewall als nat-apparaat voor verbindingen die zijn geïnitieerd door resources in niet-routable virtuele spoke-netwerken.

SNAT implementeren via NVA's van derden

NVA's van derden met NAT-mogelijkheden zijn beschikbaar in Azure Marketplace. Ze bieden:

• Gedetailleerde controle over in- en uitschalen.
• Gedetailleerde controle van de NAT-pool.
• Aangepast NAT-beleid, zoals het gebruik van verschillende NAT-adressen, afhankelijk van de eigenschappen van de binnenkomende verbinding, zoals het bron- of doel-IP-adres.

Bekijk de volgende aanbevelingen:

• Implementeer clusters met ten minste twee NVA's voor hoge beschikbaarheid. Gebruik een Azure Load Balancer om binnenkomende verbindingen van het niet-routable virtuele spoke-netwerk te distribueren naar de NVA's. Een taakverdelingsregel voor een poort met hoge beschikbaarheid is vereist omdat het cluster SNAT implementeert op alle verbindingen die de landingszone verlaten. Azure Standard Load Balancer biedt ondersteuning voor taakverdelingsregels voor poorten met hoge beschikbaarheid.
• De Azure SDN-stack ondersteunt NVA's met één arm en twee arm. NVA's met één arm hebben de voorkeur omdat ze het verbruik van adresruimte in de routeerbare virtuele spoke-netwerken verminderen.

In het volgende diagram ziet u de indeling van de landingszone voor het implementeren van SNAT in een hub-and-spoke-netwerktopologie met behulp van NVA's van derden.

Download een PowerPoint-bestand van deze architectuur.

In het volgende diagram ziet u de indeling van de landingszone voor het implementeren van SNAT in een hub-and-spoke-netwerktopologie op basis van virtual WAN met behulp van NVA's van derden.

Download een PowerPoint-bestand van deze architectuur.

Voor beide NVA-indelingen van derden moet u meerdere exemplaren achter een Azure Load Balancer implementeren om hoge beschikbaarheid te bieden. Azure Load Balancer Standard-SKU is vereist.

Methode 2: Azure Private Link-services

Private Link biedt toegang tot toepassingen die zijn geïmplementeerd in een virtueel netwerk dat niet is verbonden met uw virtuele netwerk. In het virtuele netwerk aan de serverzijde of toepassing wordt een Private Link-service geïmplementeerd en gekoppeld aan een toepassingseindpunt dat wordt weergegeven op het front-end-IP-adres van een interne Standaard-SKU-load balancer van Azure. In het virtuele netwerk aan de clientzijde wordt een privé-eindpuntresource geïmplementeerd en gekoppeld aan de Private Link-service. Het privé-eindpunt maakt het toepassingseindpunt beschikbaar in uw virtuele netwerken. Private Link biedt de tunneling- en NAT-logica om verkeer tussen de clientzijde en de serverzijde te routeren. Zie Wat is een Azure Private Link? voor meer informatie.

Private Link vereist geen laag-3-verbinding tussen het virtuele netwerk aan de clientzijde en het virtuele netwerk aan de serverzijde. De twee virtuele netwerken kunnen overlappende IP-adresruimten hebben. Private Link maakt het mogelijk om toepassingen te implementeren in toegewezen, geïsoleerde virtuele netwerken, allemaal met behulp van dezelfde niet-routable adresruimte. De toepassingen worden weergegeven als Private Link-services in het bedrijfsnetwerk, die gebruikmaakt van een routeerbare adresruimte. In de context van de Architectuur van de Azure-landingszone heeft de resulterende topologie van de landingszone:

• Een geïsoleerd virtueel netwerk dat als host fungeert voor de hele toepassing en de Private Link-service die is gekoppeld aan de eindpunten van de toepassing. Het toepassingsteam definieert de adresruimte van het virtuele netwerk.
• Een virtueel spoke-netwerk met een routeerbare adresruimte die als host fungeert voor het privé-eindpunt dat is gekoppeld aan de Private Link-service. Het virtuele spoke-netwerk wordt rechtstreeks gekoppeld aan de regionale hub.

In het volgende diagram ziet u de topologie van de landingszone waarvoor Private Link is ingeschakeld.

Download een PowerPoint-bestand van deze architectuur.

Een Private Link-service gebruiken voor uitgaande afhankelijkheden

Wanneer u toepassingen in geïsoleerde virtuele spoke-netwerken implementeert, gebruikt u een Private Link-service voor uitgaande afhankelijkheden. Definieer privé-eindpunten in het geïsoleerde virtuele spoke-netwerk en koppel deze aan een Private Link-service in routeerbare virtuele netwerken. In het volgende diagram ziet u de conceptuele benadering.

Download een PowerPoint-bestand van deze architectuur.

In praktijk zijn grootschalige implementaties mogelijk niet van toepassing op de Methode Private Link:

• Als de toepassingen die zijn geïmplementeerd in het geïsoleerde virtuele netwerk meerdere uitgaande afhankelijkheden hebben. Wanneer u een Private Link-service en een privé-eindpunt implementeert voor elk van de uitgaande afhankelijkheden, neemt de complexiteit en de beheerbehoeften toe.
• Als de uitgaande afhankelijkheid eindpunten bevat in het routeerbare netwerk dat geen deel kan uitmaken van een back-endpool van Azure Load Balancer, is Private Link niet van toepassing.

Als u deze twee beperkingen wilt overwinnen, implementeert u een proxy/NAT-oplossing in de routeerbare spoke en maakt u deze toegankelijk vanuit het geïsoleerde virtuele netwerk met behulp van Private Link.

Download een PowerPoint-bestand van deze architectuur.

Gebruik één privé-eindpunt of Private Link-service om een proxy-/NAT-oplossing beschikbaar te maken die is geïmplementeerd in het routeerbare netwerk. Poortomzettings- en adresomzettingsregels worden gedefinieerd op de NVA's. Met deze regels kan het gebruik van één privé-eindpunt in het geïsoleerde virtuele netwerk toegang krijgen tot meerdere afhankelijkheden in het routeerbare netwerk.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteurs:

• Microsoft Guerrini | EMEA Technical Lead
• De Kaviraj | Cloud Solution Architect
• Jack Tracey | Senior Cloud Solution Architect

Andere inzenders:

• Jodi Marts | Technische schrijver

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Azure Firewall implementeren in een virtueel netwerk
• SNAT configureren in Azure Firewall
• Ondersteunde IP-adressen in Azure Virtual Network
• Azure Private Link
• Azure-belastingsverdeling
• Peering op virtueel netwerk

Verwante resources

• Ontwerp van netwerkarchitectuur
• Architectuurbenaderingen voor netwerken in multitenant-oplossingen
• Hub-and-spoke-netwerktopologie