IPv6-policyrouting as twa uplinks fe80::1 diele

Do hast twa uplinks, en ip -6 route show toant deselde folgjende hop op beide: default via fe80::1 dev uplink0 en default via fe80::1 dev uplink1. Dat is gjin konflikt mei dûbele adressen, en it keale folgjende hop fe80::1 yn in policy-tabel kopiearje fertelt de kernel net hokker link do bedoelde. De echte fraach is smeller as it symptoom suggerearret: hat de twadde tabel ien link of beide nedich, en wat hâldt dy rûtes libben nei in werstart. Trije betingsten, yn folchoarder kontrolearre, besljochtsje it measte.

Deselde fe80::1 binne twa ferskillende buorlju

Link-local adressen binne beheind ta ien link, dus fe80::1 is net ien adres dat twa kear toand wurdt; it binne twa buorlju dy't tafallich in suffix diele. De sône-yndeks is hoe't in host seit hokker hy bedoelt, dus fe80::1%uplink0 en fe80::1%uplink1 binne ferskillende bestimmings foar de kernel, en dat suffix reizget nea nei in eksterne router. RFC 4007 beskriuwt it sônemodel hjiryn, en dêrom moat in policy-tabel by elk link-local folgjend hop in apparaat meinimme.

In VPN-konfiguraasjegenerator dy't in numerike sône-ID fan ien host yn in sjabloan kopiearret, behannelet lokale kontekst as wie dy diel fan it adres, en it bestân dat hy skriuwt is ferkeard op elke masine waans ynterfacenammen of -yndeksen ferskille. In policy-tabel foeget ek gjin twa links gear ta ien: in ruote VPN jout pakketten troch tusken netwurken, mar draacht de link-local identiteit fan in eksterne Ethernet-buorman net troch de tunnel, dus link-local ferkear bliuwt op syn eigen link.

Ferwiderje it apparaat en de rûte wurdt ûnskriuwber. ip -6 route add default via fe80::1 table 200 kin de gateway net fine, en iproute2 wegert it mei Error: Nexthop has invalid gateway. Foegje dev uplink0 ta en it kommando slagget, om't it apparaat de folgjende hop oan ien fan dy twa buorlju fêstset. Wat it apparaat dy net fertelle kin, is oft uplink0 de juste link foar dizze tabel is, en in rûte kopiearre fan in oare host nimt de ynterfacenammen fan dy host mei, en dêr komme de echte flaters wei.

Betingst ien: ien link of twa yn 'e tabel

Begjin mei wêr't de twadde uplink foar is. As beide links itselde ferkear drage en ien in standby is, moat de alternative tabel beide gateways mei ferskillende metryske wearden hâlde: deselde bestimmings, ien foarkarspaad, ien dúdlike twadde kar. As de uplinks besteane om't ferskillend ferkear fia ferskillende providers nei bûten moat, of om't dit in split tunnel is wêrby't in diel fan it ferkear de VPN omgiet wylst de rest binnen bliuwt, hearre de twa links hielendal net yn ien tabel. Se hearre yn twa tabellen, keazen troch in regel, en de regel kiest de tabel, net de tunnel: ferkear dat omgiet wurdt markearre foardat it rûte wurdt, en de markearring is wat it nei de twadde tabel stjoert.

Yn it twadde gefal bepaalt de regel wannear't in tabel rieplachte wurdt, en de rûte bepaalt wêr't it pakket hinne giet sadree't dat bart:

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

Gjin fan beide objekten ferfangt it oare, en in tabel mei allinnich in default kin noch altyd de gateway net fine. As in add wegere wurdt, of de rûte bestiet mar is ûnbrûkber, set dan it connected prefix foar dy ynterface yn deselde tabel, of markearje de hop onlink wannear't dat prefix earne oars rûte wurdt. Yn it blok hjirboppe stiet 2001:db8:100::/48 foar dat connected prefix op uplink1, net foar in willekeurige bestimming. De fwmark-regel ferbrûkt allinnich in markearring dy't eat oars sette moat, fanút in nftables- of iptables-regel op it trochjaanpaad of fanút SO_MARK op de socket, dus in blok dat sûnder markeringsboarne kopiearre is, matcht neat.

Betingst twa: metryske wearden ûntdekke gjin deade provider

In metryske wearde is in foarkar tusken rûtes dy't bestean, gjin sûnenscheck. As de carrier fuort falt, ferwideret de kernel de rûtes op dat apparaat en nimt de twadde default it oer. As de kabel bliuwt lizzen en de provider derachter stjert, feroaret der neat yn 'e tabel: de foarkarsrûte is ynstallearre, de buorman is op laach 2 berikber, en de pakketten ferdwine yn in swart gat. As dat ûnderskied foar dyn opstelling fan belang is, moat failover komme fan eat dat it paad peilet en de rûte ferwidert, itsij in routing-daemon of in lyts skript dat de entry ferwidert en opnij ynstallearret.

Ferifiearje de kar neidat de tabel boud is, en ferifiearje dy sa't de kernel him sjen sil. ip -6 route get 2001:db8:100::1 toant de rûte dy't brûkt wurde soe, ynklusyf it apparaat en it selektearre boarneadres, en respektearret policy-regels. In boarneadres dat by de ferkearde uplink heart, is it gewoane teken dat in regel earder matche as do ferwachte.

Betingst trije: beslút wa't de persistinsje hat

In rûte dy't mei ip -6 route add tafoege is, oerlibbet oant in werstart of oant eat him wist. In default dy't fan router-advertinsjes leard is, hat in libbensdoer en kin troch de router weromlutsen wurde, wylst in mei de hân tafoege default nea fansels ferrint. De twa yn ien tabel minge is hoe't in ferâldere permaninte rûte in farsk advertearre rûte oerstimt, lang neidat de uplink dy't er beskreau ophold te bestean.

Kies ien eigner per tabel. As in netwurkbehearder of routing-daemon de ynterface al beheart, beskriuw de policy-rûte dêr en lit de kernel gewurde. As do it skriptest, meitsje it skript idempotint en skriuw de teardown tagelyk, want do hast him nedich by de earste minne feroaring:

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

Kontrolearje op in router dy't foar oare hosts trochstjoert net.ipv6.conf.all.forwarding foardat do de tabel de skuld jout. Mei trochstjoeren út wurde pakketten dy't oan in oar netwurk adressearre binne, dropt, hoe korrekt tabel 201 ek is.

Fêstlegje it ûntwerp sadat de folgjende persoan it audite kin

In ynventaris dy't allinnich fe80::1 opslacht, smyt de fjilden dy't der ta dogge fuort. Fêstlegje de bestimming, de folgjende hop, it apparaat, de tabel en de metryske wearde byinoar, plus wêr't elke rûte wei kaam, oft dy advertearre, troch de behearder generearre of statysk is. As immen letter freget oft de twadde uplink echt ferkear draacht, beantwurdet dat record de fraach sûnder giswurk.

Foardat do de tabel klear neamst, befêstigje de buorman mei ip -6 neigh show dev uplink0, lês ip -6 rule show opnij foar folchoarderflaters, en test mei ferkear dat by de regel past ynstee fan in ping dy't de defaultrûte nimt. Nim dan mei opsetsin ien uplink del en sjoch nei hokker rûte de kernel weromfalt; it antwurd moat klopje mei wat do opskreaun hast.