IPv6-stefnuleiðun þegar tveir tenglar deila fe80::1

Þú hefur tvo tengla, og ip -6 route show prentar sama næsta hopp á báðum: default via fe80::1 dev uplink0 og default via fe80::1 dev uplink1. Þetta er ekki átök um tvítekið vistfang, og að afrita bert næsta hopp fe80::1 inn í stefnutöflu segir kjarnanum ekki hvaða línu þú áttir við. Raunverulega spurningin er þrengri en einkennin benda til: þarf önnur taflan eina línu eða báðar, og hvað heldur þessum leiðum lifandi eftir endurræsingu. Þrjú skilyrði, skoðuð í röð, ráða flestu.

Sama fe80::1 eru tveir mismunandi nágrannar

Link-local-vistföng eru bundin við eina línu, svo fe80::1 er ekki eitt vistfang prentað tvisvar; það eru tveir nágrannar sem eiga það til að deila viðskeyti. Svæðisvísirinn er hvernig hýsill segir hvorum hann eigi við, svo fe80::1%uplink0 og fe80::1%uplink1 eru mismunandi áfangastaðir fyrir kjarnann, og það viðskeyti ferðast aldrei til fjartengds leiðar. RFC 4007 lýsir svæðislíkaninu að baki þessu, og þess vegna verður stefnutafla að bera tæki með hverju link-local næsta hoppi.

VPN-stillingagerð sem afritar tölulegt svæðis-ID af einum hýsli inn í sniðmát meðhöndlar staðbundið samhengi eins og það sé hluti vistfangsins, og skráin sem hún skrifar er röng á hverri vél þar sem viðmótsheiti eða vísar eru mismunandi. Stefnutafla sameinar heldur ekki tvo tengla í einn: leiðbeinandi VPN sendir pakka milli neta, en hún ber ekki link-local auðkenni fjartengds Ethernet-nágranna í gegnum göngin, svo link-local umferð heldur sig á eigin línu.

Fjarlægðu tækið og leiðin verður óskrifanleg. ip -6 route add default via fe80::1 table 200 getur ekki leyst gáttina, og iproute2 hafnar henni með Error: Nexthop has invalid gateway. Bættu við dev uplink0 og skipunin tekst, því tækið er það sem festir næsta hopp við annan af þessum tveimur nágrönnum. Það sem tækið getur ekki sagt þér er hvort uplink0 sé rétta línan fyrir þessa töflu, og leið afrituð af öðrum hýsli hefur með sér viðmótsheiti þess hýsils, og þaðan koma raunverulegu mistökin.

Skilyrði eitt: ein lína eða tvær í töflunni

Byrjaðu á því hvað seinni tenglinum er ætlað. Ef báðir tenglar bera sömu umferð og annar er varaleið, ætti varataflan að halda báðum gáttum með mismunandi mælingum: sömu áfangastaðir, ein ákjósanleg leið, eitt augljóst annarvals. Ef tenglarnir eru til vegna þess að mismunandi umferð verður að fara út um mismunandi þjónustuveitendur, eða vegna þess að þetta er klofin göng þar sem hluti umferðar fer fram hjá VPN-inu á meðan restin er inni, eiga tveir tenglar alls ekki heima í einni töflu. Þeir eiga heima í tveimur töflum, valdar af reglu, og reglan velur töfluna, ekki göngin: umferð sem á að fara fram hjá er merkt áður en henni er leiðbeint, og merkið er það sem sendir hana í seinni töfluna.

Í seinna tilvikinu ræður reglan hvenær töflu er flett upp, og leiðin ræður því hvert pakkinn fer þegar það er gert:

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

