IPv6 politika enkursigo kiam du suprenligoj kunhavas fe80::1

Vi havas du suprenligojn, kaj ip -6 route show presas la saman sekvan salon sur ambaŭ: default via fe80::1 dev uplink0 kaj default via fe80::1 dev uplink1. Tio ne estas konflikto de duoblaj adresoj, kaj kopii la nudan sekvan salon fe80::1 en politikan tabelon ne diras al la kerno, kiun ligon vi celis. La vera demando estas pli mallarĝa ol la simptomo sugestas: ĉu la dua tabelo bezonas unu ligon aŭ ambaŭ, kaj kio tenas tiujn itinerojn vivaj post restarto. Tri kondiĉoj, kontrolitaj laŭ ordo, solvas la plejparton.

La sama fe80::1 estas du malsamaj najbaroj

Lig-lokaj adresoj estas limigitaj al unu ligo, do fe80::1 ne estas unu adreso presita dufoje; ĝi estas du najbaroj, kiuj hazarde kunhavas sufikson. La zona indico estas kiel gastiganto diras, kiun ĝi celas, do fe80::1%uplink0 kaj fe80::1%uplink1 estas malsamaj celoj por la kerno, kaj tiu sufkso neniam vojaĝas al fora itinero. RFC 4007 priskribas la zonan modelon malantaŭ tio, kaj tial politika tabelo devas porti aparaton kun ĉiu lig-loka sekva salo.

VPN-agordgenerilo, kiu kopias ciferecan zonan ID de unu gastiganto en ŝablonon, traktas lokan kuntekston kvazaŭ ĝi estus parto de la adreso, kaj la dosiero, kiun ĝi skribas, estas malĝusta sur ĉiu maŝino, kies interfacaj nomoj aŭ indicoj diferencas. Politika tabelo ankaŭ ne kunfandas du ligojn en unu: enkursigita VPN pasigas pakaĵojn inter retoj, sed ĝi ne portas lig-lokan identecon de fora Ethernet-najbaro tra la tunelo, do lig-loka trafiko restas sur sia propra ligo.

Forigu la aparaton kaj la itinero fariĝas neskribebla. ip -6 route add default via fe80::1 table 200 ne povas solvi la enirejon, kaj iproute2 rifuzas ĝin per Error: Nexthop has invalid gateway. Aldonu dev uplink0 kaj la komando sukcesas, ĉar la aparato estas tio, kio fiksas la sekvan salon al unu el tiuj du najbaroj. Kion la aparato ne povas diri al vi, estas ĉu uplink0 estas la ĝusta ligo por ĉi tiu tabelo, kaj itinero kopiita de alia gastiganto kunportas la interfacajn nomojn de tiu gastiganto, kaj de tie venas la veraj eraroj.

Kondiĉo unu: unu ligo aŭ du en la tabelo

Komencu per tio, por kio la dua suprenligo estas. Se ambaŭ ligoj portas la saman trafikon kaj unu estas rezerva, la alternativa tabelo devus teni ambaŭ enirejojn kun malsamaj metrikoj: samaj celoj, unu preferata vojo, unu evidenta dua elekto. Se la suprenligoj ekzistas ĉar malsama trafiko devas eliri tra malsamaj provizantoj, aŭ ĉar temas pri dividita tunelo, kie parto de la trafiko preterpasas la VPN dum la resto restas interne, la du ligoj tute ne apartenas al unu tabelo. Ili apartenas al du tabeloj, elektitaj de regulo, kaj la regulo elektas la tabelon, ne la tunnelon: preterpasanta trafiko estas markita antaŭ ol ĝi estas enkursigita, kaj la marko estas tio, kio sendas ĝin al la dua tabelo.

En tiu dua kazo la regulo decidas kiam tabelo estas konsultata, kaj la itinero decidas kien la pakaĵo iras poste:

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

