IPv6 politikaren bideratzea bi uplinkek fe80::1 partekatzen dutenean

Bi uplink dituzu, eta ip -6 route show hurrengo jauzi bera bistaratzen du bietan: default via fe80::1 dev uplink0 eta default via fe80::1 dev uplink1. Hau ez da helbide bikoiztuen gatazka, eta hurrengo jauzi soila fe80::1 politika-taula batean kopiatzeak ez dio nukleoari zein esteka nahi zenuen esaten. Benetako galdera sintomak iradokitzen duena baino estuagoa da: bigarren taulak esteka bat behar duen edo biak, eta zer mantentzen ditu bide horiek bizirik berrabiarazi ondoren. Hiru baldintzek, ordenan egiaztatuta, horren zatirik handiena konpontzen dute.

fe80::1 bera bi auzokide desberdin dira

Link-local helbideak esteka bakarrera mugatuta daude, beraz fe80::1 ez da bi aldiz inprimatutako helbide bat; sufijo bat partekatzen duten bi auzokide dira. Eremu-indizea da ostalariak zein adierazi nahi duen esateko modua, beraz fe80::1%uplink0 eta fe80::1%uplink1 helmuga desberdinak dira nukleoarentzat, eta sufijo hori ez da inoiz urruneko bideratzailera joaten. RFC 4007 honek horren atzeko eremu-eredua deskribatzen du, eta horregatik politika-taulak gailu bat eraman behar du link-local hurrengo jauzi bakoitzarekin.

Ostalari batetik zona-ID numeriko bat txantiloi batera kopiatzen duen VPN konfigurazio-sortzaile batek tokiko testuingurua helbidearen parte balitz bezala tratatzen du, eta idazten duen fitxategia okerra da interfaze-izenak edo indizeak desberdinak diren makina orotan. Politika-taula batek ere ez ditu bi esteka bat egiten: bideratutako VPN batek paketeak sareen artean pasatzen ditu, baina ez du urruneko Ethernet auzokide baten link-local identitatea tunelaren bidez eramaten, beraz link-local trafikoak bere estekan jarraitzen du.

Kendu gailua eta bidea idaztezina bihurtzen da. ip -6 route add default via fe80::1 table 200 ezin du atebidea ebatzi, eta iproute2-k Error: Nexthop has invalid gateway. mezuarekin ukatzen du; gehitu dev uplink0 eta komandoa arrakastatsua da, gailua baita hurrengo jauzia bi auzokide horietako batera lotzen duena. Gailuak esan ezin dizun gauza da uplink0 taula honetarako esteka egokia den ala ez, eta beste ostalari batetik kopiatutako bideak ostalari haren interfaze-izenak ekartzen ditu, eta hortik datoz benetako akatsak.

Lehen baldintza: esteka bat edo bi taulan

Hasi bigarren uplink-a zertarako den argituta. Bi estekek trafiko bera eramaten badute eta bat erreserba bada, taula alternatiboak bi atebideak metrika ezberdinekin eduki beharko lituzke: helmuga berak, bide hobetsi bat, bigarren aukera ageriko bat. Estekak existitzen badira trafiko desberdinak hornitzaile desberdinetatik irten behar duelako, edo tunel zatitu bat delako non trafikoaren zati batek VPN-a saihesten duen eta gainerakoak barruan jarraitzen duen, bi estekak ez dute batere taula bakarrean lekurik. Bi taulatan daude, arau batek aukeratuta, eta arauak taula aukeratzen du, ez tunela: saihesten den trafikoa bideratu aurretik markatzen da, eta marka da bigarren taulara bidaltzen duena.

Bigarren kasu horretan arauak erabakitzen du noiz kontsultatzen den taula bat, eta bideak erabakitzen du paketea norantz doan ondoren:

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

