IPv6 link-local virker ikke over VPN: hvorfor fe80 stopper ved linket
En fe80::-adresse betyder kun noget på ét link. Se hvorfor en routet VPN ikke kan bære den, hvordan fejlen ser ud, og hvilken adresse du skal bruge i stedet.
Du rejser tunnelen, pinger fe80::1 med tunnelen som kildeinterface og får intet tilbage. Det er ikke en firewallregel, du har glemt. En link-local-adresse betyder kun noget på det ene link, hvor den blev dannet, og en routet VPN er ikke det link. Den fjerne routers fe80::1 lever på det fjerne LAN-segment; du sidder et hop væk på et andet segment, og IPv6 har slet ingen mekanisme til, at en router videresender link-local-pakker.
Præfikset fe80 beskriver et omfang, ikke et interval
Link-local unicast er fe80::/10, og den afgørende egenskab er ikke tallet, men omfanget. Adressen gælder kun på ét link, og hvert interface danner en ud fra sin egen identifikator; derfor kan to uafhængige maskiner på to uafhængige netværk begge svare på fe80::1 uden den mindste konflikt. Præfikset siger stort set “på et eller andet link”; selve linket kommer fra konteksten.
På en vært er den kontekst zonen, eller scope-ID'et, som du tilføjer efter et procenttegn: fe80::1%eth0 på Linux, fe80::1%3 eller fe80::1%12 på Windows og i værktøjer, der viser interfaceindekser. Kernen opløser adressen sammen med interfaceindekset og sender så. Fjerner du zonen, er destinationen tvetydig, så stakken har ingen måde at vælge et segment på.
Hvorfor en routet tunnel ikke kan levere den
En routet VPN er et punkt-til-punkt-interface, der bærer sine egne adresser, normalt et /64 unikt-lokalt eller privat IPv6-rum inde i tunnelen. Det fjerne LAN er et separat link, nået ved at tunnelendepunktet router og videresender på dine vegne. Det er to forskellige segmenter, så en adresse fra det ene er ikke en gyldig destination på det andet.
Videresendelsesreglen står eksplicit i standarden og er ikke en særhed i din klient: routere videresender ikke pakker med link-local kilde eller destination. Derfor dør pakken, selv når rutetabellen ser korrekt ud. Tilføj en rute for fe80::/64 mod tunnelen, og en standardkonform stak afviser den enten eller accepterer den og kaster hver matchende pakke væk: destinationens omfang siger “kun dette link”, og det udgående interface er ikke det link.
Nabo-opdagelse forstærker samme grænse. Værter opløser link-local næste hop med naboanmodning sendt til multicast med linkomfang og en hopgrænse på 255, så routere kan afvise alt videresendt. At få det til at virke over en tunnel ville betyde at proxies opdagelsen for et fjernt segment, hvilket er lag 2-bro i en anden hat.
Der er en mere stille anden fejl, og den får folk til at snuble, når de alligevel forsøger at tvinge ruten igennem: zonen. Den zone, du skriver lokalt, navngiver tunnelinterfacet, mens den adresse, du vil have, er bundet til det fjerne LAN-interface. De to mødes aldrig, så pakken kan ikke styres til det rigtige interface i den fjerne ende.
Hvordan fejlen ser ud i praksis
Værktøjsoutput for en omfangsfejl læses som en routing- eller firewallfejl, og det er præcis derfor, folk bruger en eftermiddag i det forkerte lag.
| What you run | What you see | What it means |
|---|---|---|
| ping fe80::1 with no zone | Invalid argument on Linux, or a transmit failure on Windows | The stack cannot pick an interface for an ambiguous destination |
| ping -6 -I tun0 fe80::1 | Destination unreachable, or a silent timeout | The address is not on the tunnel link, so there is nothing on-link to answer |
| ssh user@fe80::1 after the tunnel is up | Hangs, then no route to host | The SYN never left the machine in a deliverable form; the server logs nothing |
| ip -6 neigh show dev tun0 | Empty table | No neighbor entry can exist for a link-local host that is not on this link |
| fe80::/64 inside AllowedIPs or route-ipv6 | Config accepted, traffic still dropped | The tunnel carried the packet; the receiving stack refused to forward it |
Den tredje række spilder mest tid, fordi en ssh-klient uden output ligner et problem med en lyttende tjeneste. Hvis du har nogen som helst vej ind, så se på den fjerne side og bekræft, om sshd er bundet til alle adresser eller kun én.
Brug en adresse, der var beregnet til at blive routet
Til alt, du skal nå gennem tunnelen, brug den adresse, tjenesten fik til netop det formål: en global unicast-adresse eller en unikt-lokal adresse fra fc00::/7, det interval, der er reserveret præcis til dette interne tilfælde. Bekræft, at lytteren faktisk binder den, og bekræft returvejen og enhver firewallregel på værten.
Se på den fjerne vært i stedet for at gætte. ip -6 addr show viser de adresser, der findes, og ss -6 -ltn viser, hvad dæmonen lytter på. En tjeneste, der kun er bundet til fe80::, kan kun nås fra sit eget segment, hvilket normalt er en standard, ingen valgte med vilje, og som kan ændres med administratorns accept.
Når tjenesten virkelig ikke kan genbindes, flyt broen op til applikationslaget i stedet for netværkslaget. En relæ på den fjerne vært, der lytter på en rutbar adresse og forbinder til link-local-adressen, løser problemet uden at udvide noget segment:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Her sidder zonen på den rigtige side, på den vært, der faktisk har eth0 på det link. Din klient taler med fd00:1:2::10, som router normalt, og relæet gør link-local-hoppet lokalt. Det samme trick virker til en applances web-UI eller en gammel BMC, der kun annoncerer en link-local-adresse.
Hvornår broing virkelig er svaret, og hvad du skal tjekke
Nogle installationer har virkelig brug for ét fælles segment: en enhed, der kun taler link-local-opdagelse, en appliance, der afhænger af multicast, et laboratorium, der genskaber et fladt LAN. Det er et lag 2-problem, og det kræver et lag 2-svar, såsom en tap-enhed, der er broet til det fjerne interface, eller et klientprodukt med en eksplicit broet tilstand. Det koster dig broadcast- og multicasttrafik gennem tunnelen plus nabo-opdagelse, der skal virke end to end.
Tilnærm det ikke ved at tilføje fe80::/64 til en routet profil. Det giver den værste tilstand af alle: konfigurationen ser færdig ud, rutetabellen viser en post, og hver pakke bliver stadig kasseret et sted mellem to stakke, der begge opfører sig korrekt.
Bekræft med interfacet i stedet for ping. ip -6 addr show tun0 fortæller dig, om tunnel-linket dannede sin egen link-local-adresse, og ip -6 route get fe80::1%tun0 fortæller, hvad kernen faktisk ville gøre med en destination med omfang. Når kernen siger, at destinationen ikke kan nås på det interface, ændrer ingen tunnelindstilling det, og det er tid at holde op med at redigere profilen.
En kort rækkefølge, der afgør spørgsmålet:
- Læs adressen på den fjerne vært, og notér, om det er fe80:: eller et rutbart præfiks.
- Hvis det er fe80::, så genbind tjenesten, relay på den vært, eller bro segmentet; hvis det er rutbart, så ret ruten, firewallen eller bind-adressen.
- Tjek zonen hver gang, du tester igen, fordi en kopieret kommando normalt beholder det forkerte interface.