Nek unu objekto anstataŭas la alian, kaj tabelo, kiu tenas nur defaŭltan itineron, ankoraŭ povas malsukcesi solvi sian enirejon. Se aldono estas rifuzita, aŭ la itinero ĉeestas sed estas neuzebla, metu la konektitan prefikson por tiu interfaco en la saman tabelon, aŭ marku la salon onlink kiam tiu prefikso estas enkursigita aliloke. En la supra bloko 2001:db8:100::/48 reprezentas ĝuste tiun konektitan prefikson sur uplink1, ne arbitran celon. La regulo fwmark konsumas nur markon, kiun io alia devas meti, el regulo nftables aŭ iptables sur la plusendvojo aŭ el SO_MARK sur la poŝo, do bloko kopiita sen markfonto kongruas kun nenio.

Kondiĉo du: metrikoj ne detektas mortintan provizanton

Metriko estas prefero inter itineroj, kiuj ekzistas, ne sankontrolo. Kiam la portanto falas, la kerno forigas la itinerojn sur tiu aparato kaj la dua defaŭlta transprenas. Kiam la kablo restas supren kaj la provizanto malantaŭ ĝi mortas, nenio en la tabelo ŝanĝiĝas: la preferata itinero estas instalita, la najbaro estas atingebla sur tavolo 2, kaj pakaĵoj eliras en nigran truon. Se tiu distingo gravas por via agordo, la malsukcesa transiro devas veni de io, kio sondas la vojon kaj forigas la itineron, ĉu itinera demono, ĉu malgranda skripto, kiu forigas kaj reinstalas la rikordon.

Kontrolu la elekton post kiam la tabelo estas konstruita, kaj kontrolu ĝin tiel, kiel la kerno vidos ĝin. ip -6 route get 2001:db8:100::1 presas la itineron, kiu estus uzata, inkluzive la aparaton kaj la elektitan fontan adreson, kaj ĝi respektas politikajn regulojn. Fonto-adreso apartenanta al la malĝusta suprenligo estas la kutima signo, ke regulo kongruis pli frue ol vi atendis.

Kondiĉo tri: decidu, kiu posedas la daŭrecon

Itinero aldonita per ip -6 route add postvivas ĝis restarto aŭ ĝis io forviŝas ĝin. Defaŭlta itinero lernita el itinera anoncoj portas vivdaŭron kaj povas esti retirita de la itinero, dum permane aldonita defaŭlta itinero neniam mem eksvalidiĝas. Miksi la du en unu tabelo estas la maniero, kiel malnova permanenta itinero finas superi freŝe anoncitan, longe post kiam la suprenligo, kiun ĝi priskribis, ĉesis ekzisti.

Elektu unu posedanton por tabelo. Se retadministrilo aŭ itinera demono jam administras la interfacon, priskribu la politikan itineron tie kaj lasu la kernon trankvila. Se vi skriptas ĝin, faru la skripton idempotenta kaj skribu la malmuntadon samtempe, ĉar vi bezonos ĝin dum la unua malbona ŝanĝo:

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

Sur itinero, kiu plusendas por aliaj gastigantoj, kontrolu net.ipv6.conf.all.forwarding antaŭ ol kulpigi la tabelon. Kun plusendo malŝaltita, pakaĵoj adresitaj al alia reto estas forĵetitaj, kiom ajn ĝusta estas tabelo 201.

Registru la dezajnon, por ke la sekva persono povu ĝin aŭditi

Inventaro, kiu konservas nur fe80::1, forĵetas la kampojn, kiuj gravas. Registru la celon, la sekvan salon, la aparaton, la tabelon kaj la metrikon kune, plus de kie ĉiu itinero venis — anoncita, administrila aŭ statika. Kiam iu poste demandos, ĉu la dua suprenligo efektive portas trafikon, tiu rikordo respondas la demandon sen konjektado.

Antaŭ ol vi nomos la tabelon finita, konfirmu la najbaron per ip -6 neigh show dev uplink0, relegu ip -6 rule show pri ordaj akcidentoj, kaj testu per trafiko, kiu kongruas kun la regulo, anstataŭ per ping, kiu prenas la defaŭltan itineron. Poste malsuprenigu unu suprenligon intence kaj observu, al kiu itinero la kerno reiras; la respondo devus kongrui kun tiu, kiun vi skribis.