Hvorugt hlutanna kemur í stað hins, og tafla sem heldur aðeins sjálfgefinni leið getur samt mistekist að leysa gáttina. Ef viðbót er hafnað, eða leiðin er til en ónothæf, settu tengda forskeytið fyrir það viðmót í sömu töflu, eða merktu hoppið onlink þegar það forskeyti er leiðbeint annars staðar. Í blokkinni hér að ofan stendur 2001:db8:100::/48 fyrir tengda forskeytið á uplink1, ekki fyrir handahófskenndan áfangastað. fwmark-reglan eyðir aðeins merki sem eitthvað annað verður að setja, úr nftables- eða iptables-reglu á framsendingarleiðinni eða úr SO_MARK á sokknum, svo blokk afrituð án merkjaheimildar passar við ekkert.

Skilyrði tvö: mælingar uppgötva ekki dauðan þjónustuveitanda

Mæling er val milli leiða sem eru til, ekki heilsufarsskoðun. Þegar burðarinn dettur fjarlægir kjarninn leiðirnar á því tæki og sjálfgefna leiðin sem er næst tekur við. Þegar kapallinn er áfram uppi og þjónustuveitandinn bak við hann deyr breytist ekkert í töflunni: ákjósanlega leiðin er uppsett, nágranninn er náanleg á lagi 2, og pakkarnir hverfa inn í svarthol. Ef sá greinarmunur skiptir máli fyrir uppsetninguna verður varaleiðin að koma frá einhverju sem kannar leiðina og fjarlægir hana, hvort sem það er leiðarþjónn eða lítið skript sem eyðir og setur færsluna upp aftur.

Staðfestu valið eftir að taflan er byggð, og staðfestu það eins og kjarninn muni sjá það. ip -6 route get 2001:db8:100::1 prentar leiðina sem yrði notuð, þar á meðal tækið og valda upprunavistfangið, og hún virðir stefnureglur. Upprunavistfang sem tilheyrir röngum tengli er venjulega merkið um að regla hafi passað fyrr en þú bjóst við.

Skilyrði þrjú: ákveddu hver á viðvarandi ástand

Leið bætt við með ip -6 route add lifir til endurræsingar eða þar til eitthvað hreinsar hana. Sjálfgefin leið lærð af leiðartilkynningum hefur líftíma og getur verið dregin til baka af leiðaranum, á meðan sjálfgefin leið bætt við handvirkt rennur aldrei út af sjálfu sér. Að blanda þessu tvennu í eina töflu er hvernig gömul varanleg leið endar ofar nýrri tilkynntri leið, löngu eftir að tengillinn sem hún lýsti hætti að vera til.

Veldu einn eiganda fyrir hverja töflu. Ef netstjóri eða leiðarþjónn stýrir viðmótinu þegar, lýstu stefnuleiðinni þar og láttu kjarnann í friði. Ef þú skrifar skript fyrir þetta skaltu gera skriptið idempotent og skrifa niðurrifið á sama tíma, því þú munt þurfa það við fyrstu slæmu breytinguna:

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

Á leiðara sem sendir fram fyrir aðra hýsla skaltu athuga net.ipv6.conf.all.forwarding áður en þú kennir töflunni um. Með framsendingu af er pökkum sem beint er að öðru neti hent, sama hversu rétt tafla 201 er.

Skráðu hönnunina svo næsti maður geti endurskoðað hana

Skrá sem geymir aðeins fe80::1 hefur kastað frá sér sviðunum sem skipta máli. Skráðu áfangastaðinn, næsta hopp, tækið, töfluna og mælinguna saman, auk þess hvaðan hver leið kom, hvort hún er tilkynnt, mynduð af stjóra eða kyrrstæð. Þegar einhver spyr síðar hvort seinni tengillinn beri í raun umferð svarar sú skrá án giskana.

Áður en þú kallar töfluna fullbúna skaltu staðfesta nágrannann með ip -6 neigh show dev uplink0, lesa ip -6 rule show aftur fyrir röðunarslys, og prófa með umferð sem passar við regluna í stað ping sem tekur sjálfgefnu leiðina. Taktu svo einn tengil niður viljandi og sjáðu hvaða leið kjarninn fellur til baka á; svarið ætti að stemma við það sem þú skrifaðir niður.