IPv6 link-local adresa nefunguje přes VPN: proč fe80 končí na lince

Zvednete tunel, pošlete ping na fe80::1 s tunelem jako zdrojovým rozhraním a nic se nevrátí. Není to pravidlo firewallu, na které jste zapomněli. Link-local adresa něco znamená jen na jediném linku, kde vznikla, a směrovaná VPN tím linkem není. fe80::1 vzdáleného routeru žije na vzdáleném segmentu LAN; vy sedíte o jeden skok dál na jiném segmentu a IPv6 nemá žádný mechanismus, aby router link-local pakety vůbec předával.

Prefix fe80 popisuje rozsah platnosti, ne rozmezí

Link-local unicast je fe80::/10 a určující vlastností není číslo, ale rozsah platnosti. Adresa platí jen na jednom linku a každé rozhraní si ji vytváří z vlastního identifikátoru; proto dva nesouvisející stroje ve dvou nesouvisejících sítích mohou oba odpovídat na fe80::1 bez sebemenšího konfliktu. Prefix v podstatě říká “na nějakém linku”; sám link přijde z kontextu.

Na hostiteli je tím kontextem zóna neboli scope ID, kterou přidáte za znak procenta: fe80::1%eth0 na Linuxu, fe80::1%3 nebo fe80::1%12 na Windows a v nástrojích, které ukazují indexy rozhraní. Jádro vyhodnotí adresu spolu s indexem rozhraní a pak odešle. Zónu vynechte a cíl je nejednoznačný, takže zásobník nemá jak vybrat segment.

Proč ji směrovaný tunel nedokáže doručit

Směrovaná VPN je point-to-point rozhraní, které nese vlastní adresy, obvykle /64 unikátně-lokálního nebo privátního IPv6 prostoru uvnitř tunelu. Vzdálená LAN je samostatný link, dosažený směrováním a předáváním koncového bodu tunelu vaším jménem. To jsou dva různé segmenty, takže adresa z jednoho není platným cílem na druhém.

Pravidlo předávání je výslovné ve standardu, ne zvláštnost vašeho klienta: routery nepředávají pakety s link-local zdrojem nebo cílem. Proto paket umírá, i když směrovací tabulka vypadá správně. Přidejte cestu pro fe80::/64 na tunel a zásobník odpovídající standardu ji buď odmítne, nebo přijme a zahodí každý odpovídající paket: rozsah cíle říká “jen tento link” a odchozí rozhraní tím linkem není.

Sousedské vyhledávání posiluje stejnou hranici. Hostitelé řeší link-local další skoky sousedskou výzvou poslanou na multicast s rozsahem linku a limitem skoků 255, takže routery mohou cokoli předávané odmítnout. Zprovoznit to přes tunel by znamenalo proxy vyhledávání pro vzdálený segment, což je most vrstvy 2 v jiném klobouku.

Existuje tišší druhá porucha a ta zmate lidi, kteří se cestu přesto snaží vynutit: zóna. Ať lokálně napíšete jakoukoli zónu, pojmenovává rozhraní tunelu, zatímco adresa, kterou chcete, je vázána na rozhraní vzdálené LAN. Ty dvě se nikdy neshodují, takže paket nelze na vzdáleném konci nasměrovat na správné rozhraní.

Jak porucha vypadá v praxi

Výstup nástroje při chybě rozsahu vypadá jako chyba směrování nebo firewallu, a právě proto lidé stráví odpoledne ve špatné vrstvě.

Třetí řádek ztratí nejvíc času, protože ssh klient bez výstupu vypadá jako problém služby, která naslouchá. Pokud máte jakýkoli přístup dovnitř, podívejte se na vzdálenou stranu a ověřte, zda je sshd vázán na všechny adresy, nebo jen na jednu.

Použijte adresu, která byla určena ke směrování

Pro cokoli, k čemu se potřebujete dostat tunelem, použijte adresu, kterou služba dostala právě pro tento účel: globální unicast adresu, nebo unikátně-lokální adresu z fc00::/7, rozsahu vyhrazeného přesně pro tento interní případ. Ověřte, že ji naslouchající proces skutečně váže, a ověřte zpáteční cestu a každé pravidlo firewallu na hostiteli.

Podívejte se na vzdálený hostitel, místo abyste hádali. ip -6 addr show vypíše existující adresy a ss -6 -ltn vypíše, na čem démon naslouchá. Služba vázaná jen na fe80:: je dostupná jen ze svého segmentu, což je obvykle výchozí nastavení, které nikdo nezvolil záměrně a lze je změnit se souhlasem správce.

Když službu opravdu nelze převázat, posuňte most na aplikační vrstvu místo síťové. Přenašeč na vzdáleném hostiteli, který naslouchá na směrovatelné adrese a připojuje se k link-local adrese, problém vyřeší, aniž by rozšířil kterýkoli segment:

socat TCP6-LISTEN:8080,bind=[fd00:1:2::10] TCP6:[fe80::1%eth0]:80

Tady zóna sedí na správné straně, na hostiteli, který na tom linku skutečně má eth0. Váš klient mluví s fd00:1:2::10, která se směruje normálně, a přenašeč udělá link-local skok lokálně. Stejný trik funguje pro webové rozhraní zařízení nebo starý BMC, který inzeruje jen link-local adresu.

Kdy je most opravdu odpovědí a co zkontrolovat

Některá nasazení opravdu potřebují jeden sdílený segment: zařízení, které mluví jen link-local vyhledáváním, zařízení závislé na multicastu, laboratoř reprodukující plochou LAN. To je problém vrstvy 2 a chce odpověď vrstvy 2, například tap zařízení přemostěné na vzdálené rozhraní nebo klientský produkt s explicitním mostovým režimem. Stojí vás to broadcast a multicast provoz procházející tunelem plus sousedské vyhledávání, které musí fungovat od konce ke konci.

Nepřibližujte to přidáním fe80::/64 do směrovaného profilu. Tím vznikne nejhorší stav: konfigurace vypadá hotová, směrovací tabulka ukazuje záznam a každý paket se přesto zahazuje někde mezi dvěma zásobníky, které se oba chovají správně.

Ověřujte rozhraním, ne pingem. ip -6 addr show tun0 vám řekne, zda link tunelu vytvořil vlastní link-local adresu, a ip -6 route get fe80::1%tun0 řekne, co by jádro s cílem v rozsahu skutečně udělalo. Když jádro řekne, že cíl je na tomto rozhraní nedostupný, žádné nastavení tunelu to nezmění a je čas přestat upravovat profil.

Krátká posloupnost, která otázku rozřeší:

• Přečtěte adresu na vzdáleném hostiteli a poznamenejte, zda je fe80::, nebo směrovatelný prefix.
• Pokud je fe80::, převažte službu, přesměrujte na tom hostiteli, nebo segment přemostěte; pokud je směrovatelná, opravte cestu, firewall nebo adresu vazby.
• Při každém dalším testu zónu znovu zkontrolujte, protože zkopírovaný příkaz obvykle zachová špatné rozhraní.

Zdroje: RFC 4291, architektura adresování IPv6.