IPv6 link-lokaal adres wurket net oer in VPN: wêrom't fe80 by de link bliuwt
In fe80::-adres betsjut allinnich eat op ien link. Sjoch wêrom't in routed VPN it net drage kin, hoe't de flater der útsjocht en hokker adres jo ynstee brûke moatte.
Jo bringe de tunnel omheech, pingje fe80::1 mei de tunnel as boarne-ynterface, en krije neat werom. It is gjin firewallregel dy't jo fergetten binne. In link-lokaal adres betsjut allinnich eat op it iene link dêr't it foarme is, en in routed VPN is dat link net. De fe80::1 fan de fiere router wennet op it fiere LAN-segment; jo sitte ien hop fierder op in oar segment, en IPv6 hat gjin inkel meganisme foar in router om link-lokale pakketten hielendal troch te stjoeren.
It foarheaksel fe80 beskriuwt in berik, net in rige
Link-lokale unicast is fe80::/10, en de bepalende eigenskip is net it getal mar it berik. It adres jildt allinnich op ien link, en elk ynterface foarmet der ien út syn eigen identifikaasje; dêrom kinne twa lossteande masines op twa lossteande netwurken beide antwurdzje op fe80::1 sûnder de minste konflikt. It foarheaksel seit yn wêzen “op ien of oar link”; it link sels komt út de kontekst.
Op in host is dy kontekst de sône, of de scope-ID, dy't jo nei in persintaazjeteken tafoegje: fe80::1%eth0 op Linux, fe80::1%3 of fe80::1%12 op Windows en yn ark dy't ynterface-yndeksen sjen litte. De kearn lost it adres op tegearre mei de ynterface-yndeks en stjoert dan. Lit de sône wei en de bestimming is dûbelsinnich, sadat de stapel gjin manier hat om in segment te kiezen.
Wêrom't in routed tunnel it net leverje kin
In routed VPN is in punt-nei-punt-ynterface dat syn eigen adressen draacht, meastentiids in /64 fan unyk-lokaal of privee IPv6-romte binnen de tunnel. It fiere LAN is in apart link, berikt troch it tunnel-einpunt dat foar jo routet en trochstjoert. Dat binne twa ferskillende segminten, dus in adres út it iene is gjin jildige bestimming op it oare.
De trochstjoerregel is eksplisyt yn 'e standert en net in eigensinnigens fan jo klant: routers stjoere gjin pakketten troch mei in link-lokale boarne of bestimming. Dêrom stjert it pakket sels as de routingtabel korrekt liket. Foegje in rûte foar fe80::/64 ta nei de tunnel, en in standertkonforme stapel ferwurpet dy óf akseptearret him en smyt elk oerienkommend pakket fuort: it berik fan 'e bestimming seit “allinnich dit link”, en it útgeande ynterface is dat link net.
Buortûkening fersterket deselde grins. Hosts lossen link-lokale folgjende hops op mei in buorrequest dat nei link-berik-multicast stjoerd wurdt mei in hoplimyt fan 255, sadat routers alles wat trochstjoerd wurdt ferwerpe kinne. Dat oer in tunnel wurkje litte soe betsjutte dat de tûkening foar in fier segment as proxy dien wurdt, wat laach-2-brêgen is mei in oare hoed.
Der is in stiller twadde flater, en dy lit minsken stroffelje dy't de rûte dochs trochdrukke wolle: de sône. Hokker sône jo lokaal ek yntypje, it neamt it tunnel-ynterface, wylst it adres dat jo wolle bûn is oan it fiere LAN-ynterface. De beide komme nea oerien, sadat it pakket oan 'e fiere kant net nei it goede ynterface stjoerd wurde kin.
Hoe't de flater der yn 'e praktyk útsjocht
Ark-útfier foar in berikflater lêst as in routing- of firewallflater, en dat is krekt wêrom't minsken in middei yn 'e ferkearde laach trochbringe.
| 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 |
De tredde rige fergriemt de measte tiid, want in ssh-klant sûnder útfier liket op in probleem fan in tsjinjende tsjinst. As jo hokker tagong dan ek hawwe, sjoch dan nei de fiere kant en befêstigje oft sshd oan alle adressen of mar oan ien bûn is.
Brûk in adres dat bedoeld wie om routed te wurden
Brûk foar alles dat jo troch de tunnel berikke moatte it adres dat de tsjinst krekt dêrfoar krigen hat: in wrâldwiid unicast-adres, of in unyk-lokaal adres út fc00::/7, it berik dat krekt foar dit ynterne gefal reservearre is. Befêstigje dat de listener it echt bynt, en kontrolearje it werompaad en elke host-firewallregel.
Sjoch nei de fiere host ynstee fan te rieden. ip -6 addr show listet de adressen dy't bestean, en ss -6 -ltn listet wêr't de daemon nei harket. In tsjinst dy't allinnich oan fe80:: bûn is, is allinnich fan syn eigen segment berikber, wat meastentiids in standertynstelling is dy't nimmen bewust keazen hat en dy't mei tastimming fan 'e behearder feroare wurde kin.
As de tsjinst echt net opnij bûn wurde kin, ferpleats de brêge dan nei de applikaasjelaach ynstee fan 'e netwurklach. In trochstjoerder op 'e fiere host dy't nei in routber adres harket en ferbynt mei it link-lokale, lost it probleem op sûnder in segment út te wreidzjen:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Hjir sit de sône oan 'e goede kant, op 'e host dy't wier eth0 op dat link hat. Jo klant praat mei fd00:1:2::10, dat normaal routet, en de trochstjoerder makket de link-lokale hop lokaal. Deselde trúk wurket foar in web-ynterface fan in apparaat of in âlde BMC dy't allinnich in link-lokaal adres oankundiget.
Wannear't brêgen echt it antwurd is, en wat te kontrolearjen
Guon ynstallaasjes hawwe echt ien mienskiplik segment nedich: in apparaat dat allinnich link-lokale tûkening praat, in apparaat dat fan multicast ôfhinklik is, in laboratoarium dat in plat LAN neibeart. Dat is in laach-2-probleem en it hat in laach-2-antwurd nedich, lykas in tap-apparaat dat nei it fiere ynterface brêge is of in klantprodukt mei in eksplisite brêgemodus. It kostet jo broadcast- en multicast-ferkear oer de tunnel plus buortûkening dy't fan begjin oant ein wurkje moat.
Benaderje it net troch fe80::/64 oan in routed profyl ta te foegjen. Dat jout de slimste steat fan allegear: de konfiguraasje liket klear, de routingtabel toant in ynfier, en elk pakket wurdt noch altyd earne tusken twa stapels weilitten dy't beide korrekt hâlde en drage.
Kontrolearje mei it ynterface ynstee fan de ping. ip -6 addr show tun0 fertelt jo oft it tunnel-link syn eigen link-lokaal adres foarme hat, en ip -6 route get fe80::1%tun0 fertelt wat de kearn wier mei in berikbestimming dwaan soe. As de kearn seit dat de bestimming op dat ynterface net berikber is, sil gjin tunnelynstelling dat feroarje, en is it tiid om de profyl net mear te bewurkjen.
In koarte searje dy't de fraach beslist:
- Lês it adres op 'e fiere host en tink derop oft it fe80:: of in routber foarheaksel is.
- As it fe80:: is, byn de tsjinst opnij, stjoer troch op dy host of brêgje it segment; is it routber, reparearje dan de rûte, de firewall of it bynadres.
- Kontrolearje de sône elke kear as jo opnij testen, want in kopiearre opdracht hâldt meastentiids it ferkearde ynterface.
Boarnen: RFC 4291, IPv6-adressearingsarsjitektuer.