Rutimi i politikave IPv6 kur dy uplink ndajnë fe80::1

Ke dy uplink, dhe ip -6 route show shtyp të njëjtin next hop në të dyja: default via fe80::1 dev uplink0 dhe default via fe80::1 dev uplink1. Ky nuk është konflikt i adresave të dyfishta, dhe kopjimi i next hop-it të zhveshur fe80::1 në një tabelë politikash nuk i tregon kernelit cilën lidhje ke dashur. Pyetja e vërtetë është më e ngushtë se sa sugjeron simptoma: a i duhet tabelës së dytë një lidhje apo të dyja, dhe çfarë i mban ato rrugë gjallë pas një rindezjeje. Tre kushte, të kontrolluara me radhë, zgjidhin pjesën më të madhe.

I njëjti fe80::1 janë dy fqinjë të ndryshëm

Adresat link-local janë të kufizuara në një lidhje të vetme, prandaj fe80::1 nuk është një adresë e shtypur dy herë; janë dy fqinjë që ndajnë rastësisht një prapashtesë. Indeksi i zonës është si një host thotë se cilin ka fjalën, prandaj fe80::1%uplink0 dhe fe80::1%uplink1 janë destinacione të ndryshme për kernelin, dhe ajo prapashtesë nuk udhëton kurrë drejt një ruteri të largët. RFC 4007 përshkruan modelin e zonave pas kësaj, dhe për këtë një tabelë politikash duhet të mbajë një pajisje me çdo next hop link-local.

Një gjenerator konfigurimi VPN që kopjon një ID zone numerike nga një host në një shabllon e trajton kontekstin lokal sikur të ishte pjesë e adresës, dhe skedari që shkruan është i gabuar në çdo makinë, emrat ose indekset e ndërfaqeve të së cilës ndryshojnë. As një tabelë politikash nuk bashkon dy lidhje në një: një VPN e rutuar kalon paketa midis rrjeteve, por nuk e mbart identitetin link-local të një fqinji Ethernet të largët nëpër tunel, prandaj trafiku link-local mbetet në lidhjen e vet.

Hiq pajisjen dhe rruga bëhet e pashkrueshme. ip -6 route add default via fe80::1 table 200 nuk mund ta zgjidhë gateway-in, dhe iproute2 e refuzon me Error: Nexthop has invalid gateway. Shto dev uplink0 dhe komanda ka sukses, sepse pajisja është ajo që e fikson next hop-in në njërin prej atyre dy fqinjëve. Ajo që pajisja nuk mund të të thotë është nëse uplink0 është lidhja e duhur për këtë tabelë, dhe një rrugë e kopjuar nga një host tjetër sjell me vete emrat e ndërfaqeve të atij hosti, dhe nga aty vijnë gabimet e vërteta.

Kushti një: një lidhje apo dy në tabelë

Fillo me atë për çfarë është uplink-u i dytë. Nëse të dyja lidhjet mbajnë të njëjtin trafik dhe njëra është rezervë, tabela alternative duhet të mbajë të dy gateway-t me metrika të ndryshme: të njëjtat destinacione, një shteg i preferuar, një zgjedhje e dytë e dukshme. Nëse uplink-ët ekzistojnë sepse trafik i ndryshëm duhet të dalë përmes ofruesve të ndryshëm, ose sepse ky është një split tunnel ku një pjesë e trafikut anashkalon VPN-në ndërsa pjesa tjetër mbetet brenda, dy lidhjet nuk i përkasin fare një tabele të vetme. Ato i përkasin dy tabelave, të zgjedhura nga një rregull, dhe rregulli zgjedh tabelën, jo tunelin: trafiku që anashkalon shënohet para se të rutohet, dhe shenja është ajo që e dërgon në tabelën e dytë.

Në atë rast të dytë rregulli vendos kur konsultohet një tabelë, dhe rruga vendos ku shkon paketa sapo ndodh:

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

