Proč objevování sousedů IPv6 nefunguje přes routovanou VPN

IPv6 objevování sousedů patří ke spojení a routovaný tunel je hranicí mezi dvěma spojeními. Ta jedna věta vysvětluje téměř každé hlášení o vzdáleném hostiteli, který odpovídá na adresu a nelze ho najít ničím jiným. Než zkontrolujete tunel, zkontrolujte rozsah adresy, kterou testujete. Adresa platná pro spojení má smysl jen na svém vlastním spojení a multicastová skupina vyžádaného uzlu je omezena stejně. Ani jedna nepřekračuje router, a proto může ping na globální adresu uspět, zatímco objevování pro stejného hostitele nefunguje.

Rozsah přichází před konfigurací

Žádost a oznámení souseda nesou limit skoků 255 a podle návrhu se nepředávají dál. Router mezi vaším tunelem a vzdálenou LAN předává pakety IPv6 a nepřeposílá zprávy sousedů jeho jménem. Takže keš sousedů na rozhraní tunelu obsahuje protějšek a málo dalšího, což je správné chování, nikoli závada k opravě.

Adresa platná pro spojení, například záznam fe80::, je také vázána na zónu a stejný text může na jiném spojení označovat jiného hostitele. Testování takové adresy z druhé strany tunelu nedokazuje nic než to, že je adresa nejednoznačná.

Pastí je předpoklad, že prefix je na spojení

Hostitel, který věří, že prefix je na spojení, pošle žádost o souseda místo toho, aby paket předal svému routeru, a to včetně /64 směrovaného na vzdálené místo. Když takový prefix dorazí jako „na spojení“, hostitel se ptá místního spojení na hostitele, který žije jinde, a nic neodpovídá. Směrujte na vzdáleného hostitele něco menšího, nebo prefix ukončete na routeru, který za něj bude odpovídat.

/128 pro jednu službu je nejméně překvapivé uspořádání a nejednoznačnost zcela odstraňuje. Specifikace objevování sousedů popisuje sadu zpráv a příznak „na spojení“, který to rozhoduje.

Přemostění mění pravidla záměrně

Když tunel přenáší ethernetové rámce, vzdálený a místní segment se stanou jedním spojením, multicast se dostane na obě strany a objevování sousedů se chová jako na přepínači. Důsledky přicházejí s tím: záplava broadcastu a multicastu, detekce duplicitních adres přes most a oznámení routerů prosakující do segmentu, který by je neměl vidět. Doména selhání nyní zahrnuje i dvě lokality. Nic z toho není argument proti přemostění a každý bod je důvod most stavět záměrně, ne mimochodem.

Přepnutí profilu z TUN na TAP, aby se objevování objevilo, je špatné pořadí kroků. Server, klient i plán adresování musí souhlasit a mobilní klienti rozhraní TAP vůbec nenabízejí, takže takový návrh funguje na notebooku a selhává na telefonu. Proxy a relé sousedů jsou samostatné mechanismy s vlastními požadavky a patří k dokumentovanému uspořádání správce sítě, ne k nastavení aplikace.

Testujte s adresou, kterou aplikace používá

Ověřte trasu pomocí ip -6 route get, prohlédněte záznam souseda pomocí ip -6 neigh a poté ověřte službu po směrované cestě. DNS a zpětná cesta jsou samostatné kontroly a zdravý záznam souseda nedokazuje ani jednu z nich.

Pokud aplikace trvá na cíli platném pro spojení nebo na cíli založeném na objevování, je to rozhovor o návrhu, ne cvičení v ladění, protože žádné nastavení klienta nezpůsobí, aby mechanismus omezený na spojení fungoval přes router.

Zapište si, jaký návrh máte

Před incidentem zaznamenejte, zda je návrh routovaný, nebo přemostěný, protože obě nasazení odpovídají na tyto otázky různě a pohotovostní inženýr by to neměl odvozovat z profilu.

Jedno přečtení sady zpráv odstraní pokušení vysvětlit vlastnost omezenou na spojení jako chybu VPN, což je v této oblasti nejdražší chybná diagnóza.