Turite dvi išorines linijas, ir ip -6 route show rodo tą patį kitą šuolį abiejose: default via fe80::1 dev uplink0 ir default via fe80::1 dev uplink1. Tai nėra adresų dubliavimosi konfliktas, o gryno kito šuolio fe80::1 įtraukimas į strateginę lentelę nepasako branduoliui, kurią liniją turite omenyje. Tikrasis klausimas siauresnis, nei leidžia manyti simptomas: ar antrajai lentelei reikia vienos linijos, ar abiejų, ir kas išlaiko tuos maršrutus gyvus po perkrovimo. Trys sąlygos, tikrinamos iš eilės, išsprendžia didžiąją dalį atvejų.

Tas pats fe80::1 yra du skirtingi kaimynai

Nuorodos vietiniai adresai galioja tik vienoje linijoje, todėl fe80::1 nėra vienas adresas, atspausdintas du kartus; tai du kaimynai, kurie tik sutampa pagal galūnę. Zonos indeksas yra būdas, kuriuo hostas pasako, kurį turi omenyje, todėl fe80::1%uplink0 ir fe80::1%uplink1 branduoliui yra skirtingi tikslai, o ta galūnė niekada nenukeliauja į nuotolinį maršrutizatorių. RFC 4007 aprašo už to slypintį zonos modelį, ir būtent todėl strateginė lentelė prie kiekvieno nuorodos vietinio kito šuolio turi turėti įrenginį.

VPN konfigūracijos generatorius, kuris nukopijuoja skaitinį zonos ID iš vieno hosto į šabloną, elgiasi su vietiniu kontekstu taip, tarsi jis būtų adreso dalis, o jo surašytas failas yra neteisingas kiekviename kompiuteryje, kurio sąsajų pavadinimai ar indeksai skiriasi. Strateginė lentelė taip pat nesujungia dviejų linijų į vieną: maršrutuojamas VPN perduoda paketus tarp tinklų, bet neperneša nuotolinio eterneto kaimyno nuorodos vietinės tapatybės per tunelį, todėl nuorodos vietinis srautas lieka savo linijoje.

Pašalinkite įrenginį, ir maršrutas taps neįrašomas. ip -6 route add default via fe80::1 table 200 negali išspręsti šliuzo, o iproute2 jį atmeta su Error: Nexthop has invalid gateway. klaida. Pridėkite dev uplink0 ir komanda pavyks, nes būtent įrenginys pririša kitą šuolį prie vieno iš tų dviejų kaimynų. Ko įrenginys negali pasakyti, tai ar uplink0 yra tinkama šios lentelės linija, o maršrutas, nukopijuotas iš kito hosto, atsineša to hosto sąsajų pavadinimus, ir iš čia kyla tikrosios klaidos.

Pirma sąlyga: viena linija ar dvi lentelėje

Pradėkite nuo to, kam skirta antroji išorinė linija. Jei abi linijos neša tą patį srautą ir viena yra atsarginė, atsarginėje lentelėje turėtų būti abu šliuzai su skirtingais metrikais: tie patys tikslai, vienas pageidaujamas kelias, vienas akivaizdus antrasis pasirinkimas. Jei išorinės linijos egzistuoja todėl, kad skirtingas srautas turi išeiti per skirtingus tiekėjus, arba todėl, kad tai yra skaidantis tunelis, kuriame dalis srauto apeina VPN, o likusi dalis lieka viduje, tos dvi linijos visai neturi būti vienoje lentelėje. Jos priklauso dviem lentelėms, kurias parenka taisyklė, o taisyklė renkasi lentelę, ne tunelį: apeinantis srautas pažymimas prieš maršrutizuojant, ir būtent žymė nusiunčia jį į antrąją lentelę.

Antruoju atveju taisyklė nusprendžia, kada konsultuojamasi su lentele, o maršrutas nusprendžia, kur paketas keliaus jau jį parinkus:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Nė vienas objektas nepakeičia kito, o lentelė, kurioje yra tik numatytasis maršrutas, vis tiek gali nesugebėti išspręsti savo šliuzo. Jei pridėjimas atmetamas arba maršrutas yra, bet neveikia, įrašykite tos sąsajos prijungtą prefiksą į tą pačią lentelę arba pažymėkite šuolį onlink , kai tas prefiksas maršrutizuojamas kitur. Aukščiau esančiame bloke 2001:db8:100::/48 žymi tą prijungtą prefiksą uplink1 atveju, o ne savavališką tikslą. fwmark taisyklė tik vartoja žymę, kurią turi nustatyti kažkas kitas – nftables ar iptables taisyklė perdavimo kelyje arba SO_MARK lizde, todėl nukopijuotas blokas be žymės šaltinio nieko nesutapatina.

