Hoe je IP-adresoverlap in Azure hybride netwerken voorkomt

By Mirko Peters · 2026-10-23

Leer hoe je catastrofale IP-adresoverlap voorkomt wanneer je je on-premises kantoornetwerk koppelt aan Azure virtuele netwerken, door een goede CIDR-planning te maken.

Automatically translated with AI from the original post. Read the English original

Wanneer je je on-premises bedrijfsinfrastructuur koppelt aan de Microsoft-cloud, kunnen overlappende IP-adresbereiken je hybride connectiviteit meteen laten vastlopen. Goede CIDR-blokplanning, zorgvuldig subnetontwerp en een doordachte verdeling van bereiken zorgen ervoor dat je Azure virtuele netwerken en lokale kantoren zonder routeringsconflicten met elkaar kunnen communiceren.

Belangrijkste punten

• IP-adresoverlap ontstaat wanneer je on-premises netwerk en Azure VNet hetzelfde subnetbereik gebruiken. Dat breekt de routering volledig.
• Privé-IP-bereiken zoals 192.168.x.x of 10.x.x.x moeten zorgvuldig op elkaar worden afgestemd in beide omgevingen voordat je een VPN of ExpressRoute opzet.
• Een goede CIDR-blokgrootte vooraf kiezen voorkomt pijnlijke hernummeringsprojecten later, wanneer je cloudinfrastructuur groeit.
• Azure reserveert de eerste vier en het laatste IP-adres in elk subnet. Het aantal bruikbare hosts is daardoor kleiner dan je op basis van de traditionele berekening zou verwachten.
• Logische netwerksegmentatie is in de cloud net zo belangrijk als op je fysieke kantoorswitch.

Het gevaar van IP-overlap in hybride omgevingen

Wanneer je in een traditioneel kantoor achter je bureau zit, werkt je computer binnen een netjes afgebakend lokaal netwerkblok dat door een lokale router is toegewezen. Alles voelt vanzelfsprekend totdat je organisatie besluit een hybride cloudarchitectuur te gebruiken. Zodra je je eerste Azure Virtual Network (VNet) aanmaakt en dat via een site-to-site VPN of ExpressRoute terugkoppelt aan je fysieke datacenter of kantoor, betreed je een netwerkomgeving met veel op het spel.

Twee netwerken met hetzelfde IP-bereik zijn als twee onafhankelijke gezinnen die exact hetzelfde straatadres en huisnummer delen. Wanneer een pakket van je lokale server naar een Azure-resource vertrekt, kijkt de router in zijn routeringstabel om te zien waar die bestemming zich bevindt. Als je lokale kantoornetwerk en je Azure VNet allebei dezelfde subnetruimte bezetten, zoals het veelvoorkomende blok 192.168.1.0/24, heeft de router geen manier om lokale apparaten van cloudresources te onderscheiden. De postbode weet niet bij welke deur hij moet aanbellen, en de communicatie valt meteen weg.

Waarom standaardinstellingen thuis voor problemen in het bedrijf zorgen

De meeste thuisrouters en kleine kantooropstellingen worden geleverd met verstandige standaardinstellingen en kennen automatisch adressen toe in de ruimtes 192.168.0.0/24 of 192.168.1.0/24. Omdat deze standaardinstellingen voor gewone gebruikers onzichtbaar zijn, houden beheerders er bij het instellen van thuiswerkers die via VPN-clients verbinding maken, of bij kleine vestigingen die met Azure verbonden worden, vaak geen rekening mee.

Als het thuisnetwerk van een medewerker 192.168.1.0/24 gebruikt en je cloudinfrastructuur in Azure ook op een conflicterend bereik is uitgerold, dan wordt die medewerker volledig buitengesloten van de zakelijke cloudresources zodra de VPN-tunnel de kloof probeert te overbruggen. Om dit probleem te voorkomen, is zorgvuldig IP-adresbeheer (IPAM) nodig, lang voordat er cloudresources worden ingericht.

CIDR-blokken voor je Azure VNet plannen

De overstap van de fysieke wereld naar de cloud legt de verantwoordelijkheid voor het netwerkontwerp volledig bij jou. Thuis bepaalt je internetprovider of consumentenrouter welk adresblok je krijgt. In Azure bepaal jij de grenzen, en draag je ook de gevolgen.

