Kial IPv6-najbara malkovro malsukcesas trans enkursigita VPN

IPv6-najbara malkovro apartenas al ligo, kaj enkursigita tunelo estas limo inter du ligoj. Tiu unu frazo klarigas preskaŭ ĉiun raporton pri fora gastiganto, kiu respondas per adreso kaj ne troveblas per io ajn alia. Kontrolu la amplekson de la adreso, kiun vi testas, antaŭ ol kontroli la tunelon. Adreso loka al la ligo havas sencon nur sur sia propra ligo, kaj multdissenda grupo de la petita nodo estas same limigita. Neniuj el ili trapasas enkursigilon, kaj tial ping al tutmonda adreso povas sukcesi, dum malkovro por la sama gastiganto ne.

Amplekso venas antaŭ agordo

Najbara peto kaj anonco portas saltolimon 255 kaj ne estas plusendataj, laŭ la dezajno. La enkursigilo inter via tunelo kaj la fora LAN plusendas IPv6-paketojn kaj ne plusendigas najbarajn mesaĝojn nome de ĝi. Do la najbara kaŝmemoro sur la tunela interfaco enhavas la partneron kaj malmulte alion, kio estas ĝusta konduto, ne difekto por ripari.

Adreso loka al la ligo, kiel enskribo fe80::, ankaŭ estas zonampleksa, kaj la sama teksto povas nomi alian gastiganton sur alia ligo. Testi unu el la alia flanko de la tunelo pruvas nenion krom ke la adreso estas dusenca.

La kaptilo estas la supozo, ke la prefikso estas sur la ligo

Gastiganto, kiu kredas, ke prefikso estas sur la ligo, sendas najbaran peton anstataŭ doni la paketon al sia enkursigilo, kaj tio inkluzivas /64 enkursigitan al fora loko. Kiam tia prefikso alvenas kiel sur-la-ligo, la gastiganto demandas la lokan ligon pri gastiganto, kiu loĝas aliloke, kaj nenio respondas. Enkursigu ion pli malgrandan al la fora gastiganto, aŭ finu la prefikson ĉe la enkursigilo, kiu respondos por ĝi.

/128 por unu servo estas la plej malmulte surpriza aranĝo, kaj ĝi tute forigas la dusencecon. La specifikaĵo pri najbara malkovro priskribas la mesaĝaron kaj la flagon sur-la-ligo, kiu decidas tion.

Ponto ŝanĝas la regulojn intence

Kiam la tunelo transportas Ethernet-kadrojn, la fora kaj loka segmentoj fariĝas unu ligo, multdissendo atingas ambaŭ flankojn, kaj najbara malkovro kondutas kiel sur ŝaltilo. La sekvoj venas kun ĝi: inundo de diselsendo kaj multdissendo, detekto de duoblaj adresoj trans la ponto, kaj enkursigilaj anoncoj likantaj en segmenton, kiu ne devus vidi ilin. La fiaskodomajno nun etendiĝas ankaŭ trans du lokoj. Nenio el tio argumentas kontraŭ ponto, kaj ĉiu punkto estas kialo ponti intence, ne hazarde.

Ŝanĝi profilon de TUN al TAP por aperigi malkovron estas la malĝusta ordo de operacioj. La servilo, kliento kaj adresplano devas konsenti, kaj porteblaj klientoj tute ne ofertas TAP-interfacon, do tia dezajno funkcias sur tekokomputilo kaj malsukcesas sur telefono. Najbaraj prokuraj servoj kaj ripetiloj estas apartaj mekanismoj kun propraj postuloj, kaj ili apartenas al la dokumentita aranĝo de la retadministranto, ne al la agordoj de aplikaĵo.

Testu per la adreso, kiun uzas la aplikaĵo

Konfirmu la itineron per ip -6 route get, inspektu la najbaran enskribon per ip -6 neigh, poste konfirmu la servon laŭ la enkursigita vojo. DNS kaj la revena vojo estas apartaj kontroloj, kaj sana najbara enskribo pruvas neniun el ili.

Se la aplikaĵo insistas pri celloko loka al la ligo aŭ bazita sur malkovro, tio estas dizajna interparolo, ne agorda ekzerco, ĉar neniu klienta agordo igas mekanismon limigitan al la ligo funkcii trans enkursigilo.

Notu, kiun dezajnon vi havas

Registru, ĉu enkursigita aŭ pontita, antaŭ la okazaĵo, ĉar la du deplojoj respondas ĉi tiujn demandojn malsame kaj deĵora inĝeniero ne devus dedukti tion el profilo.

Unufoja legado de la mesaĝaro forigas la tenton klarigi econ de ligamplekso kiel VPN-eraron, kio estas la plej kosta misdiagnozo en ĉi tiu kampo.