IPv6 рутирање политике када два линка деле fe80::1

Имаш два линка, а ip -6 route show исписује исти следећи скок на оба: default via fe80::1 dev uplink0 и default via fe80::1 dev uplink1. То није сукоб дуплих адреса, а копирање голог следећег скока fe80::1 у табелу политике не говори кернелу на коју си везу мислио. Право питање је уже него што симптом сугерише: да ли је другој табели потребна једна веза или обе, и шта те руте држи живим после поновног покретања. Три услова, проверавана по реду, решавају већину.

Исти fe80::1 су два различита суседа

Линк-локал адресе су ограничене на једну везу, па fe80::1 није једна адреса исписана двапут; то су два суседа која случајно деле суфикс. Зонски индекс је начин на који домаћин каже на који мисли, па fe80::1%uplink0 и fe80::1%uplink1 су различита одредишта за кернел, а тај суфикс никада не путује до удаљеног рутера. RFC 4007 описује зонски модел који стоји за тим, и зато табела политике мора носити уређај са сваким линк-локал следећим скоком.

Генератор VPN конфигурације који копира нумерички зонски ИД са једног домаћина у шаблон третира локални контекст као да је део адресе, а датотека коју пише погрешна је на сваком рачунару чија се имена или индекси интерфејса разликују. Ни табела политике не спаја две везе у једну: рутирана VPN преноси пакете између мрежа, али не преноси линк-локал идентитет удаљеног Ethernet суседа кроз тунел, па линк-локал саобраћај остаје на својој вези.

Уклони уређај и рута постаје незаписива. ip -6 route add default via fe80::1 table 200 не може да разреши гејтвеј, а iproute2 га одбија са Error: Nexthop has invalid gateway. Додај dev uplink0 и команда успева, јер уређај је оно што причвршћује следећи скок за једног од та два суседа. Оно што ти уређај не може рећи јесте да ли је uplink0 права веза за ову табелу, а рута копирана са другог домаћина доноси имена интерфејса тог домаћина, и одатле долазе праве грешке.

Услов један: једна веза или две у табели

Почни од тога чему служи други линк. Ако обе везе носе исти саобраћај и једна је резерва, алтернативна табела треба да држи оба гејтвеја са различитим метрикама: иста одредишта, један пожељан пут, један очигледан други избор. Ако линкови постоје зато што различит саобраћај мора изаћи кроз различите провајдере, или зато што је ово split тунел у ком део саобраћаја заобилази VPN док остатак остаје унутра, две везе уопште не припадају једној табели. Припадају двема табелама, изабранима правилом, а правило бира табелу, не тунел: саобраћај који заобилази означава се пре усмеравања, и ознака је оно што га шаље у другу табелу.

У том другом случају правило одлучује када се табела консултује, а рута одлучује куда пакет иде кад се то догоди:

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

Ниједан од објеката не замењује други, а табела која држи само подразумевану руту ипак може да не разреши свој гејтвеј. Ако се add одбије, или рута постоји али је неупотребљива, стави повезани префикс тог интерфејса у исту табелу, или означи скок као onlink када се тај префикс рутира другде. У горњем блоку, 2001:db8:100::/48 представља тај повезани префикс на uplink1, не произвољно одредиште. fwmark правило троши само ознаку коју мора поставити нешто друго, из nftables или iptables правила на путу прослеђивања или из SO_MARK на сокету, па блок копиран без извора ознаке не одговара ничему.

Услов два: метрике не откривају мртвог провајдера

Метрика је преференција међу рутама које постоје, не провера здравља. Кад оператер падне, кернел уклања руте на том уређају и друга подразумевана рута преузима. Кад кабл остане горе, а провајдер иза њега умре, у табели се ништа не мења: пожељна рута је инсталирана, сусед је доступан на слоју 2, а пакети одлазе у црну рупу. Ако та разлика важи за твоје подешавање, failover мора доћи од нечега што сондира пут и уклања руту, било да је то рутинг демон или мали скрипт који брише и поново инсталира унос.

Провери избор након што је табела изграђена, и провери га онако како ће га кернел видети. ip -6 route get 2001:db8:100::1 исписује руту која би се користила, укључујући уређај и изабрану изворну адресу, и поштује правила политике. Изворна адреса која припада погрешном линку уобичајен је знак да је правило одговарало раније него што си очекивао.

Услов три: одлучи коме припада трајност

Рута додата са ip -6 route add преживљава до поновног покретања или док је нешто не испере. Подразумевана рута научена из огласа рутера носи животни век и рутер је може повући, док ручно додата подразумевана рута никада сама не истиче. Мешање то двоје у једној табели начин је на који застарела трајна рута заврши испред свеже оглашене, давно након што је линк који је описивала престао да постоји.

Изабери једног власника по табели. Ако мрежни менаџер или рутинг демон већ управља интерфејсом, опиши руту политике тамо и остави кернел на миру. Ако то скриптујеш, учини скрипту идемпотентном и напиши teardown у исто време, јер ће ти требати током прве лоше промене:

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

На рутеру који прослеђује за друге домаћине, провери net.ipv6.conf.all.forwarding пре него што окривиш табелу. Са искљученим прослеђивањем, пакети намењени другој мрежи одбацују се, колико год табела 201 била исправна.

Забележи дизајн да га следећа особа може ревидирати

Инвентар који чува само fe80::1 одбацује поља која су важна. Забележи одредиште, следећи скок, уређај, табелу и метрику заједно, плус одакле је свака рута дошла, да ли је оглашена, генерисана од менаџера или статична. Кад неко касније пита носи ли други линк стварно саобраћај, тај запис одговара без нагађања.

Пре него што прогласиш табелу готовом, потврди суседа са ip -6 neigh show dev uplink0, поново прочитај ip -6 rule show због незгода с редоследом, и тестирај саобраћајем који одговара правилу уместо пингом који узима подразумевану руту. Затим намерно спусти један линк и прати на коју се руту кернел враћа; одговор би требало да одговара ономе што си забележио.