Prečo objavovanie susedov IPv6 zlyháva cez smerovanú VPN

Objavovanie susedov IPv6 patrí k jednému spojeniu a smerovaný tunel je hranicou medzi dvoma spojeniami. Tá jedna veta vysvetľuje takmer každé hlásenie o vzdialenom hostiteľovi, ktorý odpovedá na adresu a nedá sa nájsť nijakým iným spôsobom. Pred kontrolou tunela skontrolujte rozsah adresy, ktorú testujete. Adresa platná pre spojenie má zmysel len na svojom vlastnom spojení a multicastová skupina žiadaného uzla je obmedzená rovnako. Ani jedna neprechádza smerovačom, a preto môže ping na globálnu adresu uspieť, kým objavovanie pre toho istého hostiteľa nie.

Rozsah prichádza pred konfiguráciou

Žiadosť a oznámenie suseda nesú limit skokov 255 a podľa návrhu sa nepreposielajú. Smerovač medzi vaším tunelom a vzdialenou LAN preposiela pakety IPv6 a nepreposiela správy susedov v jeho mene. Takže vyrovnávacia pamäť susedov na rozhraní tunela obsahuje partnera a málo iného, čo je správne správanie, nie chyba na opravu.

Adresa platná pre spojenie, napríklad záznam fe80::, je tiež viazaná na zónu a ten istý text môže na inom spojení označovať iného hostiteľa. Testovanie takej adresy z druhej strany tunela nedokazuje nič okrem toho, že adresa je nejednoznačná.

Pascou je predpoklad, že prefix je na spojení

Hostiteľ, ktorý verí, že prefix je na spojení, pošle žiadosť suseda namiesto toho, aby paket odovzdal svojmu smerovaču, a to vrátane /64 smerovaného na vzdialené miesto. Keď taký prefix príde ako na spojení, hostiteľ sa pýta miestneho spojenia na hostiteľa, ktorý žije inde, a nič neodpovedá. Smerujte na vzdialeného hostiteľa niečo menšie alebo ukončite prefix na smerovači, ktorý zaň bude odpovedať.

/128 pre jednu službu je najmenej prekvapivé usporiadanie a nejednoznačnosť úplne odstraňuje. Špecifikácia objavovania susedov opisuje súbor správ a príznak „na spojení“, ktorý to rozhoduje.

Premostenie mení pravidlá zámerne

Keď tunel prenáša ethernetové rámce, vzdialený a miestny segment sa stanú jedným spojením, multicast sa dostane na obe strany a objavovanie susedov sa správa ako na prepínači. Dôsledky prichádzajú s tým: záplava broadcastu a multicastu, detekcia duplicitných adries cez most a oznámenia smerovača presakujúce do segmentu, ktorý by ich nemal vidieť. Doména zlyhania teraz zahŕňa aj dve lokality. Nič z toho nie je argument proti premosteniu a každý bod je dôvod most stavať zámerne, nie mimochodom.

Prepnutie profilu z TUN na TAP, aby sa objavovanie objavilo, je nesprávne poradie krokov. Server, klient aj plán adresovania musia súhlasiť a mobilní klienti rozhranie TAP vôbec neponúkajú, takže taký návrh funguje na notebooku a zlyháva na telefóne. Proxy a relé susedov sú samostatné mechanizmy s vlastnými požiadavkami a patria k dokumentovanému usporiadaniu správcu siete, nie k nastaveniam aplikácie.

Testujte s adresou, ktorú aplikácia používa

Overte trasu pomocou ip -6 route get, prezrite záznam suseda pomocou ip -6 neigh a potom overte službu po smerovanej ceste. DNS a spiatočná cesta sú samostatné kontroly a zdravý záznam suseda nedokazuje ani jednu z nich.

Ak aplikácia trvá na cieli platnom pre spojenie alebo na cieli založenom na objavovaní, je to rozhovor o návrhu, nie cvičenie v ladení, pretože žiadne nastavenie klienta nespôsobí, aby mechanizmus obmedzený na spojenie fungoval cez smerovač.

Zapíšte si, aký návrh máte

Pred incidentom zaznamenajte, či je návrh smerovaný alebo premostený, pretože obe nasadenia odpovedajú na tieto otázky rôzne a pohotovostný inžinier by to nemal odvodzovať z profilu.

Jedno prečítanie súboru správ odstráni pokušenie vysvetliť vlastnosť obmedzenú na spojenie ako chybu VPN, čo je v tejto oblasti najdrahšia chybná diagnóza.