Kiam itineroj de dividita tunelo interkovriĝas: kiu prefikso venkas

Du profiloj de dividita tunelo, du privataj prefiksoj kaj unu gastiganto, kiun ambaŭ postulas. La simptomo malofte estas pura paneo: servo funkcias lunde, paneas post kiam la dua kliento rekonektiĝas, kaj funkcias denove post restarto. La ordo, laŭ kiu vi konektis la klientojn, ne decidas la rezulton, nek la ordo de la vicoj en la fasado de la kliento. Plenumu ĉi tiujn kontrolojn laŭorde kaj haltu ĉe la unua, kiu ne validas, ĉar la postaj havas sencon nur kiam la antaŭaj veras.

1. Notu la celon kaj la fonton

Komencu per la ĝusta adreso, al kiu iras la malsukcesa peto, ne per la gastiganta nomo kaj ne per la nomo de la aplikaĵo. Solvu la nomon unufoje, notu ĉiun respondon kaj elektu tiun, kiun la malsukcesa fluo efektive uzas. Poste notu la lokan adreson de la sama fluo, ĉar la fonta adreso povas ŝanĝi, kiu politika regulo kongruas kaj sekve, kiun tabelon oni konsultas.

Peto al unu el pluraj A-rikordoj povas malsukcesi dum frata adreso sukcesas, kio aspektas kiel malstabila tunelo kaj fakte estas du malsamaj vojoj. Se la celo estas nomo kun pluraj respondoj, testu ĉiun respondon aparte antaŭ ol ŝanĝi ion.

2. Demandu la kernon, kiun itineron ĝi elektis

Ne legu la itineran tabelon kaj ne deduktu la respondon. Demandu la saman demandon, kiun demandas la stako, kun la sama fonta adreso: ip route get 10.20.4.10 from 10.8.0.2 en Linux, aŭ Find-NetRoute -RemoteIPAddress 10.20.4.10 en PowerShell. La eligo nomas la itineron, kiu efektive estus uzata, kaj tio ofte ne estas tiu, kiun vi atendis legante la tabelon.

Inter kongruaj itineroj kutime venkas la pli specifa prefikso: /24 venkas /16 por adreso ene de ambaŭ. Inter kongruoj de egala longo venkas la pli malalta metriko, kaj itinero instalita sur ligilo, kiu estas malsupra, estas preterlasata. Du tuneloj, kiuj puŝas la saman /24 kun la sama metriko, estas alia kazo: la kerno konservas ambaŭ itinerojn kaj elektas inter ili, do la rezulto povas alterni anstataŭ sekvi la ordon, laŭ kiu la klientoj konektiĝis. Ĝuste tiu situacio produktas la ŝablonon lunde funkcias kaj marde malsukcesas, kaj rekonekti laŭ alia ordo ne ŝanĝas tion.

3. Kontrolu, ĉu politika regulo alidirektis la serĉon

Antaŭ ol oni konsultas la itineran tabelon, la kerno trairas siajn politikajn regulojn. Regulo povas sendi trafikon de donita fonto, uzanto aŭ fajroŝirmila marko al tute alia tabelo, do la venka prefikso en la ĉefa tabelo eble neniam estas konsultata por tiu fluo. ip rule show listigas ilin laŭ taksa ordo, kaj ip route show table 100 montras, kion la elektita tabelo efektive enhavas.

Ĉi tie kuŝas du kaptiloj. Regulo, kiu montras al malplena tabelo, produktas serĉon, kiu falas al la sekva regulo, do la regulo ŝajnas fari nenion. La alia estas la prioritata numero mem: reguloj estas legitaj laŭ kreskanta ordo, kaj la enkonstruitaj valoroj estas 0 local, 32766 main kaj 32767 default. Regulo kun numero sub 32767 estas konsultata antaŭ la implicita regulo, kiu kaptas ĉion. Regulo kun numero super 32767 staras malantaŭ ĝi kaj atingiĝas nur kiam neniu pli frua tabelo respondas, kion normala implicita itinero en main malhelpas, do praktike ĝi neniam atingiĝas kaj silente faras nenion dum ĝi aspektas instalita. Se la kliento skribis regulon kaj itineron, kontrolu ambaŭ, kaj kontrolu ilin denove post rekonekto, ĉar reskribita profilo povas aldoni duan regulon kun alia prioritato.

4. Apartigu itineran egalbatalon de duobligita adresplano

Kelkfoje la prefikso tute ne estas la problemo. Du lokoj, kiuj ambaŭ uzas 192.168.1.0/24, signifas, ke la sama adreso identigas du malsamajn gastigantojn, kaj neniu itinero povas ilin distingi. Itinero al gastiganto por unu el la du respondoj funkcias nur ĝis la alia loko respondos por la sama nomo, kaj tiam la escepto silente fariĝas la cimo.

La signo estas, ke la cela adreso identas sur ambaŭ vojoj kaj nur la celita posedanto malsamas. Tio estas decido pri adresplano, ne ĝustigo de itinado: renumeru unu flankon, metu unu flankon malantaŭ tradukan pordegon, aŭ atingi la duan lokon per prokura servilo, kiu solvas siajn proprajn nomojn. Malaltigi implicitan itineron aŭ stakigi gastigantajn esceptojn nur movas la kolizion aliloken.

5. Konfirmu, ke la solvilo konsentas kun la itinero

Nomo, kiu solviĝas al la malĝusta privata adreso, produktas ĉiun simptomon de itinada konflikto kaj neniun el ĝiaj kaŭzoj. Komparu la respondon, kiun la gastiganto ricevas, kun la adreso, kiun la celo efektive uzas, kaj kontrolu, kiu solvilo respondis. Se la tunelo puŝas solvilon, la kliento devus instali ĝin por la fluoj, kiuj uzas la tunelon; se ĝi ne faras tion, la gastiganto daŭre demandas la lokan solvilon, kiu povas respondi el serĉa domajno aŭ el kaŝmemora rikordo.

Demandu la solvilon rekte kaj notu la servilon, kiu respondis. Kaŝmemora respondo kun mallonga TTL ankaŭ povas klarigi, kial la unua peto post rekonekto kondutas alie ol la kvina.

6. Rekonektu, ekzamenu la aplikitan staton, poste testu ambaŭ fluojn

Post korekto, rekonektu kaj ekzamenu, kion la kliento efektive instal, anstataŭ fidi la profilredaktilon. Legu denove la regulojn, la tabelojn kaj la rezultan respondon ip route get. Dua kliento povas reinstali sian propran itineron ĉe konekto kaj rekrei la konflikton, tial la statkontrolo devas okazi post kiam la lasta kliento konektiĝas, ne antaŭe.

Testu du fluojn, ne unu: la peton, kiu antaŭe malsukcesis, kaj rimedon, kiu devus uzi la alian tunelon. Movi la tutan privatan trafikon al unu konekto igos la unuan teston sukcesi dum ĝi rompos la duan, kaj nur parigita testo kaptas tion. Notu ĉiun escepton, kiun vi konservas, kun la celo kaj la kialo, por ke la sekva persono povu distingi intencan gastigantan itineron de restinta.