Který zdroj IPv6 si požadavek VPN vybere a proč na tom záleží

Přidali jste adresu VPN a čekali, že ji požadavek použije, ale server stále logoval starý prefix. Nic v tunelu neselhalo; hostitel zvolil zdrojovou adresu dřív, než se vůbec podíval na trasu, na kterou jste zírali. Výběr zdroje IPv6 je samostatná uspořádaná soutěž mezi kandidátskými adresami hostitele a nejdelší shodný prefix je jen jedno pravidlo blízko jejího konce. Chcete-li dostat výsledek, který chcete, musíte vědět, které pravidlo už vyhrálo. Pravidla samotná jsou nudná a přesná, a právě proto se mají číst popořadě.

Dvě hledání, ne jedno

Volba cíle vybírá další skok a výstupní rozhraní. Pak volba zdroje vybírá, která z adres hostitele se objeví v hlavičce, a na obě otázky odpovídají různé mechanismy, i když obě používají prefixy. Hostitel s fyzickou adresou, dočasnou adresou a adresou VPN má pro daný cíl tři kandidáty a trasa k VPN třetí automaticky nenavrhuje.

Proto spolu správná trasa a nesprávný zdroj tak snadno koexistují a proto se stejný požadavek může chovat jinak z prohlížeče a z vynucené vazby. Berte obě hledání jako oddělená, dokud nenajdete důkaz, který je spojuje.

Čtěte pravidla jako uspořádanou soutěž

RFC 6724 uvádí pravidla v pořadí a každé jen rozbíjí remízu, kterou nechala předchozí. Preference výstupního rozhraní a shoda štítků přicházejí dlouho před porovnáním prefixů, takže adresa na rozhraní, které trasa používá, už získala výhodu, kterou lepší shoda prefixu nesmaže. Uplatňuje se i zastaralost a rozsah, a proto se zastaralá adresa někdy přestane vybírat, aniž by kdokoli změnil politiku.

Praktické čtení je, že o vítězi nelze uvažovat jen z cíle. Vypište kandidáty, projděte pravidla popořadě a podívejte se, kde se rozhodnutí skutečně udělalo.

Všimněte si také, že tohle je zdrojová polovina problému. Slévání obou porovnání prefixů dává vysvětlení, která znějí přísně a předpovídají špatnou adresu. Kdykoli v tiketu použijete slovo prefix, řekněte, které porovnání máte na mysli.

Vazba aplikace mění otázku

Aplikace může požádat o konkrétní zdrojovou adresu a platná výslovná volba přesouvá otázku z “kterou adresu by hostitel preferoval” na “dokáže se tato adresa dostat k cíli a vrátit se”. Nástroje, které se vážou ke zdroji nebo si vyžádají doplňková data o zvolené adrese, to ukazují přímo a jsou nejrychlejší cestou, jak dokázat, kterou adresu spojení skutečně použilo. Ten experiment je lepší než třetí čtení směrovací tabulky, protože hlásí, co rozhodlo jádro, a ne co jste nastavili. Po změně ho zopakujte a obě odpovědi porovnejte.

Tím se vazba zdroje stává diagnostickým nástrojem i náhradním řešením: připoutejte adresu VPN a sledujte, zda požadavek uspěje. Pokud ano, cesta je v pořádku a problémem byla volba. Pokud ne, problémem byla od začátku zpáteční cesta nebo politika na vzdáleném konci.

Ověřte, že vzdálená strana ten zdroj přijímá

Ať hostitel zvolí cokoli, musí to sedět do chráněného rozsahu VPN a do zpáteční trasy a přístupových pravidel vzdáleného konce. Zdroj mimo selektory může putovat do tunelu a být na vzdáleném konci zahozen, což vypadá jako jednosměrná porucha a svádí se na směrování. Porovnejte zvolený vnitřní zdroj s rozsahem ochrany, než se dotknete nastavení šifrování, protože změna režimu nevybírá mezi kandidátskými adresami.

Adresu vnějšího koncového bodu držte ve svých úvahách také stranou. Určuje transport mezi účastníky VPN a není zdrojem paketu aplikace uvnitř.

Rozhodujte podle čtyř pozorování

Zapište použitý cíl, způsobilé místní zdroje, skutečně zvolený zdroj a efektivní výstupní cestu. Čtyři řádky stačí k vysvětlení téměř každého případu a lze je porovnat mezi funkčním a nefunkčním hostitelem, aniž by se znovu rozebírala teorie. Pro krok volby použijte vlastní podporovaný pohled operačního systému, ne název z normy, protože implementace přidávají vlastní místní preference.

Když vás odpověď pořád překvapuje, uspořádání dělá něco, co váš mentální model nedělá, a náprava je změnit vstupy, ne hádat se s algoritmem. Napište čtyři pozorování do tiketu a další čtenář bude moci zopakovat váš závěr.