Asnjëri prej objekteve nuk e zëvendëson tjetrin, dhe një tabelë që mban vetëm një default mund të dështojë përsëri të zgjidhë gateway-in e vet. Nëse një add refuzohet, ose rruga është e pranishme por e papërdorshme, vendos prefiksin e lidhur për atë ndërfaqe në të njëjtën tabelë, ose shëno hop-in onlink kur ai prefiks rutohet diku tjetër. Në bllokun më sipër, 2001:db8:100::/48 qëndron për atë prefiks të lidhur në uplink1, jo për një destinacion arbitrar. Rregulli fwmark konsumon vetëm një shenjë që diçka tjetër duhet ta vendosë, nga një rregull nftables ose iptables në shtegun e përcjelljes ose nga SO_MARK në socket, prandaj një bllok i kopjuar pa burim shenje nuk përputhet me asgjë.

Kushti dy: metrikat nuk zbulojnë një ofrues të vdekur

Një metrikë është një preferencë midis rrugëve që ekzistojnë, jo një kontroll shëndeti. Kur operatori bie, kerneli heq rrugët në atë pajisje dhe default-i i dytë merr kontrollin. Kur kablloja mbetet lart dhe ofruesi pas saj vdes, në tabelë nuk ndryshon asgjë: rruga e preferuar është e instaluar, fqinji është i arritshëm në shtresën 2, dhe paketat nisen në një vrimë të zezë. Nëse ai dallim ka rëndësi për konfigurimin tënd, failover-i duhet të vijë nga diçka që sond përcjelljen dhe heq rrugën, qoftë një daemon rutimi apo një skript i vogël që fshin dhe riinstalon hyrjen.

Verifiko zgjedhjen pasi tabela të jetë ndërtuar, dhe verifikoje ashtu siç do ta shohë kerneli. ip -6 route get 2001:db8:100::1 shtyp rrugën që do të përdorej, duke përfshirë pajisjen dhe adresën burimore të zgjedhur, dhe respekton rregullat e politikës. Një adresë burimore që i përket uplink-ut të gabuar është shenja e zakonshme që një rregull u përputh më herët nga sa prisje.

Kushti tre: vendos kush e zotëron këmbënguljen

Një rrugë e shtuar me ip -6 route add mbijeton deri në rindezje ose derisa diçka ta flush-ojë. Një default i mësuar nga reklamat e ruterit mbart një jetëgjatësi dhe mund të tërhiqet nga ruteri, ndërsa një default i shtuar me dorë nuk skadon kurrë vetë. Përzierja e të dyjave në një tabelë është si një rrugë e vjetër e përhershme përfundon duke ia kaluar një rruge të freskët të reklamuar, shumë kohë pasi lidhja që përshkruante pushoi së ekzistuari.

Zgjidh një pronar për tabelë. Nëse një menaxher rrjeti ose daemon rutimi e menaxhon tashmë ndërfaqen, përshkruaj rrugën e politikës atje dhe lëre kernelin në paqe. Nëse po e skripton, bëje skriptin idempotent dhe shkruaj teardown-in në të njëjtën kohë, sepse do t'i duash gjatë ndryshimit të parë të keq:

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

Në një ruter që përcjell për hoste të tjerë, kontrollo net.ipv6.conf.all.forwarding para se ta fajësosh tabelën. Me përcjelljen e fikur, paketat që i drejtohen një rrjeti tjetër hidhen, sado e saktë që është tabela 201.

Regjistro dizajnin që personi i ardhshëm ta auditojë

Një inventar që ruan vetëm fe80::1 i hedh poshtë fushat që kanë rëndësi. Regjistro bashkë destinacionin, next hop-in, pajisjen, tabelën dhe metrikën, plus nga ka ardhur çdo rrugë, nëse është e reklamuar, e gjeneruar nga menaxheri apo statike. Kur dikush më vonë pyet nëse uplink-u i dytë po mban vërtet trafik, ai regjistrim përgjigjet pa hamendje.

Para se ta shpallësh tabelën të përfunduar, konfirmo fqinjin me ip -6 neigh show dev uplink0, rilexo ip -6 rule show për aksidente renditjeje, dhe testo me trafik që përputhet me rregullin në vend të një ping që merr rrugën e paracaktuar. Pastaj ul qëllimisht një uplink dhe shiko në cilën rrugë kerneli kthehet; përgjigjja duhet të përputhet me atë që ke shkruar.