Antra sąlyga: metrikai neaptinka mirusio tiekėjo

Metrikas yra pirmenybė tarp egzistuojančių maršrutų, o ne būsenos patikra. Kai operatorius atkrenta, branduolys pašalina to įrenginio maršrutus ir perima antrasis numatytasis. Kai kabelis lieka prijungtas, o už jo esantis tiekėjas miršta, lentelėje niekas nesikeičia: pageidaujamas maršrutas įdiegtas, kaimynas pasiekiamas 2 sluoksnyje, o paketai iškeliauja į juodąją skylę. Jei šis skirtumas jūsų sąrankai svarbus, perjungimas turi ateiti iš kažko, kas zondavo kelią ir pašalina maršrutą – ar tai būtų maršrutizavimo tarnyba, ar mažas scenarijus, kuris ištrina ir vėl įrašo įrašą.

Patikrinkite pasirinkimą po to, kai lentelė sudaryta, ir tikrinkite taip, kaip jį matys branduolys. ip -6 route get 2001:db8:100::1 išspausdina maršrutą, kuris būtų naudojamas, įskaitant įrenginį ir pasirinktą šaltinio adresą, ir jis paisoma strateginių taisyklių. Šaltinio adresas, priklausantis netinkamai išorinei linijai, paprastai rodo, kad taisyklė suveikė anksčiau, nei tikėjotės.

Trečia sąlyga: nuspręskite, kam priklauso išsaugojimas

Maršrutas, pridėtas su ip -6 route add , išlieka iki perkrovimo arba kol kažkas jį išvalo. Numatytasis maršrutas, išmoktas iš maršrutizatoriaus skelbimų, turi galiojimo laiką ir maršrutizatorius gali jį atšaukti, o rankiniu būdu pridėtas numatytasis niekada nepasibaigia savaime. Sumaišius abu vienoje lentelėje, pasenęs nuolatinis maršrutas ima viršyti naują skelbiamą, ilgai po to, kai jį apibūdinusi išorinė linija nustojo egzistuoti.

Kiekvienai lentelei pasirinkite vieną šeimininką. Jei tinklo tvarkyklė ar maršrutizavimo tarnyba jau tvarko sąsają, aprašykite strateginį maršrutą ten ir palikite branduolį ramybėje. Jei tai darote scenarijumi, padarykite jį idempotentišku ir tuoj pat parašykite išardymą, nes jo prireiks per pirmąjį blogą pakeitimą:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Maršrutizatoriuje, kuris persiunčia kitiems hostams, prieš kaltindami lentelę patikrinkite net.ipv6.conf.all.forwarding . Kai persiuntimas išjungtas, paketai, adresuoti į kitą tinklą, išmetami, kad ir kokia teisinga būtų 201 lentelė.

Užrašykite sprendimą, kad kitas žmogus galėtų jį audituoti

Inventorius, kuriame saugomas tik fe80::1 , išmeta svarbiausius laukus. Užrašykite tikslą, kitą šuolį, įrenginį, lentelę ir metriką kartu, be to, iš kur atsirado kiekvienas maršrutas: ar jis skelbtas, sugeneruotas tvarkyklės, ar statinis. Kai vėliau kas nors paklaus, ar antroji išorinė linija tikrai neša srautą, tas įrašas atsakys be spėlionių.

Prieš paskelbdami lentelę baigta, patvirtinkite kaimyną su ip -6 neigh show dev uplink0 , iš naujo perskaitykite ip -6 rule show , ar nėra eiliškumo netikėtumų, ir išbandykite srautu, kuris atitinka taisyklę, o ne ping, kuris pasirenka numatytąjį maršrutą. Tada tyčia išjunkite vieną išorinę liniją ir stebėkite, į kurį maršrutą branduolys atsitrauks; atsakymas turėtų sutapti su tuo, kurį užrašėte.

Susiję straipsniai