Twee kantoren gebruiken allebei 192.168.77.0/24, en iemand stelt een tunnel voor zodat ze één netwerk zijn. De zin klinkt eenvoudig en verbergt drie verschillende ontwerpen: twee onafhankelijke LAN’s die botsen, één opzettelijk over een WAN uitgerekt Ethernet-segment, en een proxy-ARP-opstelling die voor externe adressen antwoordt. Welke je hebt bepaalt wat een host met het pakket doet, en het antwoord is zichtbaar voordat de VPN-gateway erbij betrokken is.

De host beslist vóór de router

Een host met adres 192.168.77.10/24 vergelijkt de bestemming met zijn eigen prefix. Alles binnen die prefix is on-link, dus de host lost het linklaagadres van de bestemming direct op. Alles daarbuiten gaat naar de standaardgateway.

Die beslissing valt in de stack van de host, niet in de tunnel. Een route die op de gateway wordt toegevoegd kan een pakket niet redden dat de host er nooit heen stuurt.

Dus wanneer 192.168.77.20 alleen op de andere locatie bestaat, vraagt de lokale host er met ARP naar en krijgt geen antwoord. De VPN-handshake kan volkomen gezond zijn terwijl dit faalt. De fout ziet eruit als een dode host en niet als een routeringsprobleem. Die signatuur herkennen scheelt een uur tunneldebugging.

ARP is een vraag over de lokale link

ARP vraagt wie een adres op deze link bezit, en het antwoord moet komen van iets dat de broadcast hoort. Een router aan de andere kant van een IPsec-tunnel hoort die niet, tenzij het ontwerp de twee locaties één broadcastdomein maakt.

Twee apparaten met hetzelfde adres maken het erger: zelfs een geslaagde resolutie kan niet zeggen welke antwoordde.

Dubbele adressering is geen routeringsfout en geen enkele route lost het op. Of de locaties worden hernummerd naar verschillende prefixen, of ze worden met opzet één linklaagdomein.

Een uitgerekt segment draagt frames, geen routes

Een tunnel die Ethernet draagt en aan bridges hangt, maakt beide locaties deel van één linklaagdomein. ARP-broadcasts bereiken de overkant, en elke bridge leert welke MAC-adressen waar zitten. De documentatie van de Linux-bridge beschrijft die op MAC gebaseerde doorstuurbaarheidsgrens.

Hier routeert de externe gateway helemaal niet tussen twee identieke subnetten. Frames gaan door een onderlaag die zelf IP routeert, terwijl de bridges het Ethernet-gesprek verlengen.

De prijs is een grotere impactstraal. Flooding naar onbekende bestemmingen, lussen, DHCP-toewijzing en unieke adressering vragen allemaal één plan dat beide locaties omvat. Als de WAN wegvalt, verliezen hosts verkeer dat zij als lokaal beschouwen. Filteren op de bridge en VLAN-regels kunnen beperken wat oversteekt, maar transport belooft nog steeds niet dat elk lokaal besturingsframe aankomt.

Proxy ARP is een derde ontwerp

Een router kan ARP beantwoorden voor een extern adres en er dan naartoe routeren. Dat laat de externe host voor de afzender on-link lijken zonder een broadcastdomein uit te rekken.

Het is een smaller gereedschap dan bridging: het hangt af van doorsturen, retourroutes en een duidelijke eigenaar per adres.

Het maakt ook willekeurige niet-IP-protocollen niet routeerbaar, en het reproduceert geen Ethernet-broadcastdomein. Gebruik het wanneer de eis precies die vervanging is, niet als snelkoppeling voor uitgestelde hernummering.

Kies op basis van de eis en verifieer dan

Voor gewone toegang tot toepassingen tussen kantoren geven aparte prefixen en expliciete routes een duidelijker grens. Bridge wanneer de eis echt linklaag-buurschap is. Hernummer wanneer de enige reden voor het gedeelde prefix is dat niemand het nog heeft gedaan.

Bevestig welk ontwerp je werkelijk hebt door een host te vragen wat hij met de bestemming doet:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

Een on-link-resultaat met een mislukte buuringang wijst op een ontbrekend linklaagpad. Een via-resultaat noemt de gateway en verplaatst de vraag naar routering. Op een bridge, controleer de doorstuurdatabase om te zien of de MAC via de tunnel is geleerd. Elke uitvoer vernauwt de ontwerpvraag in plaats van hem opnieuw te beginnen.

Gerelateerde artikelen