169.254 över en VPN: adressen var aldrig routbar
Ett link-local-mål släpps innan det når tunneln, så att lägga till rutter gör bara felet större. Välj mellan att laga subnätet och att brygga.
Du lägger till rutten, tunneln kommer upp, och pinget till andra sidan dör fortfarande med total förlust i stället för ”network unreachable”. Den skillnaden spelar roll, för den pekar bort från din routingtabell och mot adressen själv. Ett 169.254-mål är link-local, och link-local-omfånget tar slut vid första hoppet av design, inte på grund av felkonfiguration.
Beslutet som följer är snävt och värt att fatta uttryckligen: reparera subnätet på serversidan, eller förläng lager 2-segmentet så att adressen blir lokalt meningsfull igen. Allt annat, inklusive att lägga till en bredare rutt, är ett sätt att låta samma fel gälla fler mål.
Adressen saknar inte en rutt, den går inte att routa
Link-local IPv4-adresser tilldelas sig själva när inget bättre svarar, vilket är där det automatiska privata adresseringsbeteendet kommer från i Windows och motsvarande reservlösning kommer från i andra system. Intervallet används på varje länk samtidigt, och det är precis därför det fungerar: två värdar på samma segment kan prata utan någon samordning.
Samma egenskap är anledningen till att en router inte får vidarebefordra dessa paket mellan nät. Att ta emot ett paket adresserat till ett link-local-mål och skicka ut det på ett annat gränssnitt skulle skapa oklarhet, eftersom avsändarens ”lokala” och mottagarens ”lokala” är olika platser. Det finns ingen uppslagning som kan avgöra vilket av de två avsändaren menade. Vidarebefordran är inte ett policyval som en administratör kan aktivera här; adressklassen utesluter det.
Så en gateway som installerar 169.254.1.10 som nåbart via tunneln ber kärnan göra något som adressformatet förbjuder. Paketet kastas långt innan det når fjärrvärden, och ingen grad av ruttprecision ändrar det resultatet.
Varför en tunnel synliggör omfångsproblemet
Ett TUN-gränssnitt bär IP-paket mellan två parter och har inget delat segment bakom sig. Det finns ingen broadcast, ingen ARP för andra sidan och ingen grannupptäckt som kan lösa upp ett link-local-mål till en länklagradress. Även om vidarebefordran vore tillåten har klienten inget sätt att lära sig vilken part som bör svara.
Symptomen stämmer perfekt när man vet vad man ska leta efter. Rutten finns i tabellen, ping rapporterar total förlust i stället för ett onåbart nät, och grannbordet visar en ofullständig eller misslyckad post för målet. En avlyssning på tunneln visar paketet lämna, vilket får folk att titta på andra änden i stället för på adressklassen.
I Windows finns ett andra, till synes orelaterat symptom med samma rot: en adapter som bara har en link-local-adress har ingen användbar gateway, så nätverksidentifieringen kan inte klassificera anslutningen och brandväggsprofilen hamnar på public. Tunneln är inte orsaken; adressen är det.
Avgör med tre frågor
Valet mellan att reparera subnätet och att brygga länken hänger på tre villkor, och vilket som helst av dem kan avgöra det innan du öppnar en konfigurationsfil.
| 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 flesta fall stannar vid den första frågan. En värd som visar en link-local-adress betyder vanligtvis att DHCP inte svarade, att en kabel eller VLAN är fel, eller att någon skrev in adressen för hand. Att reparera det är billigare än något tunnelarbete, och det tar bort problemet för varje framtida klient i stället för bara den här. Det lämnar också platsen med ett fungerande DHCP-omfång, vilket är det du faktiskt ville ha.
Kontrollera serversidan innan du antar något. Kör ip addr show och ip route på värden, och arp -n eller route print -4 på klienten, så att du kan se om prefixet finns över huvud taget eller om en inaktuell post är det enda som påstår att det gör det.
Vad en brygga kostar när den är rätt svar
Att brygga en fysisk adapter med en TAP-adapter gör fjärrklienten till en del av den lokala broadcast-domänen. Broadcast och grannupptäckt fungerar då, och en link-local-adress blir meningsfull igen eftersom klienten verkligen är lokal på den länken.
Kostnaderna är verkliga och bör anges innan någon går med på det. Broadcast-trafik korsar tunneln, klienten exponeras mot det lokala segmentet för alla ändamål i stället för bara de tjänster den behöver, och servern måste nu vidarebefordra ramar i stället för att routa paket. Det är en rimlig avvägning för en labbänk eller en enhet utan routbar konfigurationsväg, och ett dåligt standardval för fjärråtkomst.
När du bryggar krävs båda halvorna: bryggan på servern, och en rutt i klientprofilen som talar om vilka mål som ligger på andra sidan. En brygga ensam lämnar klienten gissande, och en rutt ensam kan inte fixa en adressklass.