IPv6 politikas maršrutēšana, ja divas ārējās līnijas izmanto vienu fe80::1

Jums ir divas ārējās līnijas, un ip -6 route show rāda vienu un to pašu nākamo lēcienu abās: default via fe80::1 dev uplink0 un default via fe80::1 dev uplink1. Tas nav adrešu dublēšanās konflikts, un tukšā nākamā lēciena fe80::1 iekopēšana politikas tabulā nepasaka kodolam, kuru līniju jūs domājat. Īstais jautājums ir šaurāks, nekā liecina simptoms: vai otrajai tabulai vajag vienu līniju vai abas, un kas notur šos maršrutus dzīvus pēc pārstartēšanas. Trīs nosacījumi, pārbaudīti secībā, atrisina lielāko daļu.

Tas pats fe80::1 ir divi dažādi kaimiņi

Saistes lokālie adresi ir derīgi tikai vienā līnijā, tāpēc fe80::1 nav viens adress, kas izdrukāts divreiz; tie ir divi kaimiņi, kuriem vienkārši sakrīt sufikss. Zonas indekss ir veids, kā saimnieks pasaka, kuru tas domā, tāpēc fe80::1%uplink0 un fe80::1%uplink1 kodolam ir dažādi galamērķi, un šis sufikss nekad neaizceļo uz attālinātu maršrutētāju. RFC 4007 apraksta zonas modeli aiz tā, un tāpēc politikas tabulai pie katra saistes lokālā nākamā lēciena ir jābūt ierīcei.

VPN konfigurācijas ģenerators, kas kopē ciparu zonas ID no vienas saimnieka sistēmas veidnē, izturas pret lokālo kontekstu tā, it kā tas būtu adreses daļa, un tā rakstītais fails ir nepareizs katrā mašīnā, kuras saskarņu nosaukumi vai indeksi atšķiras. Arī politikas tabula nesavieno divas līnijas vienā: maršrutēts VPN pārraida paketes starp tīkliem, bet nepārnes attālināta Ethernet kaimiņa saistes lokālo identitāti caur tuneli, tāpēc saistes lokālā plūsma paliek savā līnijā.

Noņemiet ierīci, un maršruts kļūst neierakstāms. ip -6 route add default via fe80::1 table 200 nevar atrisināt vārteju, un iproute2 to noraida ar Error: Nexthop has invalid gateway. kļūdu. Pievienojiet dev uplink0 un komanda izdosies, jo tieši ierīce piesaista nākamo lēcienu vienam no šiem diviem kaimiņiem. Ko ierīce nevar pateikt, ir tas, vai uplink0 ir pareizā līnija šai tabulai, un no citas saimnieka sistēmas kopēts maršruts līdzi atnes tās sistēmas saskarņu nosaukumus, un tieši no turienes nāk īstās kļūdas.

Pirmais nosacījums: viena līnija vai divas tabulā

Sāciet ar to, kam paredzēta otrā ārējā līnija. Ja abas līnijas pārvadā vienu un to pašu plūsmu un viena ir rezerves, alternatīvajā tabulā jābūt abām vārtejām ar atšķirīgiem metrikiem: tie paši galamērķi, viens vēlamais ceļš, viena acīmredzama otrā izvēle. Ja ārējās līnijas pastāv tāpēc, ka dažādām plūsmām jāiziet pa dažādiem operatoriem, vai tāpēc, ka tas ir sadalošs tunelis, kurā daļa plūsmas apiet VPN, bet pārējā paliek iekšpusē, šīs divas līnijas nemaz nepieder vienai tabulai. Tās pieder divām tabulām, ko izvēlas noteikums, un noteikums izvēlas tabulu, nevis tuneli: apiejošā plūsma tiek atzīmēta pirms maršrutēšanas, un tieši atzīme to nosūta uz otro tabulu.

Otrajā gadījumā noteikums izlemj, kad tabula tiek konsultēta, bet maršruts izlemj, kur pakete aiziet pēc tam:

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

