IPv6 szabályalapú útválasztás, amikor két uplink osztozik a fe80::1 címen

Két uplinked van, és a ip -6 route show ugyanazt a következő ugrást írja ki mindkettőn: default via fe80::1 dev uplink0 és default via fe80::1 dev uplink1. Ez nem duplikált cím konfliktus, és a csupasz következő ugrás fe80::1 szabálytáblába másolása nem mondja meg a kernelnek, melyik linkre gondoltál. A valódi kérdés szűkebb a tünetnél: a második táblának egy linkre van szüksége vagy kettőre, és mi tartja életben ezeket az útvonalakat újraindítás után. Három feltétel, sorrendben ellenőrizve, a legtöbbet eldönti.

Ugyanaz a fe80::1 két különböző szomszéd

A link-local címek egyetlen linkre korlátozódnak, ezért a fe80::1 nem egy kétszer kiírt cím; két szomszéd, amelyek véletlenül közös utótagot használnak. A zónaindex az, ahogyan egy hoszt megmondja, melyikre gondol, ezért a fe80::1%uplink0 és a fe80::1%uplink1 különböző célpontok a kernel számára, és ez az utótag soha nem jut el egy távoli routerhez. Az RFC 4007 írja le az e mögötti zónamodellt, és ezért kell a szabálytáblának minden link-local következő ugráshoz eszközt is hordoznia.

Egy VPN-konfigurációgenerátor, amely egy hosztról numerikus zóna-ID-t másol a sablonba, a helyi kontextust a cím részének tekinti, és a fájl, amit ír, minden olyan gépen hibás, amelynek interfésznevei vagy indexei eltérnek. A szabálytábla sem von össze két linket eggyé: egy irányított VPN csomagokat ad át hálózatok között, de nem viszi át az alagúton egy távoli Ethernet-szomszéd link-local azonosságát, így a link-local forgalom a saját linkjén marad.

Távolítsd el az eszközt, és az útvonal írhatatlanná válik. A ip -6 route add default via fe80::1 table 200 nem tudja feloldani az átjárót, és az iproute2 ezzel utasítja el: Error: Nexthop has invalid gateway. Add hozzá a dev uplink0 eszközt, és a parancs sikerül, mert az eszköz az, ami a következő ugrást a két szomszéd egyikéhez rögzíti. Amit az eszköz nem tud megmondani, az az, hogy az uplink0 a megfelelő link-e ehhez a táblához, és egy másik hosztról másolt útvonal magával hozza annak a hosztnak az interfészneveit, és innen jönnek az igazi hibák.

Első feltétel: egy link vagy kettő a táblában

Kezdd azzal, mire való a második uplink. Ha mindkét link ugyanazt a forgalmat viszi, és az egyik tartalék, a tartalék táblának mindkét átjárót külön metrikával kell tartalmaznia: azonos célok, egy előnyben részesített út, egy nyilvánvaló második választás. Ha az uplinkek azért vannak, mert különböző forgalomnak különböző szolgáltatókon kell kifelé mennie, vagy mert ez egy osztott alagút, ahol bizonyos forgalom megkerüli a VPN-t, a többi pedig bent marad, a két link egyáltalán nem való egyetlen táblába. Két táblába valók, amelyeket egy szabály választ ki, és a szabály a táblát választja, nem az alagutat: a megkerülő forgalom az útválasztás előtt jelölést kap, és a jelölés az, ami a második táblába küldi.

Ebben a második esetben a szabály dönti el, mikor konzultálunk egy táblával, az útvonal pedig azt, hová megy a csomag, miután megtettük:

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

Egyik objektum sem helyettesíti a másikat, és egy csak alapértelmezést tartalmazó tábla is elbukhat az átjáró feloldásában. Ha egy hozzáadás elutasításra kerül, vagy az útvonal létezik, de használhatatlan, tedd az interfész csatlakoztatott előtagját ugyanabba a táblába, vagy jelöld meg az ugrást onlink jelzéssel, amikor az az előtag máshol van irányítva. A fenti blokkban a 2001:db8:100::/48 az uplink1 csatlakoztatott előtagját képviseli, nem egy tetszőleges célpontot. Az fwmark szabály csak olyan jelölést fogyaszt, amelyet valami másnak be kell állítania, egy nftables vagy iptables szabályból a továbbítási úton, vagy a socketen lévő SO_MARK jelölésből, ezért a jelölés forrása nélkül másolt blokk semmivel sem egyezik.

