IPv6 poliitika marsruutimine, kui kaks ühendusliini jagavad aadressi fe80::1

Teil on kaks ühendusliini ja ip -6 route show näitab mõlemal sama järgmist hüpet: default via fe80::1 dev uplink0 ja default via fe80::1 dev uplink1. See ei ole dubleeritud aadresside konflikt, ja palja järgmise hüppe fe80::1 kopeerimine poliitikatabelisse ei ütle tuumale, millist linki te mõtlesite. Tegelik küsimus on kitsam, kui sümptom vihjab: kas teine tabel vajab ühte linki või mõlemat, ja mis hoiab neid marsruute pärast taaskäivitust elus. Kolm tingimust, järjekorras kontrollitud, lahendavad suurema osa sellest.

Sama fe80::1 on kaks erinevat naabrit

Link-local aadressid on piiratud ühe lingiga, seega fe80::1 ei ole üks kaks korda trükitud aadress; need on kaks naabrit, kes juhtumisi jagavad sufiksit. Tsooni indeks on viis, kuidas host ütleb, millist ta mõtleb, seega fe80::1%uplink0 ja fe80::1%uplink1 on tuuma jaoks erinevad sihtkohad ja see sufiks ei reisi kunagi kaugesse ruuterisse. RFC 4007 kirjeldab selle taga olevat tsoonimudelit ja seetõttu peab poliitikatabel kandma seadet iga link-local järgmise hüppega.

VPN-i konfiguratsioonigeneraator, mis kopeerib numbrilise tsooni-ID ühest hostist mallile, kohtleb kohalikku konteksti nii, nagu oleks see aadressi osa, ja fail, mille ta kirjutab, on vale igas masinas, mille liidese nimed või indeksid erinevad. Ka poliitikatabel ei ühenda kahte linki üheks: marsruuditud VPN edastab pakette võrkude vahel, kuid ei kanna kaugema Etherneti naabri link-local identiteeti tunnelist läbi, seega link-local liiklus jääb oma lingile.

Eemaldage seade ja marsruut muutub kirjutamatuks. ip -6 route add default via fe80::1 table 200 ei suuda lüüsi lahendada ja iproute2 lükkab selle tagasi veaga Error: Nexthop has invalid gateway. Lisage dev uplink0 ja käsk õnnestub, sest seade on see, mis kinnitab järgmise hüppe ühele neist kahest naabrist. Mida seade teile öelda ei saa, on see, kas uplink0 on selle tabeli jaoks õige link, ja teisest hostist kopeeritud marsruut toob kaasa selle hosti liidesenimed, ja just sealt tulevad tõelised vead.

Tingimus üks: üks link või kaks tabelis

Alustage sellest, milleks teine ühendusliin on. Kui mõlemad lingid kannavad sama liiklust ja üks on varu, peaks alternatiivne tabel hoidma mõlemat lüüsi erinevate mõõdikutega: samad sihtkohad, üks eelistatud tee, üks ilmne teine valik. Kui ühendusliinid on olemas sellepärast, et erinev liiklus peab väljuma eri teenusepakkujate kaudu, või sellepärast, et see on jaotatud tunnel, kus osa liiklusest läheb VPN-ist mööda, ülejäänu jääb aga sisse, ei kuulu need kaks linki üldse ühte tabelisse. Nad kuuluvad kahte tabelisse, mille valib reegel, ja reegel valib tabeli, mitte tunneli: mööduv liiklus märgistatakse enne marsruutimist ja märgis on see, mis saadab selle teise tabelisse.

Teisel juhul otsustab reegel, millal tabelit küsitakse, ja marsruut otsustab, kuhu pakett pärast seda läheb:

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

