Trafiko IPv6 preter la VPN: trovi la likan itineron

Du testaj paĝoj malkonsentas: unu raportas la adreson de la provizanto tra la tunelo, la dua raportas vian hejman prefikson, kaj la evidenta konkludo estas, ke la VPNo likas. Tiu konkludo saltas paŝon, ĉar la du raportoj ekzercis du malsamajn itinarajn decidojn kaj nur unu el ili devis eniri la tunelon. La manko kutime estas reala, kaj ĝi estas kovroproblemo, ne rompita tunelo. Tri demandoj klarigas ĝin: kiu fluo efektive eliris, kiun itineron la kerno elektis por ĝi, kaj kiun konduton la kliento celis.

Laboru laŭ tiu ordo. Respondi ilin malorde produktas longan diskuton pri tio, ĉu la kliento estas difekta, kiam la vera respondo estas, ke neniu iam ajn instalis IPv6-itineron.

Kiu fluo efektive eliris, kaj sur kiu adaptilo

Komencu per testo, kiu nomas la familion uzitan, poste notu la aplikaĵon, la alirretan, la validan profilon kaj ĉu la konekto entute proponas IPv6. Tiuj kvar faktoj igas du ruladojn kompareblaj, kaj la kvara estas tiu, kiun homoj forgesas: reto sen v6-prefikso ne povas liki v6, kaj reto, kiu aldonas unu poste, ŝanĝas la respondon.

Sendu unu peton por familio anstataŭ ŝargi paĝon kaj legi ĝian rezulton. Unuopa paĝo povas miksi v6- kaj v4-rimedojn, fona procezo povas konduti alie ol la langeto antaŭ vi, kaj kaŝmemora respondo povas postvivi la retan ŝanĝon, kiun vi provas testi. Fiksu la celon, kiun vi testas, kaj notu ĝin, por ke ripeta rulado mezuru la saman aferon.

Legi la itineron, kiun la kerno elektis

La itinara tabelo respondas la demandon, kiun la retumilo ne povas. Demandu la sistemon, kien irus difinita celo, kaj inkluzivu kaj politikajn regulojn kaj la videblan defaŭlton, ĉar ĉiu el ili povas superregi ĝin:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Pli specifa prefikso estas la kutima kialo, ke unu celo restas ekster la tunelo dum ĉio alia restas interne, kaj politika regulo povas fari la samon kun pli alta prioritato ol iu ajn itinero. Legu ankaŭ la metrikon, ĉar du enskriboj por la sama prefikso decidiĝas laŭ metriko kaj ne laŭ ilia ordo sur la ekrano. En Windows la ekvivalenta listo estas Get-NetRoute -AddressFamily IPv6, ordigita laŭ metriko por kongrui kun la decida ordo. Regulo, kiu aspektas ĝusta en la tabelo, ankoraŭ povas perdi al politika regulo kun pli malalta numero, kaj tial la regula listo apartenas al la sama spiro kiel la itinara listo.

De kie venas la politiko IPv6 de la kliento

Kliento povas esti konstruita por porti v6 tra la tunelo, por rifuzi ĝin, aŭ por permesi nomitan escepton, kaj tiuj tri intencoj donas tri malsamajn ĝustajn rezultojn. Legu la profilon kaj la dokumentaron de la kliento mem antaŭ ol nomi observon liko, ĉar kliento, kiu blokas v6 dum la operaciumo ankoraŭ sendas najbaran malkovron sur la fizika ligo, kondutas laŭ la dezajno.

Aplikaĵo intence ekskludita el la tunelo estas alia kazo ol familio, kiun la tunelo neniam portis. La unua estas decido pri unu programo, la dua estas manko en kovro, kaj la riparo diferencas laŭe. Legu la liston de ekskluditaj programoj de la kliento antaŭ ol ĉasi itineron, kiu neniam devis ekzisti.

Mallarĝa observado, kiam la tabelo malkonsentas

Kiam la itinara serĉo estas ambigua, unu interfaca observado sur la gastiganto povas klarigi ĝin, sed nur se ĝi celas la demandon. Trafiko al la VPNa finpunkto mem transiros la fizikan adaptilon laŭ la dezajno; tio, kio gravas, estas ĉu la aplikaĵa fluo, adresita tute aliloke, ankaŭ aperas tie. Filtru la kaptaĵon al la celo, kiun vi testas, anstataŭ kolekti ĉion.

Vasta kaptaĵo elmetas multe pli da persona trafiko ol la unu demando bezonas. Ĝi ankaŭ respondas la demandon malpli klare, ĉar la fluo, pri kiu vi zorgas, alvenas enterigita en fluo de nerilataj konektoj. Filtru al la testita celo, haltu post manpleno da pakaĵoj, kaj forigu la kaptaĵon.

Tri manieroj fermi la mankon

Portu la familion tra la tunelo, bloku ĝin en la kliento kiam la tunelo ne povas porti ĝin, aŭ registru intencan escepton kun posedanto kaj revizia dato. Ĉiu estas defendebla, kaj la sola nedefendebla afero estas lasi la elekton implicita, ĉar implicita elekto estas ĝuste tio, kio la liko efektive estas. Se la tunelo tute ne havas v6-eliron, rifuzi v6 en la kliento estas kaj honesta kaj testebla. Tio, kio gravas, estas ke la elekto estu skribita tie, kie la sekva persono trovos ĝin, ne konjektita el konduto ses monatojn poste.

Ripetu la kontrolon post rekonekto kaj post moviĝo inter retoj, ĉar itinero instalita por la antaŭa ligo povas postvivi la ŝanĝon. Poste notu la celon, la elektitan itineron, la klientan politikon kaj la familion, kiun la testo uzis, por ke la sekva persono legu decidon anstataŭ rederivi ĝin. RFC 7359 dokumentas dulikstan likadon kiel dezajnoproblemon anstataŭ cimon, kaj ĝi estas la referenco citenda kiam iu asertas, ke funkcianta v4-tunelo kovras ĉion.