Bi objektuetako batek ere ez du bestea ordezkatzen, eta defektuzko bide bat bakarrik duen taula batek oraindik huts egin dezake bere atebidea ebaztean. Gehitzea baztertzen bada, edo bidea badago baina erabilezina bada, jarri interfaze horren aurrizki konektatua taula berean, edo markatu jauzia onlink gisa aurrizki hori beste nonbait bideratzen denean. Goiko blokean 2001:db8:100::/48 uplink1-eko aurrizki konektatu horren ordez dago, ez edozein helmugaren ordez. fwmark arauak beste zerbaiti jarri behar zaion marka bat kontsumitzen du soilik, birbidaltze-bideko nftables edo iptables arau batetik edo socket-eko SO_MARK-tik, beraz marka-iturririk gabe kopiatutako bloke batek ez du ezer bat ere egiten.

Bigarren baldintza: metrikek ez dute hornitzaile hila hautematen

Metrika bat existitzen diren bideen arteko lehentasuna da, ez osasun-egiaztapena. Garraiolaria erortzen denean, nukleoak gailu horretako bideak kentzen ditu eta bigarren defektuzko bideak hartzen du lekua. Kablea gorantza geratzen bada eta atzeko hornitzailea hiltzen bada, taulan ez da ezer aldatzen: bide hobetsia instalatuta dago, auzokidea geruza 2an iristeko modukoa da, eta paketeak zulo beltz batera ateratzen dira. Bereizketa hori zure konfiguraziorako garrantzitsua bada, failover-ra bidea aztertzen eta bidea kentzen duen zerbaitetik etorri behar da, bideratze-daemon bat edo sarrera ezabatu eta berriro instalatzen duen script txiki bat izan.

Egiaztatu aukera taula eraiki ondoren, eta egiaztatu nukleoak ikusiko duen moduan. ip -6 route get 2001:db8:100::1 erabiliko litzatekeen bidea inprimatzen du, gailua eta hautatutako iturburu-helbidea barne, eta politika-arauak errespetatzen ditu. Uplink okerreko iturburu-helbidea arau bat espero baino lehenago bat etorri zela adierazteko ohiko seinalea da.

Hirugarren baldintza: erabaki nor den iraunkortasunaren jabe

ip -6 route add erabiliz gehitutako bide bat berrabiarazi arte edo zerbait bere garbitu arte irauten du. Bideratzailearen iragarkietatik ikasitako defektuzko bide batek bizitza bat darama eta bideratzaileak kendu dezake, eskuz gehitutako defektuzko bide batek inoiz ez du berez iraungitzen. Biak taula batean nahastea da bide iraunkor zaharkitu bat berriki iragarritako bat gainditzen hasten den modua, deskribatzen zuen uplink-a existitzeari utzi eta askoz geroago.

Aukeratu jabe bat taulako. Sare-kudeatzaile batek edo bideratze-daemon batek interfazea kudeatzen badu jada, deskribatu politika-bidea han eta utzi nukleoa bakean. Script bidez egiten baduzu, egin script-a idempotentea eta idatzi desmuntatzea aldi berean, lehen aldaketa txarrean beharko duzu eta:

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

Beste ostalari batzuentzat birbidaltzen duen bideratzaile batean, egiaztatu net.ipv6.conf.all.forwarding taula erruduntzat jo aurretik. Birbidaltzea itzalita dagoenean, beste sare batera zuzendutako paketeak baztertu egiten dira, 201 taula zuzena den edo ez kontuan hartu gabe.

Erregistratu diseinua hurrengo pertsonak auditatu ahal izan dezan

Bakarrik fe80::1 gordetzen duen inbentario batek garrantzitsuak diren eremuak botatzen ditu. Erregistratu helmuga, hurrengo jauzia, gailua, taula eta metrika elkarrekin, gehi bide bakoitza nondik etorri zen — iragarria, kudeatzaileak sortua edo estatikoa. Geroago norbait bigarren uplink-ak benetan trafikoa eramaten duen galdetzen badu, erregistro horrek galderari erantzuten dio asmatu gabe.

Taula amaitutzat eman aurretik, egiaztatu auzokidea ip -6 neigh show dev uplink0 erabiliz, irakurri berriro ip -6 rule show ordena-istripuetan, eta probatu arauarekin bat datorren trafikoarekin defektuzko bidea hartzen duen ping batekin beharrean. Ondoren jaitsi nahita uplink bat eta begiratu zein bidera jotzen duen nukleoak; erantzunak idatzi duzunarekin bat egin beharko luke.