Kumbki objekt ei asenda teist ja ainult vaikemarsruuti hoidv tabel võib ikkagi oma lüüsi lahendada mitte suuta. Kui lisamine lükatakse tagasi või marsruut on olemas, aga kasutuskõlbmatu, pange selle liidese ühendatud prefiks samasse tabelisse, või märkige hüpe onlink, kui see prefiks marsruuditakse mujale. Ülalolevas plokis tähistab 2001:db8:100::/48 just seda ühendatud prefiksit uplink1-l, mitte suvalist sihtkohta. Fwmark-reegel tarbib ainult märgist, mille peab panema miski muu, kas nftablesi või iptablesi reeglist edastustee peal või SO_MARK-st soklil, seega ilma märgiallikata kopeeritud plokk ei vasta millelegi.

Tingimus kaks: mõõdikud ei tuvasta surnud teenusepakkujat

Mõõdik on eelistus olemasolevate marsruutide vahel, mitte tervisekontroll. Kui kandja kaob, eemaldab tuum selle seadme marsruudid ja teine vaikemarsruut võtab üle. Kui kaabel jääb üles ja selle taga olev teenusepakkuja sureb, ei muutu tabelis midagi: eelistatud marsruut on paigaldatud, naaber on kihis 2 kättesaadav ja paketid väljuvad musta auku. Kui see erinevus on teie seadistuse jaoks oluline, peab ümberlülitus tulema millestki, mis uurib teed ja eemaldab marsruudi, olgu selleks marsruutimisdemon või väike skript, mis kirje kustutab ja uuesti paigaldab.

Kontrollige valikut pärast tabeli ehitamist ja kontrollige seda nii, nagu tuum seda näeb. ip -6 route get 2001:db8:100::1 prindib marsruudi, mida kasutataks, sealhulgas seadme ja valitud lähteaadressi, ja see austab poliitikareegleid. Valele ühendusliinile kuuluv lähteaadress on tavaline märk sellest, et reegel sobis varem, kui ootasite.

Tingimus kolm: otsustage, kellele kuulub püsivus

Käsuga ip -6 route add lisatud marsruut püsib taaskäivituse või millegi poolt läbipuhumiseni. Ruuteri kuulutustest õpitud vaikemarsruut kannab eluiga ja ruuter võib selle tagasi võtta, samal ajal kui käsitsi lisatud vaikemarsruut ei aegu kunagi iseenesest. Kahe segamine ühes tabelis on viis, kuidas vananenud püsimarsruut hakkab ületama värskelt kuulutatud marsruuti, kaua pärast seda, kui see ühendusliin, mida ta kirjeldas, lakkas olemast.

Valige üks omanik tabeli kohta. Kui võrguhaldur või marsruutimisdemon juba haldab liidest, kirjeldage poliitikamarsruuti seal ja jätke tuum rahule. Kui teete seda skriptiga, tehke skript idempotentseks ja kirjutage lammutamine samal ajal, sest teil on seda vaja esimese halva muudatuse ajal:

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

Ruuteris, mis edastab teiste hostide eest, kontrollige enne tabeli süüdistamist net.ipv6.conf.all.forwarding. Väljalülitatud edastusega visatakse teise võrku adresseeritud paketid ära, ükskõik kui õige on tabel 201.

Kirjeldage disain, et järgmine inimene saaks seda auditeerida

Inventuur, mis salvestab ainult fe80::1, viskab ära väljad, mis loevad. Kirjeldage sihtkoht, järgmine hüpe, seade, tabel ja mõõdik koos, lisaks kust iga marsruut tuli — kuulutatud, halduri loodud või staatiline. Kui keegi hiljem küsib, kas teine ühendusliin tegelikult liiklust kannab, vastab see kirje küsimusele ilma oletusteta.

Enne kui kuulutate tabeli valmis, kinnitage naaber käsuga ip -6 neigh show dev uplink0, lugege ip -6 rule show uuesti läbi järjekorraõnnetuste suhtes ja testige liiklusega, mis vastab reeglile, mitte pingiga, mis võtab vaikemarsruudi. Seejärel võtke üks ühendusliin meelega maha ja jälgige, millisele marsruudile tuum tagasi langeb; vastus peaks ühtima sellega, mille üles kirjutasite.