IPv6 přes VPN: delegovaný prefix není fond adres

Ve stejný den přijdou dva požadavky: notebook potřebuje IPv6 přes tunel a malá lokalita chce IPv6 pro zařízení za svým routerem. Oba dostanou odpověď v podobě adresy a druhý pak stráví týden selháváním. Role se liší, stejně jako mechanismy, konfigurace a kontrola, která dokazuje, že to funguje. Tato příručka je drží oddělené.

Krok první: rozhodněte, které roli sloužíte

Jeden hostitel potřebuje jednu adresu na tunelovém rozhraní, s trasou na vzdálenou stranu a ničím níže, co by se mělo číslovat. Router za tunelem potřebuje celou síť, kterou může rozdávat, plus trasu na vzdálené straně, která tyto adresy vrací k němu. To, co je za tunelem, určuje každé další rozhodnutí.

Odpovězte na tuto otázku, než otevřete jakoukoli konfiguraci. Vše po tomto kroku závisí na tom, kterou odpověď jste dali.

Krok druhý: přidělení adres pro jednoho hostitele

Přidělte adresu tunelu, potvrďte délku prefixu, kterou produkt očekává, a zkontrolujte, že klient nainstaluje trasu pro vzdálený rozsah, místo aby ji posílal na místní výchozí bránu. /128 na tunelovém rozhraní je pro spojení bod-bod normální, zatímco /64 tam nárokuje síť, kterou nikdo nedelegoval. Dva výstupy otázku vyřeší: tabulka adres a tabulka tras, přečtené na obou koncích. Čtěte je společně, protože trasa ukazující na špatné rozhraní je v tomto kroku nejčastější chybou.

Ověřte pomocí tabulek adres a tras na obou koncích a potom pošlete jeden požadavek. Pokud požadavek odejde správně a nic se nevrátí, závada je v trase vzdálené strany, ne v adrese klienta.

Krok třetí: delegace pro router za tunelem

Delegace prefixu je samostatný mechanismus od přidělování adres, s vlastním požadavkem a vlastním pronájmem. Delegující strana musí být nakonfigurována tak, aby vydala prefix dostatečně velký pro síť níže, a žádající router musí očíslovat své vnitřní rozhraní z tohoto prefixu.

Nepředpokládejte, že fond, který obsluhuje mobilní klienty, umí delegovat. Mnoho produktů VPN přiděluje jednotlivé adresy a nemá vůbec žádnou roli delegace, a prefix poskytovatele, který dorazí na váš okraj, se automaticky nepředává protějšku. Zapište, které roli každý fond slouží, protože oba se konfigurují na různých místech.

Krok čtvrtý: udělejte zpětnou trasu explicitní

Oba konce se musí shodnout, který protějšek nese který prefix. Na vzdálené straně přidejte trasu pro delegovanou síť ukazující na tunel a potvrďte, že si ji žádný překrývající se rozsah už nenárokuje.

Platný prefix bez zpětné trasy dává úhledný plán adresování a žádnou konektivitu. Trasa bez přístupového pravidla vystavuje více lokality, než bylo zamýšleno, takže obě změny spojte ve stejném okně a napůl aplikovaný stav držte od uživatelů.

Krok pátý: ověřte zpoza routeru

Proveďte kontroly v pořadí: adresa tunelového rozhraní na klientovi, delegovaný prefix na vnitřním rozhraní, trasa vzdálené strany k tomuto prefixu a nakonec požadavek ze zařízení za routerem. Použijte cíl, který ovládáte, aby se tiché blokování dalo odlišit od chybějící trasy. Ať vás překvapí kterýkoli krok, právě ten je třeba opravit, než půjdete dál.

Poslední kontrolu udělejte dvakrát, jednou ze samotného routeru a jednou ze zařízení za ním. Router, který se dostane k cíli, zatímco jeho klienti ne, je problém delegace nebo předávání, ne problém výše po proudu.

Vrácení změn

Před změnou si uložte předchozí konfiguraci adresování a poznamenejte, který ze dvou mechanismů jste změnili. Odebrání delegovaného prefixu bez odebrání trasy nechává černou díru a odebrání trasy bez prefixu nechává adresy, ke kterým se nic nedostane. Poznamenejte obě změny odděleně, protože vrácení jedné při ponechání druhé činí lokalitu nedostupnou jen v jednom směru.

Pokud se ukáže, že produkt nepodporuje roli, kterou potřebujete, zastavte se a změňte návrh, místo abyste roztahovali pole klienta, aby pojalo rozsah, pro který nikdy nebylo určeno. Případ podpory zodpovězený špatným mechanismem stojí víc než změna návrhu.