169.254 over en VPN: adressen var aldri rutbar
En link-local-destinasjon forkastes før den når tunnelen, så flere ruter gjør bare feilen bredere. Velg mellom å reparere subnettet og å bygge en bro.
Du legger til ruten, tunnelen kommer opp, og likevel dør ping til den andre siden med totalt tap i stedet for «network unreachable». Forskjellen betyr noe, fordi den peker bort fra rutetabellen og mot adressen selv. En 169.254-destinasjon er link-local, og rekkevidden slutter ved første hopp av design, ikke av feilkonfigurasjon.
Beslutningen som følger er smal og bør tas eksplisitt: reparer subnettet på serversiden, eller utvid lag 2-segmentet slik at adressen igjen gir lokal mening. Alt annet, også en bredere rute, gjør bare at samme feil gjelder for flere destinasjoner.
Adressen er ikke uten rute, den er ikke rutbar
IPv4 link-local-adresser tildeler seg selv når ingenting bedre svarer; det er bakgrunnen for den automatiske private adresseringen i Windows og tilsvarende på andre systemer. Området brukes på hver lenke samtidig, og nettopp derfor virker det: to verter i samme segment kan snakke sammen uten noen koordinering.
Samme egenskap er grunnen til at en ruter ikke skal videresende slike pakker mellom nettverk. Å motta en pakke adressert til en link-local-destinasjon og sende den ut på et annet grensesnitt ville skape tvetydighet, fordi avsenderens «lokale» og mottakerens «lokale» er forskjellige steder. Det finnes ingen oppslag som kan avgjøre hvilken av de to avsenderen mente. Videresending er ikke et policyvalg en administrator kan slå på her; adresseklassen utelukker det.
Så en gateway som installerer 169.254.1.10 som nåbar gjennom tunnelen, ber kjernen om noe adresseformatet forbyr. Pakken forkastes lenge før den når den fjerne verten, og ingen rutepresisjon endrer det.
Hvorfor en tunnel gjør rekkeviddeproblemet synlig
Et TUN-grensesnitt bærer IP-pakker mellom to parter og har ingen delt segment bak seg. Det finnes ingen kringkasting, ingen ARP for den andre siden og ingen nabo-oppdagelse som kan løse en link-local-destinasjon til en lenkelagsadresse.
Symptomene passer nøyaktig når en vet hva en skal se etter. Ruten finnes i tabellen, ping rapporterer totalt tap i stedet for et utilgjengelig nettverk, og nabotabellen viser en ufullstendig eller mislykket oppføring. Et opptak på tunnelen viser pakken forlate, noe som får folk til å se på den fjerne enden i stedet for adresseklassen.
I Windows finnes et andre, tilsynelatende urelatert symptom med samme rot: en adapter som bare har en link-local-adresse, har ingen brukbar gateway, så nettverksidentifikasjon kan ikke klassifisere forbindelsen og brannmurprofilen havner på offentlig. Tunnelen er ikke årsaken; adressen er det.
Avgjør med tre spørsmål
Valget mellom å reparere subnettet og å bro lenken avhenger av tre betingelser, og hvilken som helst av dem kan avgjøre det før du åpner en konfigurasjonsfil.
| 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 fleste tilfeller stopper ved første spørsmål. En vert med link-local-adresse betyr vanligvis at DHCP ikke svarte, at en kabel eller VLAN er feil, eller at noen skrev adressen for hånd. Å reparere det er billigere enn alt tunnelarbeid og fjerner problemet for hver fremtidige klient, ikke bare denne.
Kontroller serversiden før du antar noe. Kjør ip addr show og ip route på verten, og arp -n eller route print -4 på klienten, for å se om prefikset faktisk finnes eller om bare en gammel oppføring påstår det.
Hva en bro koster når den er det riktige svaret
Å bro en fysisk adapter med en TAP-adapter gjør den fjerne klienten til en del av det lokale kringkastingsdomenet. Da virker kringkasting og nabo-oppdagelse, og en link-local-adresse gir igjen mening fordi klienten faktisk er lokal på den lenken.
Kostnadene er reelle og bør nevnes før noen godtar. Kringkastingstrafikk krysser tunnelen, klienten er utsatt for det lokale segmentet for alle formål og ikke bare tjenestene den trenger, og serveren må nå videresende rammer i stedet for å rute pakker. Det er en rimelig bytte for en laboratoriebenk eller en enhet uten rutbar konfigurasjonsvei, og en dårlig standard for fjernadgang.
Når du bro, trengs begge halvdeler: broen på serveren og en rute i klientprofilen som sier hvilke destinasjoner som ligger på den andre siden. En bro alene lar klienten gjette, og en rute alene kan ikke reparere en adresseklasse.