Bij het ontwerpen van je Azure-omgeving moet je een hiërarchisch adresschema uitwerken waarin geen overlap voorkomt. Dat betekent dat je de beschikbare privé-adresruimte, meestal afkomstig uit de RFC 1918-pools, opdeelt in afzonderlijke, specifieke blokken voor:

• Productieworkloads en kernapplicatieservers
• Staging-, ontwikkel- en testomgevingen
• Beheerinfrastructuur, domeincontrollers en jump boxes
• Integratiediensten, gateways en beveiligingsappliances

Door je IP-architectuur als eindige resource te behandelen, zorg je ervoor dat toekomstige vestigingen, overgenomen dochterondernemingen en nieuwe cloudregio's kunnen worden geïntegreerd zonder een grootschalig, bedrijfsverstorend hernummeringsproject.

Het Azure-verschil: aanpassingen in de subnetberekening

Bij het berekenen van je subnetgroottes in Azure vraagt de standaard netwerkrekenkunde om een cruciale aanpassing. In een standaard subnet uit het leerboek worden altijd twee adressen per blok gereserveerd: het eerste adres dient als netwerkidentificatie en het laatste adres fungeert als broadcastadres. Een standaard /24-blok met 256 adressen levert dus 254 bruikbare hostadressen op.

Wanneer je subnets binnen Azure Virtual Networks bouwt, haalt het cloudplatform echter extra adressen weg voor zijn eigen interne infrastructuur en routering. Azure reserveert vijf IP-adressen in elk subnet:

.0: Netwerkadres .1: Door Azure gereserveerd voor de standaardgateway .2 en .3: Door Azure gereserveerd voor het koppelen van de Azure DNS-IP's .255: Broadcastadres

Dit betekent dat een /24-subnet in Azure 251 bruikbare adressen biedt in plaats van 254. Door rekening te houden met deze gereserveerde adressen voorkom je onverwachte capaciteitstekorten bij het uitrollen van geschaalde webapps, containerclusters of virtual machine scale sets.

Conclusie

Het beheersen van CIDR-notatie en subnetgrenzen is meer dan een academische oefening voor IT-certificeringen. Het is de fundamentele vaardigheid die moderne hybride cloudomgevingen operationeel houdt. Door je adresruimten proactief in kaart te brengen en veelvoorkomende overlapvalkuilen te vermijden, bescherm je je infrastructuur tegen stille routeringsfouten en zorg je voor naadloze communicatie tussen je on-premises kantoren en Microsoft Azure.

Wil je dieper ingaan op hoe thuisrouters, netmaskers en cloudarchitecturen samenhangen? Luister de volledige aflevering van de podcast voor een uitleg van de netwerkbasics zonder jargon.

Veelgestelde vragen

Wat gebeurt er als mijn on-premises netwerk en Azure VNet hetzelfde IP-bereik gebruiken?

Het verkeer tussen de twee omgevingen valt volledig weg. Omdat routers afhankelijk zijn van unieke bestemmingsnetwerken om pakketten door te sturen, zorgen overlappende bereiken voor verwarring in de routeringstabellen, waardoor systemen niet kunnen bepalen welke richting ze de data op moeten sturen.

Hoeveel IP-adressen reserveert Azure in elk subnet?

Azure reserveert vijf IP-adressen in elk subnet: het netwerkadres, de standaardgateway, twee IP-adressen voor de interne Azure DNS-koppeling en het broadcastadres.

Kan ik het IP-adresbereik van mijn Azure VNet later eenvoudig wijzigen?

Nee. Het wijzigen van de primaire adresruimte van een bestaand Azure Virtual Network of subnet is ingewikkeld en vereist vaak dat resources worden verwijderd en opnieuw aangemaakt. Daarom is een zorgvuldige CIDR-planning vooraf essentieel.

Welke privé-IP-adresbereiken moet ik gebruiken voor Azure-hybride implementaties?

Je kunt bereiken uit RFC 1918 gebruiken (10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16). Belangrijk is dat je bereiken kiest die niet conflicteren met je bestaande kantoren, vestigingen of partnernetwerken.