Második feltétel: a metrikák nem észlelik a halott szolgáltatót

A metrika a létező útvonalak közötti preferencia, nem állapotellenőrzés. Amikor a vivő leesik, a kernel eltávolítja az eszköz útvonalait, és a második alapértelmezés veszi át. Amikor a kábel fent marad, és a mögötte lévő szolgáltató meghal, a táblában semmi nem változik: az előnyben részesített útvonal telepítve van, a szomszéd a 2-es rétegen elérhető, és a csomagok egy fekete lyukba távoznak. Ha ez a különbség számít a beállításodnál, a feladatátvételnek olyasvalamiből kell jönnie, ami próbálja az utat és eltávolítja az útvonalat, akár egy útválasztó démon, akár egy kis szkript, amely törli és újratelepíti a bejegyzést.

A tábla felépítése után ellenőrizd a választást, és úgy ellenőrizd, ahogy a kernel látni fogja. A ip -6 route get 2001:db8:100::1 kiírja az útvonalat, amelyet használni fog, beleértve az eszközt és a kiválasztott forrás-címet, és tiszteletben tartja a szabályokat. A rossz uplinkhez tartozó forrás-cím a szokásos jele annak, hogy egy szabály korábban illeszkedett a vártnál.

Harmadik feltétel: döntsd el, ki a perzisztencia tulajdonosa

A ip -6 route add paranccsal hozzáadott útvonal újraindításig vagy addig marad meg, amíg valami ki nem üríti. A routerhirdetésekből tanult alapértelmezés élettartamot hordoz, és a router visszavonhatja, míg a kézzel hozzáadott alapértelmezés magától soha nem jár le. A kettő keverése egy táblában az, ahogy egy elavult állandó útvonal megelőzi a friss hirdetettet, jóval azután, hogy az az uplink, amelyet leírt, megszűnt létezni.

Táblánként egy tulajdonost válassz. Ha egy hálózatkezelő vagy útválasztó démon már kezeli az interfészt, ott írd le a szabályútvonalat, és hagyd békén a kernelt. Ha szkriptben csinálod, tedd idempotenssé a szkriptet, és ugyanakkor írd meg a bontást is, mert szükséged lesz rá az első rossz változtatásnál:

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

Egy olyan routeren, amely más hosztok nevében továbbít, a tábla okolása előtt ellenőrizd a net.ipv6.conf.all.forwarding beállítást. Kikapcsolt továbbítás mellett a másik hálózatnak címzett csomagok eldobódnak, nem számít, mennyire helyes a 201-es tábla.

Rögzítsd a tervet, hogy a következő ember auditálhassa

Egy leltár, amely csak a fe80::1 címet tárolja, eldobja a fontos mezőket. Rögzítsd együtt a célt, a következő ugrást, az eszközt, a táblát és a metrikát, valamint azt, honnan jött az egyes útvonalak: hirdetett, kezelő által generált vagy statikus. Amikor később valaki azt kérdezi, hogy a második uplink valóban visz-e forgalmat, az a feljegyzés találgatás nélkül válaszol.

Mielőtt késznek nyilvánítod a táblát, erősítsd meg a szomszédot a ip -6 neigh show dev uplink0 paranccsal, olvasd újra a ip -6 rule show parancsot sorrendi balesetek után kutatva, és olyan forgalommal tesztelj, amely illeszkedik a szabályra, ne egy pinggel, amely az alapértelmezett útvonalat használja. Aztán szándékosan kapcsold le az egyik uplinket, és figyeld, melyik útvonalra esik vissza a kernel; a válasznak egyeznie kell azzal, amit leírtál.