La respondo eliras per la LAN, ne per la tunelo: kial kaj kiel

Servo publikigita per pordego funkcias el la plej granda parto de la interreto kaj malsukcesas el unu oficejo. Iu kontrolas la tunelon, vidas la peton alveni kaj konkludas, ke la respondo devas sekvi la saman vojon reen. Linux ne funkcias tiel, kaj neniu kvanto da inspektado de la tunelo ŝanĝos la respondon. La respondo estas enkursigita laŭ celo, kaj tiu sola malsukcesa alvokanto sidas en subreto, kiun la gastiganto jam atingas rekte.

Kio efektive decidas elirantan pakaĵon

La kerno serĉas itineron por la celo de la pakaĵo, konsultante regulojn de politiko laŭ prioritata ordo kaj poste la tabelon, kiun elektas kongrua regulo. La interfaco, per kiu pakaĵo alvenis, ludas nenian rolon, krom se regulo aŭ marko estis skribita por igi ĝin grava. Tio estas enkursiga fakto pri ĉi tiu gastiganto, ne difekto en la tunelo.

Peto ricevita per la tunelo povas do produkti respondon, kiu eliras per la fizika interfaco, kaj la fluo fariĝas unudirekta sen ke iu ajn aparato raportu eraron. Kontrolu ambaŭ direktojn antaŭ ol konkludi ion pri la tunelo. Respondo, kiu eliras la malĝustan vojon, malaperas el la tunelaj nombriloj, kaj tial la du finoj malkonsentas pri tio, ĉu io estis sendita. Rimarku, kiu nombrilo moviĝis, antaŭ ol tuŝi regulon.

Kial la loka subreto gajnas

Gastiganto kun adreso en loka reto havas konektitan itineron por tiu prefikso en la ĉefa tabelo, kaj konektita itinero estas rekta kongruo. Kiam la alvokanto venas el tiu sama subreto, la serĉo trovas la lokan ligon antaŭ ol la tunelo eĉ estas konsiderata.

Ĝuste la malsimetrio igas tion konfuza diagnozi. Alvokantoj el la pli larĝa interreto funkcias, ĉar ili kongruas kun neniu loka itinero, dum la sola alvokanto, kiu dividas la oficejan prefikson, malsukcesas, kaj tio estas ĝuste la alvokanto, per kiu iu testas.

La kovrado de peer ne samas kiel instalitaj itineroj

Ĉe la tunela flanko, la permesitaj gamoj de peer priskribas, kio rajtas esti sendita en la tunelon kaj kiuj fontoj estas akceptataj el ĝi. Ili diras nenion pri tio, kien la loka enkursiga tabelo sendos pakaĵon.

Se la tunela ilo instalas defaŭltan itineron sur la gastiganto, ĝi povas treni nerilatan trafikon en la tunelon kiel flankan damaĝon. Kie anstataŭe regulo de politiko devus posedi la decidon, la opcio de itinera instalado ekzistas ĝuste por malhelpi tion, kaj la adresoj, ŝlosiloj kaj finpunkta agordoj restas precize kiel ili estis. Defaŭlta itinero aldonita por komforto estas ordinara maniero, per kiu gastiganto perdas sian propran lokan reton.

Elektu la tabelon laŭ la fonta adreso

Regulo bazita sur fonto sendas respondojn de la serva adreso en privatan tabelon, kies defaŭlto estas la tunelo, dum ĉio alia daŭre uzas la ĉefan tabelon. Elektu tabelajn kaj prioritatajn numerojn, kiuj ne estas uzataj loke, kaj legu la ekzistantajn regulojn antaŭ ol enmeti ion. Legu la vivajn regulojn anstataŭ konservitan dosieron, ĉar la du povas diferenci post restarto.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

La lasta linio igas mankan itineron malsukcesi videble anstataŭ reiri al la loka ligo. La fonto devas esti vere asignita al la gastiganto, kaj la ordinaraj lokalaj kaj ĉefaj serĉoj devas resti en siaj pli fruaj pozicioj. La regulo elektas tabelon laŭ fonto; ĝi ne komparas prefiksajn longojn inter tabeloj.

Konfirmu la vojon, poste la servon

Demandu la kernon, kion ĝi farus, anstataŭ dedukti el kaptaĵo, uzante la servan adreson kiel fontan selektilon. Malĝusta respondo ĉi tie ŝparas tutan pakaĵan spuron.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

La eligo devus nomi la tunelon. Poste testu fonton, kiun vi ne tuŝis, kaj konfirmu, ke ĝi ankoraŭ prenas la lokan ligon, do la ŝanĝo restis limigita al unu adreso. Pli larĝa selektilo pruvus nenion pri la origina plendo.

Kion ĉi tio ne riparas

Lasu plusendadon, fajroŝirmilajn regulojn kaj ICMPv6-konduton sur la pordego kiel ili estis, ĉar fonta itinero anstataŭas neniun el ili. Manka Packet Too Big-mesaĝo ankoraŭ rompas grandajn respondojn, kiu ajn tabelo gajnis la serĉon. Riparu tion antaŭ ol aldoni enkursigajn regulojn, alie la simptomo postvivos la ŝanĝon.

Konfirmu la publikigan modelon antaŭ ol apliki ion ajn el ĉi tio. Inversa prokuro, kiu malfermas sian propran malantaŭan konekton, prezentas sian propran fonton kaj ne konservas la alvokanton, do ĉi tiu difekto ne povas okazi en tiu dezajno. Apliki la regulon tie aldonus enkursigan escepton, kiu solvas nenion kaj kaŝas la veran kaŭzon.

Fine, skribu la regulajn numerojn kaj la tabelon en la agordan administradon de la gastiganto. Politika regulo aldonita mane malaperas ĉe la sekva rekonstruo, kaj la oficeja alvokanto revenas kun la sama plendo.