IPv6-prefiksa delegado trans VPN de loko al loko: kontrol-listo

Levante la tunelon estas la facila duono. Mi vidis ligilon de loko al loko resti starigita dum tagoj, dum ĉiu gastiganto en la malproksima LAN ricevis nur silenton, ĉar la delegita prefikso malantaŭ tiu pordego estis agordita sur interfaco sed neniam enkursigita en la tunelon. La tunelaj adresoj respondis al pingoj la tutan tempon, kaj ĝuste tial neniu rigardis la prefikson. Jen la ordo, kiun mi kontrolas, kiam delegita IPv6-prefikso devas transpasi lokan VPN-on: la prefiksa mapo, la trafikaj selektiloj, plusendado kaj fajroŝirmilo, poste la revena vojo.

Skribu la prefiksan mapon antaŭ ol tuŝi la tunelon

Prefiksa delegado transdonas blokon al la enkursigilo, kiu petis ĝin. Ĝi ne instalas itineron ĉe la kunulo, ne etendas tiun blokon sur la ligilo, kaj ne diras al la malproksima pordego, kio loĝas malantaŭ la petanta enkursigilo. Tiujn tri aferojn agordas vi, kaj ili apartenas al adresa plano antaŭ ol ajna agorda dosiero ŝanĝiĝas.

Por ĉiu loko, notu la delegitan prefikson, la /64 efektive uzatan en la LAN, la tunelajn adresojn kaj la posedanton de ĉiu itinero. La provizanto delegas 2001:db8:a1::/56 al loko A, kiu servas 2001:db8:a1:10::/64 en sia LAN; loko B konservas 2001:db8:b2::/64. Se loko A servas nur tiun unu /64, ambaŭ finoj devus nomi 2001:db8:a1:10::/64 anstataŭ la tutan /56.

Du eraroj aperas preskaŭ ĉiufoje. Unu estas trakti la malproksiman prefikson kiel surlokan, ponti ĝin aŭ meti ĝin sur la tunelan interfacon por ke la pordego respondu al najbara peto por gastigantoj, kiujn ĝi ne povas atingi. La alia estas anonci la tutan /56 kiam nur unu /64 estas agordita: la itinera tabelo asertas, ke la bloko estas atingebla, kaj la plej multaj adresoj falas en nigran truon.

Agordigu la trafikajn selektilojn de ambaŭ finoj al la itineroj

IKEv2 kaj WireGuard ambaŭ rifuzas malkongruan trafikon, sufiĉe silente por ke la tunelo ankoraŭ aspektu sana.

En strongSwan la selektiloj estas eksplicitaj. Ĉe loko A:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

La conn de loko B spegulas la du subretojn. Kiam ili malkongruas, la respondanto malakceptas la CHILD_SA per TS_UNACCEPTABLE, do la infana SA neniam leviĝas kvankam la IKE_SA leviĝis. Ambaŭflanke la agordita subreto devas egali tion, kion la loka kerno enkursigas al la tunelo.

WireGuard portas la saman informon en AllowedIPs, kun unu tordo: AllowedIPs estas fonta filtrilo ĉe ricevo kaj ankaŭ itinero ĉe sendo. Se la kunula ero de loko B por loko A preterlasas 2001:db8:a1:10::/64, pakaĵoj de loko A alvenas per valida manpremo kaj estas forĵetitaj kiel nepermesitaj. Tio produktas la konatan ŝablonon de manpremo, kiu senĉese renoveblas dum neniu respondo iam eliras. Komparu ambaŭ finojn per wg show wg0 allowed-ips. Rekontrolu tiun liston ĉiufoje, kiam la delegado ŝanĝiĝas; malnova /64 tenas la sesion supren kaj la novan prefikson neatingebla.

Unue ekskludu plusendadon, fajroŝirmilon kaj MTU

