Hindi gumagana ang IPv6 link-local sa VPN: bakit humihinto ang fe80 sa link
Ang fe80:: address ay may kahulugan lamang sa isang link. Tingnan kung bakit hindi ito madala ng rutadong VPN, ano ang hitsura ng kabiguan, at aling address ang gamitin sa halip.
Inaangat mo ang tunnel, piniping mo ang fe80::1 gamit ang tunnel bilang source interface, at walang bumabalik. Hindi ito nakalimutang firewall rule. Ang link-local address ay may kahulugan lamang sa nag-iisang link kung saan ito nabuo, at ang rutadong VPN ay hindi ang link na iyon. Ang fe80::1 ng remote router ay nasa remote LAN segment; isang hop ang layo mo sa ibang segment, at ang IPv6 ay walang mekanismong magpadala ang router ng link-local packets.
Inilalarawan ng fe80 prefix ang saklaw, hindi hanay
Ang link-local unicast ay fe80::/10, at ang naglalarawang katangian ay hindi ang numero kundi ang saklaw. Ang address ay valid lamang sa isang link, at bawat interface ay bumubuo ng isa mula sa sariling identifier, kaya dalawang walang kaugnayang makina sa dalawang walang kaugnayang network ay parehong makakasagot sa fe80::1 nang walang kaunting salungatan. Ang prefix ay nagsasabing “sa isang link”; ang link mismo ay nagmumula sa konteksto.
Sa isang host, ang kontekstong iyon ay ang zone, o scope ID, na idinaragdag mo pagkatapos ng percent sign: fe80::1%eth0 sa Linux, fe80::1%3 o fe80::1%12 sa Windows at sa mga tool na nagpapakita ng interface index. Nireresolba ng kernel ang address kasama ng interface index at pagkatapos ay nagpapadala. Kung aalisin mo ang zone, ang destinasyon ay malabo, kaya walang paraan ang stack na pumili ng segment.
Bakit hindi ito maipadala ng rutadong tunnel
Ang rutadong VPN ay isang point-to-point interface na may sariling address, karaniwang /64 ng unique-local o pribadong IPv6 space sa loob ng tunnel. Ang remote LAN ay hiwalay na link, naaabot ng tunnel endpoint sa pamamagitan ng pagruruta at pagpapasa para sa iyo. Dalawang magkaibang segment ito, kaya ang address mula sa isa ay hindi valid na destinasyon sa isa.
Ang forwarding rule ay tahasan sa standard, hindi kapritso ng iyong client: hindi nagpapasa ang mga router ng packets na may link-local source o destination. Kaya namamatay ang packet kahit mukhang tama ang route table. Magdagdag ng ruta para sa fe80::/64 patungo sa tunnel at ang conforming stack ay tatanggihan ito o tatanggapin at itatapon ang bawat tugmang packet: sinasabi ng saklaw ng destinasyon na “itong link lang”, at ang outgoing interface ay hindi ang link na iyon.
Pinapalakas ng neighbor discovery ang parehong hangganan. Nireresolba ng mga host ang link-local next hops sa pamamagitan ng neighbor solicitation na ipinapadala sa link-scoped multicast na may hop limit na 255, kaya matatanggihan ng mga router ang anumang ipinasa. Ang gawin itong gumana sa tunnel ay nangangahulugang i-proxy ang discovery para sa remote segment, na Layer 2 bridging sa ibang sumbrero.
May pangalawang, mas tahimik na kabiguan, at nahuhuli nito ang mga taong pinipilit pa rin ang ruta: ang zone. Anumang zone na itatype mo nang lokal ay pinapangalanan ang tunnel interface, habang ang address na gusto mo ay nakatali sa remote LAN interface. Hindi kailanman nagtutugma ang dalawa, kaya hindi maididirekta ang packet sa tamang interface sa dulong bahagi.
Ano ang hitsura ng kabiguan sa praktika
Ang tool output para sa scope mistake ay parang routing o firewall error, at iyon mismo ang dahilan kung bakit ang mga tao ay gumugugol ng isang hapon sa maling layer.
| 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 |
Ang ikatlong hilera ang pinakamaraming nasasayang na oras, dahil ang ssh client na walang output ay mukhang problema ng service na nakikinig. Kung mayroon kang anumang paraan upang makapasok, tingnan ang remote side at tiyakin kung ang sshd ay nakatali sa lahat ng address o isa lamang.
Gumamit ng address na nilaan para sa pagruruta
Para sa lahat ng kailangan mong maabot sa tunnel, gamitin ang address na ibinigay sa service para sa layuning ito: isang global unicast address, o isang unique-local address mula sa fc00::/7, ang hanay na nakalaan para sa panloob na kasong ito. Tiyakin na talagang binibigkis ito ng listener, at suriin ang return path at anumang firewall rule ng host.
Tingnan ang remote host sa halip na manghula. Inililista ng ip -6 addr show ang mga address na umiiral, at inililista ng ss -6 -ltn kung ano ang pinakikinggan ng daemon. Ang service na nakatali lamang sa fe80:: ay maaabot lamang mula sa sariling segment, na karaniwang default na walang sinumang sinadyang pumili at maaaring baguhin nang may pahintulot ng administrator.
Kapag talagang hindi maaaring i-rebind ang service, iangat ang tulay sa application layer sa halip na network layer. Ang relay sa remote host na nakikinig sa rutableng address at kumokonekta sa link-local ay nilulutas ang problema nang hindi nagpapalawak ng anumang segment:
socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80Dito nasa tamang panig ang zone, sa host na talagang may eth0 sa link na iyon. Nakikipag-usap ang iyong client sa fd00:1:2::10, na normal na naruruta, at ginagawa ng relay ang link-local hop nang lokal. Gumagana rin ang parehong trick para sa web UI ng appliance o lumang BMC na nag-aanunsyo lamang ng link-local address.
Kapag ang bridging talaga ang sagot, at ano ang dapat suriin
Ang ilang deployment ay talagang nangangailangan ng isang shared segment: isang device na nagsasalita lamang ng link-local discovery, isang appliance na umaasa sa multicast, isang lab na gumagawa ng flat LAN. Problema ito ng Layer 2 at kailangan ng Layer 2 na sagot, tulad ng tap device na naka-bridge sa remote interface o client product na may tahasang bridged mode. Gastos ito ng broadcast at multicast traffic na tumatawid sa tunnel at neighbor discovery na dapat gumana mula dulo hanggang dulo.
Huwag lapitan ito sa pamamagitan ng pagdaragdag ng fe80::/64 sa rutadong profile. Gumagawa ito ng pinakamasamang estado: mukhang tapos na ang configuration, may entry ang route table, at bawat packet ay itinatapon pa rin sa isang lugar sa pagitan ng dalawang stack na parehong kumikilos nang tama.
I-verify sa interface hindi sa ping. Sinasabi ng ip -6 addr show tun0 kung ang tunnel link ay bumuo ng sariling link-local address, at sinasabi ng ip -6 route get fe80::1%tun0 kung ano talaga ang gagawin ng kernel sa isang scoped destination. Kapag sinabi ng kernel na hindi maabot ang destinasyon sa interface na iyon, walang tunnel setting ang makakabago nito, at oras na para itigil ang pag-edit ng profile.
Isang maikling pagkakasunod-sunod na nagtatapos sa tanong:
- Basahin ang address sa remote host at tandaan kung fe80:: ito o rutableng prefix.
- Kung fe80::, i-rebind ang service, mag-relay sa host na iyon, o i-bridge ang segment; kung rutable, ayusin ang ruta, firewall, o bind address.
- Suriin muli ang zone sa bawat muling pagsubok, dahil ang kinopyang command ay kadalasang nagpapanatili ng maling interface.
Mga pinagmulan: RFC 4291, arkitektura ng pag-address ng IPv6.