Маршрутызацыя палітык IPv6, калі два каналы ўверх дзеляць fe80::1

У вас два каналы ўверх, і ip -6 route show паказвае адзін і той жа наступны крок на абодвух: default via fe80::1 dev uplink0 і default via fe80::1 dev uplink1. Гэта не канфлікт дублікаваных адрасоў, і капіраванне голага наступнага кроку fe80::1 у табліцу палітыкі не паведамляе ядру, якое звяно вы мелі на ўвазе. Сапраўднае пытанне вузней, чым падказвае сімптом: ці патрэбна другой табліцы адно звяно ці абодва, і што трымае гэтыя маршруты жывымі пасля перазагрузкі. Тры ўмовы, правераныя па чарзе, вырашаюць большасць гэтага.

Адзін і той жа fe80::1 — гэта два розныя суседзі

Адрасы link-local абмежаваныя адным звяном, таму fe80::1 — гэта не адзін адрас, надрукаваны двойчы; гэта два суседзі, якія проста дзеляць суфікс. Індэкс зоны — гэта спосаб вузла сказаць, які з іх ён мае на ўвазе, таму fe80::1%uplink0 і fe80::1%uplink1 — розныя прызначэнні для ядра, і гэты суфікс ніколі не трапляе на аддалены маршрутызатар. RFC 4007 апісвае мадэль зон, што ляжыць за гэтым, і менавіта таму табліца палітыкі мусіць несці прыладу з кожным наступным крокам link-local.

Генератар канфігурацыі VPN, які капіруе лікавы ідэнтыфікатар зоны з аднаго вузла ў шаблон, ставіцца да лакальнага кантэксту так, нібыта ён частка адраса, і файл, які ён запісвае, няправільны на кожнай машыне, дзе імёны або індэксы інтэрфейсаў адрозніваюцца. Табліца палітыкі таксама не злівае два звяны ў адно: маршрутызаваны VPN перадае пакеты паміж сеткамі, але не пераносіць праз тунель link-local ідэнтычнасць аддаленага Ethernet-суседа, таму link-local трафік застаецца на сваім звяне.

Выдаліце прыладу, і маршрут стане незапісваемым. ip -6 route add default via fe80::1 table 200 не можа вырашыць шлюз, і iproute2 адхіляе гэта з Error: Nexthop has invalid gateway. Дадайце dev uplink0 і каманда пройдзе, бо менавіта прылада прывязвае наступны крок да аднаго з гэтых двух суседзяў. Чаго прылада не можа сказаць, дык гэта ці з'яўляецца uplink0 правільным звяном для гэтай табліцы, а маршрут, скапіяваны з іншага вузла, прыносіць з сабой імёны інтэрфейсаў таго вузла, і менавіта адсюль бяруцца сапраўдныя памылкі.

Умова першая: адно звяно ці два ў табліцы

Пачніце з таго, для чаго патрэбны другі канал уверх. Калі абодва звяны нясуць адзін і той жа трафік і адно з іх рэзервовае, альтэрнатыўная табліца павінна трымаць абодва шлюзы з рознымі метрыкамі: тыя ж прызначэнні, адзін пераважны шлях, адзін відавочны другі выбар. Калі каналы ўверх існуюць таму, што розны трафік мусіць выходзіць праз розных правайдараў, або таму што гэта раздзелены тунель, дзе частка трафіку абыходзіць 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

Ні адзін аб'ект не замяняе іншы, і табліца, што трымае толькі маршрут па змаўчанні, усё роўна можа не вырашыць свой шлюз. Калі даданне адхілена, або маршрут ёсць, але непрыдатны, змясціце далучаны прэфікс для гэтага інтэрфейса ў тую ж табліцу або пазначце крок onlink, калі гэты прэфікс маршрутызуецца ў іншае месца. У блоку вышэй 2001:db8:100::/48 адлюстроўвае менавіта гэты далучаны прэфікс на uplink1, а не адвольнае прызначэнне. Правіла fwmark спажывае толькі пазнаку, якую мусіць выставіць нешта іншае — з правіла nftables ці iptables на шляху перасылкі або з SO_MARK на сокеце, — таму блок, скапіяваны без крыніцы пазнакі, не супадае ні з чым.

Умова другая: метрыкі не выяўляюць мёртвага правайдера

Метрыка — гэта перавага сярод маршрутаў, якія існуюць, а не праверка здароўя. Калі носьбіт знікае, ядро выдаляе маршруты на гэтай прыладзе, і другі маршрут па змаўчанні пераймае кіраванне. Калі кабель застаецца на месцы, а правайдер за ім памірае, у табліцы нічога не змяняецца: пераважны маршрут усталяваны, сусед дасягальны на ўзроўні 2, і пакеты сыходзяць у чорную дзірку. Калі гэта розніца важная для вашай канфігурацыі, пераключэнне павінна ісці ад нечага, што правярае шлях і выдаляе маршрут, — ці гэта дэман маршрутызацыі, ці невялікі скрыпт, які выдаляе і пераўсталёўвае запіс.

Праверце выбар пасля пабудовы табліцы, і праверце так, як яго ўбачыць ядро. ip -6 route get 2001:db8:100::1 паказвае маршрут, які будзе выкарыстаны, уключаючы прыладу і выбраны адрас крыніцы, і ён улічвае правілы палітыкі. Адрас крыніцы, што належыць няправільнаму каналу ўверх, — звычайная прыкмета таго, што правіла супала раней, чым вы чакалі.

Умова трэцяя: вырашыце, хто валодае захаваннем

Маршрут, дададзены праз ip -6 route add, жыве да перазагрузкі або да таго, як нешта яго скіне. Маршрут па змаўчанні, вывучаны з аб'яў маршрутызатара, нясе тэрмін жыцця і можа быць адкліканы маршрутызатарам, а маршрут, дададзены ўручную, сам ніколі не сканчаецца. Змешванне двух у адной табліцы — гэта шлях, якім састарэлы пастаянны маршрут пачынае пераўзыходзіць свежы аб'яўлены, праз доўгі час пасля таго, як апісаны ім канал уверх перастаў існаваць.

Выберыце аднаго ўладальніка на табліцу. Калі сеткавы менеджар або дэман маршрутызацыі ўжо кіруе інтэрфейсам, апішыце маршрут палітыкі там і не чапайце ядро. Калі вы робіце гэта скрыптам, зрабіце скрыпт ідэмпатэнтным і адначасова напішыце дэмантаж, бо ён спатрэбіцца вам падчас першай няўдалай змены:

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 на прадмет памылак парадку і праверце трафікам, што адпавядае правілу, а не пінгам, які ідзе па маршруце па змаўчанні. Затым свядома выключыце адзін канал уверх і паглядзіце, на які маршрут ядро адкоціцца; адказ павінен супасці з тым, што вы запісалі.