Antaŭ ol legi plian protokollinion, konfirmu, ke la pordegoj entute plusendas. sysctl net.ipv6.conf.all.forwarding devas redoni 1 ĉe ambaŭ, aplikite ankaŭ al la tunelaj kaj LAN-interfacoj. Unu kaptilo venas kun ĝi: post kiam plusendado estas ŝaltita, interfaco kun accept_ra=1 ĉesas akcepti enkursigilajn anoncojn de la provizanto, do la maŝino povas perdi sian supran defaŭltan itineron dum ĝi enkursigas senriproĉe ene de la tunelo. Agordu accept_ra=2 tie, kie provizanta RA ankoraŭ necesas.

Poste la fajroŝirmilaj reguloj devas permesi la prefikson en ambaŭ direktoj, kaj ICMPv6 devas postvivi: najbara malkovro, pakaĵo-tro-granda kaj celo-neatingebla ne estas laŭvolaj. Forĵetu ilin kaj la voja MTU-malkovro rompiĝas, donante al vi konektojn, kiuj malfermiĝas kaj poste blokiĝas ĉe la unua granda respondo. Minimuma paro da reguloj aspektas tiel:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

La MTU staras malantaŭ tio. Tunelo malgrandigas la uzeblan MTU sub 1500, kaj IPv6 postulas, ke ĉiu ligilo portu almenaŭ 1280. Malgrandaj pingoj pasas, SSH-sesio frostas ĉe granda eksplodo, kaj /proc/net/snmp6 montras mesaĝojn pakaĵo-tro-granda, kiuj neniam revenas. Agordu la tunelan MTU eksplicite, aŭ limigu TCP MSS en la mangle-tabelo, kaj lasu la ICMPv6, kiu raportas la pli malgrandan MTU, reveni.

Testu la revenan vojon, ne la tunelan adreson

La fiasko, kiu kostas la plej multe da tempo, estas unudirekta enkursigado. Ĉiu pordego enkursigas la malproksiman prefikson en la tunelon, sed gastigantoj respondas per sia propra defaŭlta pordego, ĉar tie loĝas ilia /64. Venigi pakaĵon al la celo estas nur duona vojo.

Du komandoj solvas la plej multon. Ĉe loko A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 montras, kiun interfacon respondo de tiu fonto uzus; faru la spegulan kontrolon ĉe loko B. Poste generu trafikon de gastiganto anstataŭ de la pordego kaj komparu la nombrilojn ambaŭflanke.

Se najbara peto por la malproksima prefikso aperas en la tunelo, tiu prefikso estas surloka ie, kie ĝi ne devus esti; riparu tion antaŭ ol ĝustigi itinerojn. Proxy NDP kovras kazojn, kie pontado vere necesas, ne estas anstataŭaĵo por itinero.

Planu por la prefikso ŝanĝiĝanta sub vi

Prefiksa delegado estas luo inter la deleganta kaj la petanta enkursigilo, kaj renovigo povas redoni alian blokon: alian /56 post provizanta migrado, aŭ pli mallongan luon ol la tempo, dum kiu la tunelo estis supren. Ĉiu loko, kiu nomas la malnovan prefikson, eksmodiĝas samtempe: itineroj, selektiloj, AllowedIPs, fajroŝirmilaj reguloj, DNS-rikordoj kaj ajna monitorado, kiu malmole kodas laŭvortajn adresojn. La mesaĝfluo estas en RFC 8415.

Kie oni atendas, ke la prefikso moviĝos, tenu internan adresan planon, kiu ne dependas de ĝi, kaj traduku ĉe la limo. NPTv6 estas la senstata opcio kaj tenas internan politikon legebla, sed ĝi estas prefiksa traduko, ne magia tavolo: /64-limoj devas akordiĝi, kontrolsumoj estas ĝustigataj, kaj aplikaĵoj, kiuj enigas laŭvortajn adresojn, ankoraŭ rompiĝas. Se vi tenas provizantajn adresojn de fino al fino, registru la luokonduton kaj ŝanĝproceduron en la adresa plano.

Finu per testo, kiu postvivas la tempon: permesita gastiganto en ĉiu LAN atingas servon en la alia LAN, la respondo revenas tra la tunelo, kaj la sama paro ankoraŭ funkcias post restartiĝo de la tunelo kaj renovigo de la delegado. Se la lasta parto malsukcesas, la dezajno dependas de stato, kiu ne postvivos la semajnon.