Ko se poti razdeljenega tunela prekrivajo: kateri prefiks zmaga

Dva profila razdeljenega tunela, dva zasebna prefiksa in en gostitelj, na katerega oba polagata pravico. Simptom je redko čista okvara: storitev deluje v ponedeljek, po ponovni povezavi drugega odjemalca poteče čas in po ponovnem zagonu spet deluje. Vrstni red, v katerem ste povezali odjemalce, ne odloča o izidu, prav tako ne vrstni red vrstic v vmesniku odjemalca. Izvedite te preglede po vrsti in se ustavite pri prvem, ki ne velja, ker imajo naslednji smisel le, ko so prejšnji resnični.

1. Zapišite cilj in vir

Začnite s točnim naslovom, kamor gre neuspešna zahteva, ne z imenom gostitelja in ne z imenom aplikacije. Razrešite ime enkrat, zabeležite vsak odgovor in izberite tistega, ki ga neuspešni tok dejansko uporablja. Nato zabeležite lokalni naslov istega toka, ker lahko izvorni naslov spremeni, katero pravilo politike se ujema in s tem, katera tabela se pregleda.

Zahteva na enega od več zapisov A lahko ne uspe, medtem ko sosednji naslov uspe, kar je videti kot nestabilen tunel, v resnici pa sta to dve različni poti. Če je cilj ime z več odgovori, preizkusite vsak odgovor posebej, preden karkoli spremenite.

2. Vprašajte jedro, katero pot je izbralo

Ne berite tabele poti in ne sklepajte odgovora iz nje. Postavite isto vprašanje, ki ga postavlja sklad, z istim izvornim naslovom: ip route get 10.20.4.10 from 10.8.0.2 v Linuxu ali Find-NetRoute -RemoteIPAddress 10.20.4.10 v PowerShellu. Izpis navede pot, ki bi bila v resnici uporabljena, in to pogosto ni tista, ki ste jo pričakovali ob branju tabele.

Med ujemajočimi potmi običajno zmaga bolj natančen prefiks: /24 premaga /16 za naslov, ki leži v obeh. Med ujemanji enake dolžine zmaga nižja metrika, pot, nameščena na izklopljeni povezavi, pa se preskoči. Dva tunela, ki oglašujeta isti /24 z isto metriko, so drug primer: jedro obdrži obe poti in izbira med njima, zato se lahko izid izmenjuje, namesto da bi sledil vrstnemu redu povezovanja odjemalcev. Prav ta položaj ustvari vzorec v ponedeljek deluje in v torek ne, in ponovna povezava v drugem vrstnem redu tega ne spremeni.

3. Preverite, ali je pravilo politike preusmerilo iskanje

Preden se pregleda tabela poti, jedro prehodi svoja pravila politike. Pravilo lahko pošlje promet iz danega vira, uporabnika ali oznake požarnega zidu v povsem drugo tabelo, zato se zmagovalni prefiks v glavni tabeli za ta tok morda nikoli ne pregleda. ip rule show jih našteje v vrstnem redu ocenjevanja, ip route show table 100 pa pokaže, kaj izbrana tabela v resnici vsebuje.

Tu prežita dve past. Pravilo, ki kaže na prazno tabelo, ustvari iskanje, ki pade na naslednje pravilo, zato se zdi, da pravilo ne naredi ničesar. Druga je sama številka prioritete: pravila se berejo naraščajoče, vgrajene vrednosti pa so 0 local, 32766 main in 32767 default. Pravilo s številko pod 32767 se pregleda pred privzetim pravilom, ki ujame vse. Pravilo s številko nad 32767 stoji za njim in se doseže le, kadar nobena prejšnja tabela ne odgovori, kar prepreči običajna privzeta pot v main, zato se v praksi nikoli ne doseže in tiho ne naredi ničesar, medtem ko je videti nameščeno. Če je odjemalec zapisal pravilo in pot, preverite oboje in ju preverite znova po ponovni povezavi, ker lahko prepisan profil doda drugo pravilo z drugačno prioriteto.

4. Ločite izenačenje poti od podvojenega načrta naslovov

Včasih prefiks sploh ni težava. Dve lokaciji, ki obe uporabljata 192.168.1.0/24, pomenita, da isti naslov označuje dva različna gostitelja in nobena pot ju ne more razlikovati. Pot do gostitelja na enega od dveh odgovorov deluje le dotlej, dokler druga lokacija ne odgovori za isto ime, in takrat izjema tiho postane sama napaka.

Namig je, da je ciljni naslov na obeh poteh enak in se razlikuje le predvideni lastnik. To je odločitev o načrtu naslovov, ne prilagoditev usmerjanja: preštevilčite eno stran, postavite eno stran za prehod, ki prevaja, ali dosezite drugo lokacijo prek posrednika, ki sam razrešuje svoja imena. Znižanje privzete poti ali kopičenje izjem za gostitelje samo premakne trčenje.

5. Potrdite, da se razreševalnik strinja s potjo

Ime, ki se razreši na napačen zasebni naslov, ustvari vse simptome konflikta usmerjanja in nobenega od njegovih vzrokov. Primerjajte odgovor, ki ga prejme gostitelj, z naslovom, ki ga cilj dejansko uporablja, in preverite, kateri razreševalnik je odgovoril. Če tunel potiska razreševalnik, bi ga moral odjemalec namestiti za tokove, ki uporabljajo tunel; če ne, gostitelj še naprej sprašuje lokalni razreševalnik, ki lahko odgovori iz iskalne domene ali iz predpomnjenega zapisa.

Vprašajte razreševalnik neposredno in zabeležite strežnik, ki je odgovoril. Predpomnjen odgovor s kratkim TTL lahko tudi pojasni, zakaj se prva zahteva po ponovni povezavi obnaša drugače kot peta.

6. Znova se povežite, pregledajte uporabljeno stanje in nato preizkusite oba toka

Po popravku se znova povežite in pregledajte, kaj je odjemalec v resnici namestil, namesto da bi zaupali urejevalniku profilov. Znova preberite pravila, tabele in dobljeni odgovor ip route get. Drugi odjemalec lahko ob povezavi znova namesti svojo pot in znova ustvari konflikt, zato mora pregled stanja slediti povezavi zadnjega odjemalca in ne priti pred njo.

Preizkusite dva toka, ne enega: zahtevo, ki je prej neuspešno končala, in vir, ki bi moral uporabljati drugi tunel. Premik vsega zasebnega prometa na eno povezavo bo pustil prvi preskus uspešen, a bo pokvaril drugega, in to ujame le seznanjen preskus. Zabeležite vsako izjemo, ki jo obdržite, s ciljem in razlogom, da bo naslednja oseba lahko ločila namerno pot do gostitelja od preostale.