169.254 via een VPN: het adres was nooit routeerbaar
Een link-local-bestemming wordt weggegooid voordat de tunnel wordt bereikt, dus extra routes maken de fout alleen breder. Kies tussen het subnet repareren en een brug bouwen.
Je voegt de route toe, de tunnel komt op, en toch sterft de ping naar de overkant met volledig verlies in plaats van «network unreachable». Dat verschil is belangrijk, want het wijst van de routetabel naar het adres zelf. Een 169.254-bestemming is link-local, en het bereik eindigt per ontwerp bij de eerste hop, niet door een verkeerde configuratie.
De beslissing die volgt is smal en verdient het expliciet te worden genomen: repareer het subnet aan de serverkant, of breid het laag-2-segment uit zodat het adres weer lokaal betekenis krijgt. Al het andere, ook een bredere route, maakt alleen dat dezelfde fout voor meer bestemmingen geldt.
Het adres is niet routeloos, het is niet routeerbaar
IPv4 link-local adressen kennen zichzelf toe wanneer niets beters antwoordt; daar komt de automatische private adressering in Windows vandaan en het equivalent in andere systemen. De reeks wordt tegelijk op elke verbinding gebruikt, en juist daarom werkt het: twee hosts in hetzelfde segment praten zonder enige coördinatie.
Diezelfde eigenschap is de reden dat een router deze pakketten niet tussen netwerken mag doorsturen. Een pakket voor een link-local-bestemming ontvangen en via een andere interface naar buiten sturen zou dubbelzinnigheid scheppen, omdat «lokaal» bij de afzender en «lokaal» bij de ontvanger verschillende plaatsen zijn. Geen enkele opzoeking kan beslissen welke van de twee bedoeld was. Doorsturen is hier geen beleidsoptie die een beheerder kan aanzetten; de adresklasse sluit het uit.
Een gateway die 169.254.1.10 als bereikbaar via de tunnel instelt, vraagt de kernel dus iets wat het adresformaat verbiedt. Het pakket wordt weggegooid lang voordat het de verre host bereikt, en geen routespecificiteit verandert dat.
Waarom een tunnel het bereikprobleem zichtbaar maakt
Een TUN-interface draagt IP-pakketten tussen twee peers en heeft geen gedeeld segment achter zich. Er is geen broadcast, geen ARP voor de andere kant en geen buurdetectie die een link-local-bestemming in een linklaagadres kan omzetten.
De symptomen kloppen precies als je weet waar je moet kijken. De route staat in de tabel, ping meldt volledig verlies in plaats van een onbereikbaar netwerk, en de buurtabel toont een onvolledige of mislukte vermelding. Een opname op de tunnel laat het pakket vertrekken, waardoor mensen naar het verre uiteinde kijken in plaats van naar de adresklasse.
In Windows is er een tweede, schijnbaar ongerelateerd symptoom met dezelfde wortel: een adapter met alleen een link-local adres heeft geen bruikbare gateway, dus netwerkidentificatie kan de verbinding niet classificeren en het firewallprofiel belandt op openbaar. De tunnel is niet de oorzaak; het adres is dat.
Beslis met drie vragen
De keuze tussen het subnet repareren en de verbinding overbruggen hangt van drie voorwaarden af, en elk daarvan kan het beslissen voordat je een configuratiebestand opent.
| Question | If yes | If no |
|---|---|---|
| Can the far-side host be given a routable address? | Change the host or fix DHCP and route normally | Continue to the next question |
| Does the device accept a static address at all? | Assign one from the site's real prefix | Bridging is the only remaining option |
| Can you accept broadcast crossing the tunnel? | A bridge is viable for a small segment | Replace the device or accept no remote access |
De meeste gevallen stoppen bij de eerste vraag. Een host met een link-local adres betekent meestal dat DHCP niet antwoordde, dat een kabel of VLAN verkeerd is, of dat iemand het adres met de hand heeft getypt. Dat repareren is goedkoper dan welk tunnelwerk dan ook en haalt het probleem weg bij elke toekomstige client, niet alleen bij deze.
Controleer de serverkant voordat je iets aanneemt. Voer ip addr show en ip route uit op de host, en arp -n of route print -4 op de client, om te zien of het prefix echt bestaat of dat alleen een oude vermelding dat beweert.
Wat een brug kost als die het juiste antwoord is
Een fysieke adapter overbruggen met een TAP-adapter maakt de verre client deel van het lokale broadcastdomein. Dan werken broadcast en buurdetectie, en een link-local adres krijgt weer betekenis omdat de client echt lokaal op die verbinding is.
De kosten zijn reëel en moeten genoemd worden voordat iemand instemt. Broadcastverkeer gaat door de tunnel, de client staat voor elk doel bloot aan het lokale segment en niet alleen aan de diensten die hij nodig heeft, en de server moet nu frames doorsturen in plaats van pakketten te routeren. Dat is een redelijke ruil voor een laboratoriumbank of een apparaat zonder routeerbaar configuratiepad, en een slechte standaard voor toegang op afstand.
Als je overbrugt, zijn beide helften nodig: de brug op de server en een route in het clientprofiel die zegt welke bestemmingen aan de andere kant liggen. Een brug alleen laat de client raden, en een route alleen kan geen adresklasse repareren.