Neviens objekts neaizstāj otru, un tabula, kurā ir tikai noklusējuma maršruts, joprojām var nespēt atrisināt savu vārteju. Ja pievienošana tiek noraidīta vai maršruts ir, bet nav lietojams, ievietojiet tās saskarnes pievienoto prefiksu tajā pašā tabulā vai atzīmējiet lēcienu onlink , kad šis prefikss tiek maršrutēts citur. Blokā augstāk 2001:db8:100::/48 apzīmē to pievienoto prefiksu uplink1 gadījumā, nevis patvaļīgu galamērķi. fwmark noteikums tikai patērē atzīmi, kas kaut kam citam jāuzstāda — nftables vai iptables noteikumam pārraides ceļā vai SO_MARK ligzdā, tāpēc nokopēts bloks bez atzīmes avota ne ar ko nesakrīt.

Otrais nosacījums: metriki neatklāj mirušu operatoru

Metrika ir priekšroka starp esošiem maršrutiem, nevis veselības pārbaude. Kad operators atkrīt, kodols noņem maršrutus šajā ierīcē un pārņem otrais noklusējums. Kad kabelis paliek ieslēgts un operatora aizmugure mirst, tabulā nekas nemainās: vēlamais maršruts ir uzstādīts, kaimiņš ir sasniedzams 2 slānī, un paketes aiziet melnajā caurumā. Ja šī atšķirība jūsu iestatījumam ir svarīga, pārslēgšanai jānāk no kaut kā, kas zondē ceļu un noņem maršrutu, vai tas būtu maršrutēšanas dēmons, vai mazs skripts, kas izdzēš un atkārtoti ievieto ierakstu.

Pārbaudiet izvēli pēc tabulas izveides un pārbaudiet to tā, kā to redzēs kodols. ip -6 route get 2001:db8:100::1 izdrukā maršrutu, kas tiktu izmantots, ieskaitot ierīci un izvēlēto avota adresi, un tas ievēro politikas noteikumus. Avota adrese, kas pieder nepareizajai ārējai līnijai, parasti liecina, ka noteikums sakrita agrāk, nekā gaidījāt.

Trešais nosacījums: izlemiet, kam pieder noturība

Maršruts, kas pievienots ar ip -6 route add , saglabājas līdz pārstartēšanai vai līdz kaut kas to notīra. Noklusējums, kas iemācīts no maršrutētāja reklāmām, nes derīguma termiņu, un maršrutētājs to var atsaukt, savukārt manuāli pievienotais noklusējums nekad nebeidzas pats. Abu sajaukšana vienā tabulā ir veids, kā novecojis pastāvīgais maršruts sāk pārspēt svaigi reklamēto, ilgi pēc tam, kad to aprakstošā ārējā līnija pārstājusi eksistēt.

Katrai tabulai izvēlieties vienu saimnieku. Ja tīkla pārvaldnieks vai maršrutēšanas dēmons jau pārvalda saskarni, aprakstiet politikas maršrutu tur un atstājiet kodolu mierā. Ja to darāt ar skriptu, padariet to idempotentu un tajā pašā laikā uzrakstiet nojaukšanu, jo tā būs vajadzīga pirmajā sliktajā izmaiņā:

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

Maršrutētājā, kas pārsūta citiem saimniekiem, pirms tabulas vainošanas pārbaudiet net.ipv6.conf.all.forwarding . Kad pārsūtīšana ir izslēgta, paketes, kas adresētas citam tīklam, tiek izmestas, lai cik pareiza būtu 201 tabula.

Pierakstiet projektu, lai nākamais cilvēks varētu to auditēt

Inventārs, kas glabā tikai fe80::1 , izmet svarīgos laukus. Pierakstiet galamērķi, nākamo lēcienu, ierīci, tabulu un metriku kopā, kā arī to, no kurienes nācis katrs maršruts: vai reklamēts, pārvaldnieka ģenerēts vai statisks. Kad kāds vēlāk jautās, vai otrā ārējā līnija tiešām pārvadā plūsmu, šis ieraksts atbildēs bez minējumiem.

Pirms pasludināt tabulu pabeigtu, apstipriniet kaimiņu ar ip -6 neigh show dev uplink0 , pārlasiet ip -6 rule show , vai nav secības negadījumu, un pārbaudiet ar plūsmu, kas atbilst noteikumam, nevis ar ping, kas izvēlas noklusējuma maršrutu. Pēc tam tīši izslēdziet vienu ārējo līniju un vērojiet, uz kuru maršrutu kodols atkāpsies; atbildei jāsakrīt ar to, ko pierakstījāt.