IPv6 link-local funktionéiert net iwwer VPN: firwat fe80 um Link stoe bleift
Eng fe80:: Adress huet nëmmen op engem eenzege Link Bedeitung. Kuckt firwat e geroutete VPN se net ka droen, wéi de Feeler ausgesäit a wéi eng Adress Dir amplaz benotze sollt.
Dir hiewt den Tunnel op, pingt fe80::1 mat dem Tunnel als Quellinterface, a kritescht näischt zréck. Dat ass keng Firewall-Reeg déi Dir vergiess hutt. Eng Link-local-Adress huet nëmmen op deem eenzege Link Bedeitung wou se geformt gouf, an e geroutete VPN ass net dee Link. D'fe80::1 vum Remote-Router läit um Remote-LAN-Segment; Dir sidd ee Hop wäit ewech op engem aneren Segment, an IPv6 huet iwwerhaapt kee Mechanismus fir engem Router erlaabt, Link-local-Paketen ze viruleeden.
De fe80-Präfix beschreift e Beräich, net eng Rei
Link-local Unicast ass fe80::/10, an déi definéierend Eigenschaft ass net d'Zuel, mä de Beräich. D'Adress ass nëmmen op engem Link gülteg, an all Interface formt eng aus sengem eegenen Identifiant, dofir kënnen zwee onofhängeg Maschinnen op zwee onofhängeg Netzwierker allebéid op fe80::1 äntweren, ouni dee klengsten Konflikt. De Präfix seet am Grond „op engem Link“; de Link selwer kënnt aus dem Kontext.
Op engem Host ass dee Kontext d'Zon, oder d'Scope ID, déi Dir no engem Prozentzeechen ubréngt: fe80::1%eth0 op Linux, fe80::1%3 oder fe80::1%12 op Windows an a Geschier déi Interface-Indizes weisen. De Kernel léist d'Adress zesumme mam Interface-Index a schéckt dann. Loosst Dir d'Zon ewech, ass den Destinatioun zweedeiteg, dofir huet de Stack keng Méiglechkeet, e Segment ze wielen.
Firwat en gerouteten Tunnel en net liwwere kann
E geroutete VPN ass en Punkt-zu-Punkt Interface mat sengen eegenen Adressen, meeschtens en /64 aus dem Unique-local- oder private IPv6-Raum am Tunnel. D'Remote-LAN ass en separate Link, dee vum Tunnel-Endpunkt erreecht gëtt, dee fir Iech routet a viruleet. Dat sinn zwee verschidde Segmenter, dofir ass eng Adress vun engem keng gülteg Destinatioun um aneren.
D'Viruleedungsreegel steet explizit am Standard, et ass keng Marotte vum Client: Routere leede keng Pakete mat enger Link-local-Quell oder -Destinatioun virun. Dofir stierft de Paket och dann, wann d'Routentabelle richteg ausgesäit. Füügt eng Route fir fe80::/64 op den Tunnel bäi, an en normkonforme Stack entweder refuséiert se oder akzeptéiert se a verwërft all passende Paket: de Beräich vun der Destinatioun seet „nëmmen dësen Link“, an dat ausgänglech Interface ass net dee Link.
D'Nopeschdetektioun verstäerkt déiselwecht Grenz. Hoste léisen Link-local Nächst-Hoppe mat enger Nopesch-Ufro, déi op Link-scoped Multicast mam Hop-Limit 255 geschéckt gëtt, dofir kënnen Routere verwerfen wat viruleet gëtt. Dat iwwer en Tunnel schaffen ze maachen, géif bedeiten, d'Detektioun fir e Remote-Segment ze proxyen, wat Layer 2 Bridging mat engem anere Hutt ass.
Et gëtt eng méi roueg zweet Feelfunktioun, an si erwëscht Leit déi d'Route trotzdem forcéieren: d'Zon. Wéi eng Zon Dir lokal agitt, si nennt den Tunnel-Interface, wärend d'Adress déi Dir wëllt um Remote-LAN-Interface gebonnen ass. Déi zwou passen ni zesummen, dofir kann de Paket um wäiten Enn net op den richtegen Interface gestierlt ginn.
Wéi de Feeler an der Praxis ausgesäit
D'Ausgab vun engem Tool fir e Beräichsfehler liest sech wéi e Routing- oder Firewall-Fehler, an dofir verbréngen d'Leit en Nomëtteg am falsche Schicht.
| 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 |
Déi drëtt Zeil verléiert am meeschten Zäit, well en ssh-Client ouni Ausgab wéi e Problem mat engem Service ausgesäit deen zouhéiert. Wann Dir iergendeen Wee erakënnt, kuckt d'wäit Säit a bestätegt, ob sshd u all Adressen oder nëmmen un eng gebonnen ass.
Benotzt eng Adress, déi fir Routing geduecht war
Fir alles wat Dir duerch den Tunnel erreeche musst, benotzt d'Adress déi dem Service genee fir dësen Zweck ginn ass: eng global Unicast-Adress, oder eng Unique-local-Adress aus fc00::/7, de Beräich dee genee fir dësen internen Fall reservéiert ass. Bestätegt datt de Listener se wierklech bindt, a kontrolléiert de Retourwee an all Firewall-Reeg vum Host.
Kuckt den Remote-Host amplaz ze roden. ip -6 addr show lëscht d'Adressen déi existéieren, an ss -6 -ltn lëscht wat den Daemon zouhéiert. E Service deen nëmmen un fe80:: gebonnen ass, ass nëmmen aus sengem eegene Segment erreechbar, wat meeschtens en Default ass deen keen absichtlech gewielt huet an dee mam Averständnis vum Administrateur geännert ka ginn.
Wann de Service wierklech net nei ka gebonne ginn, hieft d'Bréck op d'Applikatiounsschicht amplaz vun der Netzwierkschicht. Eng Relay um Remote-Host déi op enger routbarer Adress zouhéiert an sech mat der Link-local verbënnt, léist de Problem ouni ee Segment ze erweideren:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Hei sëtzt d'Zon op der richteger Säit, um Host deen tatsächlech eth0 op deem Link huet. Äre Client schwätzt mat fd00:1:2::10, dat normal geroutet gëtt, an d'Relay mécht den Link-local-Hop lokal. Dee selwechte Trick funktionnéiert fir eng Web-UI vun engem Apparat oder en alen BMC deen nëmmen eng Link-local-Adress annoncéiert.
Wann Bridging wierklech d'Äntwert ass, a wat ze kontrolléieren
Verschidde Deploymente brauchen tatsächlech ee gemeinsaamt Segment: en Apparat deen nëmmen Link-local-Detektioun schwätzt, en Apparat deen op Multicast ugewise ass, eng Labor déi e flaachen LAN reproduzéiert. Dat ass e Layer 2 Problem an et brauch eng Layer 2 Äntwert, wéi en Tap-Apparat deen op den Remote-Interface gebréckt ass oder e Clientprodukt mat engem explizitte Bridged-Modus. Et kascht Iech Broadcast- a Multicast-Traffic deen den Tunnel iwwerquiert plus Nopeschdetektioun déi Enn-zu-Enn musse funktionnéieren.
Approximéiert et net andeems Dir fe80::/64 an e geroutete Profil bäifüügt. Dat produzéiert de schlëmmsten Zoustand: d'Konfiguratioun gesäit fäerdeg aus, d'Routentabelle weist en Agang, an all Paket gëtt nach ëmmer irgendwou tëschent zwee Stacks verworf, déi sech allebéid richteg behuelen.
Verifizéiert mam Interface an net mam ping. ip -6 addr show tun0 seet Iech ob de Tunnel-Link seng eege Link-local-Adress geformt huet, an ip -6 route get fe80::1%tun0 seet Iech wat de Kernel tatsächlech mat enger scoped Destinatioun géif maachen. Wann de Kernel seet d'Destinatioun ass op deem Interface net erreechbar, ännert keng Tunnel-Astellung dat, an et ass Zäit ophale mam Profil z'änneren.
Eng kuerz Sequenz déi d'Fro klärt:
- Liest d'Adress um Remote-Host a notéiert ob se fe80:: oder e routbare Präfix ass.
- Wann et fe80:: ass, bindt de Service nei, maacht Relay op deem Host oder bréckt de Segment; wann et routbar ass, fléckt d'Route, d'Firewall oder d'Bind-Adress.
- Kontrolléiert d'Zon all Kéier wann Dir nei testt, well en kopéierte Befehl meeschtens den falschen Interface behält.
Quellen: RFC 4291, IPv6-Adressarchitektur.