Kai skaidyto tunelio maršrutai persidengia: kuris prefiksas laimi

Du skaidyto tunelio profiliai, du privatūs prefiksai ir vienas mazgas, į kurį abu pretenduoja. Simptomas retai būna švarus gedimas: paslauga veikia pirmadienį, po antrojo kliento prisijungimo baigiasi laukimo laikas, o po perkrovimo vėl veikia. Tvarka, kuria sujungėte klientus, rezultato nenulemia, kaip ir eilučių tvarka kliento sąsajoje. Atlikite šiuos patikrinimus iš eilės ir sustokite ties pirmuoju, kuris netinka, nes vėlesni turi prasmę tik tada, kai ankstesni yra teisingi.

1. Užsirašykite tikslą ir šaltinį

Pradėkite nuo tikslaus adreso, į kurį eina nepavykusi užklausa, o ne nuo mazgo vardo ir ne nuo programos pavadinimo. Išspręskite vardą vieną kartą, užsirašykite kiekvieną atsakymą ir pasirinkite tą, kurį nepavykęs srautas iš tikrųjų naudoja. Tada užsirašykite to paties srauto vietinį adresą, nes šaltinio adresas gali pakeisti, kuri politikos taisyklė atitinka, taigi ir kuri lentelė tikrinama.

Užklausa į vieną iš kelių A įrašų gali nepavykti, kol gretimas adresas pavyksta, ir tai atrodo kaip nepastovus tunelis, o iš tikrųjų yra du skirtingi keliai. Jei tikslas yra vardas su keliais atsakymais, prieš ką nors keisdami atskirai išbandykite kiekvieną atsakymą.

2. Paklauskite branduolio, kurį maršrutą jis pasirinko

Neskaitome maršrutų lentelės ir nedarykite išvados. Užduokite tą patį klausimą, kurį užduoda kamina, su tuo pačiu šaltinio adresu: ip route get 10.20.4.10 from 10.8.0.2 Linux sistemoje arba Find-NetRoute -RemoteIPAddress 10.20.4.10 PowerShell aplinkoje. Išvestis nurodo maršrutą, kuris būtų tikrai naudojamas, ir jis dažnai nėra tas, kurio tikėjotės skaitydami lentelę.

Tarp atitinkančių maršrutų paprastai laimi konkretesnis prefiksas: /24 nugali /16 adresui, kuris yra abiejuose. Tarp vienodo ilgio atitikčių laimi mažesnė metrika, o maršrutas, įdiegtas išjungtoje jungtyje, praleidžiamas. Du tuneliai, skelbiantys tą patį /24 su ta pačia metrika, yra kitas atvejis: branduolys laiko abu maršrutus ir renkasi tarp jų, todėl rezultatas gali kaitaliotis, o ne sekti klientų prisijungimo tvarką. Būtent ši situacija sukuria modelį pirmadienį-veikia-antradienį-nepavyksta, ir prisijungimas kita tvarka to nepakeičia.

3. Patikrinkite, ar politikos taisyklė nukreipė paiešką

Prieš tikrinant maršrutų lentelę, branduolys pereina savo politikos taisykles. Taisyklė gali siųsti srautą iš nurodyto šaltinio, naudotojo ar ugniasienės žymos į visiškai kitą lentelę, todėl pagrindinės lentelės laimintis prefiksas tam srautui gali būti niekada netikrinamas. ip rule show jas išvardija vertinimo tvarka, o ip route show table 100 parodo, ką pasirinkta lentelė iš tikrųjų turi.

Čia tyko dvi spąstai. Taisyklė, nukreipta į tuščią lentelę, sukuria paiešką, kuri persimeta į kitą taisyklę, todėl atrodo, kad taisyklė nieko nedaro. Kita yra pats prioriteto numeris: taisyklės skaitomos didėjančia tvarka, o įtaisytosios reikšmės yra 0 local, 32766 main ir 32767 default. Taisyklė, kurios numeris mažesnis už 32767, tikrinama prieš viską pagaunančią numatytąją taisyklę. Taisyklė, kurios numeris didesnis už 32767, stovi už jos ir pasiekiama tik tada, kai jokia ankstesnė lentelė neatsako, ką užkerta įprastas numatytasis maršrutas main lentelėje, todėl praktiškai ji niekada nepasiekiama ir tyliai nieko nedaro, nors atrodo įdiegta. Jei klientas įrašė taisyklę ir maršrutą, patikrinkite abu ir patikrinkite juos dar kartą po prisijungimo iš naujo, nes perrašytas profilis gali pridėti antrą taisyklę su kitu prioritetu.

4. Atskirkite maršrutų lygybę nuo dvigubinamo adresų plano

Kartais prefiksas visai ne problema. Dvi vietovės, kurios abi naudoja 192.168.1.0/24, reiškia, kad tas pats adresas žymi du skirtingus mazgus, ir joks maršrutas negali jų atskirti. Mazgo maršrutas į vieną iš dviejų atsakymų veikia tik tol, kol kita vietovė atsako už tą patį vardą, ir tada išimtis tyliai tampa pačiu gedimu.

Požymis yra tas, kad tikslo adresas abiejuose keliuose yra identiškas ir skiriasi tik numatytas savininkas. Tai adresų plano sprendimas, o ne maršrutizavimo koregavimas: pernumeruokite vieną pusę, padėkite vieną pusę už verčiančio tinklų sietuvo arba pasiekite antrą vietovę per tarpinį serverį, kuris pats išsprendžia savo vardus. Numatomojo maršruto sumažinimas ar mazgų išimčių krūva tik perkelia susidūrimą kitur.

5. Patvirtinkite, kad sprendėjas sutinka su maršrutu

Vardas, išsprendžiamas į neteisingą privatų adresą, sukuria visus maršrutizavimo konflikto simptomus ir nė vienos jo priežasties. Palyginkite atsakymą, kurį gauna mazgas, su adresu, kurį tikslas iš tikrųjų naudoja, ir patikrinkite, kuris sprendėjas atsakė. Jei tunelis stumia sprendėją, klientas turėtų jį įdiegti srautams, kurie naudoja tunelį; jei ne, mazgas toliau klausia vietinio sprendėjo, kuris gali atsakyti iš paieškos domeno ar podėlyje saugomo įrašo.

Klauskite sprendėjo tiesiogiai ir užsirašykite serverį, kuris atsakė. Podėlyje saugomas atsakymas su trumpu TTL taip pat gali paaiškinti, kodėl pirmoji užklausa po prisijungimo iš naujo elgiasi kitaip nei penktoji.

6. Prisijunkite iš naujo, apžiūrėkite taikomą būseną, tada išbandykite abu srautus

Po pataisymo prisijunkite iš naujo ir apžiūrėkite, ką klientas iš tikrųjų įdiegė, o ne pasitikėkite profilio redaktoriumi. Dar kartą perskaitykite taisykles, lenteles ir gautą ip route get atsakymą. Antras klientas gali prisijungdamas iš naujo įdiegti savo maršrutą ir vėl sukurti konfliktą, todėl būsenos patikra turi įvykti po paskutinio kliento prisijungimo, o ne prieš jį.

Išbandykite du srautus, o ne vieną: užklausą, kuri anksčiau nepavykdavo, ir išteklių, kuris turėtų naudoti kitą tunelį. Perkėlus visą privatų srautą į vieną jungtį, pirmasis testas praeis, bet antrasis suges, ir tai pagauna tik suporuotas testas. Užsirašykite kiekvieną paliktą išimtį su tikslu ir priežastimi, kad kitas žmogus galėtų atskirti tyčinį mazgo maršrutą nuo likusio.