Delegació de prefixos IPv6 a través d'una VPN de lloc a lloc: llista de verificació

Pujar el túnel és la meitat fàcil. He vist un enllaç de lloc a lloc quedar-se establert durant dies mentre tots els equips de la LAN remota rebien silenci, perquè el prefix delegat darrere d'aquella passarel·la s'havia configurat en una interfície però mai no s'havia encaminat cap al túnel. Les adreces del túnel responien als pings tot el temps, i per això mateix ningú no va mirar el prefix. Aquest és l'ordre que comprovo quan un prefix IPv6 delegat ha de travessar una VPN de lloc: el mapa de prefixos, els selectors de trànsit, el reenviament i el tallafocs, i després el camí de tornada.

Escriviu el mapa de prefixos abans de tocar el túnel

La delegació de prefixos lliura un bloc al router que l'ha sol·licitat. No instal·la cap ruta al parell, no estén aquest bloc enllaç endins ni diu a la passarel·la remota què hi ha darrere del router sol·licitant. Aquestes tres coses les heu de configurar vosaltres, i tenen lloc en un pla d'adreçament abans que canviï cap fitxer de configuració.

Per a cada lloc, anoteu el prefix delegat, la /64 que realment s'usa a la LAN, les adreces del túnel i l'amo de cada ruta. El proveïdor delega 2001:db8:a1::/56 al lloc A, que serveix 2001:db8:a1:10::/64 a la seva LAN; el lloc B conserva 2001:db8:b2::/64. Si el lloc A només serveix aquesta /64, tots dos extrems haurien de nomenar 2001:db8:a1:10::/64 en lloc de tot el /56.

Dues errades apareixen gairebé sempre. Una és tractar el prefix remot com si fos enllaç local, enviant-lo per pont o posant-lo a la interfície del túnel perquè la passarel·la respongui a la sol·licitud de veí per equips que no pot assolir. L'altra és anunciar tot el /56 quan només hi ha una /64 configurada: la taula de rutes afirma que el bloc és abastable i la majoria d'adreces cauen en un forat negre.

Feu coincidir els selectors de trànsit dels dos extrems amb les rutes

IKEv2 i WireGuard tots dos refusen el trànsit desajustat, prou en silenci perquè el túnel encara sembli sa.

A strongSwan els selectors són explícits. Al lloc 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 del lloc B reflecteix les dues subxarxes. Quan no coincideixen, el respondedor rebutja la CHILD_SA amb TS_UNACCEPTABLE, així que la SA filla no puja mai encara que la IKE_SA sí que ho hagi fet. A banda i banda, la subxarxa configurada ha de ser igual al que el nucli local encamina cap al túnel.

WireGuard porta la mateixa informació a AllowedIPs, amb un gir: AllowedIPs és un filtre d'origen en recepció i també una ruta en enviament. Si l'entrada de parell del lloc B per al lloc A omet 2001:db8:a1:10::/64, els paquets del lloc A arriben amb un handshake vàlid i es descarten com a no permesos. Això produeix el patró conegut d'un handshake que es renova sense parar mentre no surt mai cap resposta. Compareu els dos extrems amb wg show wg0 allowed-ips. Torneu a comprovar la llista sempre que canviï la delegació; una /64 antiga manté la sessió enlaire i el prefix nou inabastable.

Descarteu primer el reenviament, el tallafocs i l'MTU

Abans de llegir una altra línia de registre, confirmeu que les passarel·les reenvien d'alguna manera. sysctl net.ipv6.conf.all.forwarding ha de tornar 1 a totes dues, aplicat també a les interfícies del túnel i de la LAN. Hi ha un parany adjunt: un cop el reenviament és actiu, una interfície amb accept_ra=1 deixa d'acceptar anuncis de router del proveïdor, de manera que l'equip pot perdre la ruta per defecte ascendent mentre encamina perfectament dins del túnel. Poseu accept_ra=2 on encara calgui un RA del proveïdor.

Després, les regles del tallafocs han de permetre el prefix en tots dos sentits, i ICMPv6 ha de sobreviure: el descobriment de veïns, el paquet-massa-gran i la destinació inabastable no són opcionals. Si els descarteu, el descobriment d'MTU del camí es trenca i obteniu connexions que s'obren i després s'encallen a la primera resposta gran. Una parella mínima de regles té aquest aspecte:

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

L'MTU va al darrere. Un túnel redueix l'MTU utilitzable per sota de 1500, i IPv6 exigeix que cada enllaç porti almenys 1280. Els pings petits passen, una sessió SSH es congela en una ràfega gran, i /proc/net/snmp6 mostra missatges de paquet-massa-gran que no tornen mai. Fixeu l'MTU del túnel explícitament, o limiteu l'MSS de TCP a la taula mangle, i deixeu que torni l'ICMPv6 que informa de l'MTU més petit.

Proveu el camí de tornada, no l'adreça del túnel

La fallada que costa més temps és l'encaminament unidireccional. Cada passarel·la encamina el prefix remot cap al túnel, però els equips responen per la seva pròpia passarel·la per defecte perquè és on viu la seva /64. Fer arribar un paquet a la destinació és només mig camí.

Dues ordres resolen la major part. Al lloc A, ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 mostra quina interfície faria servir una resposta d'aquella font; feu la comprovació mirall al lloc B. Després genereu trànsit des d'un equip i no des de la passarel·la, i compareu els comptadors als dos extrems.

Si la sol·licitud de veí per al prefix remot apareix al túnel, aquest prefix és enllaç local en algun lloc on no hauria de ser; arregleu-ho abans d'ajustar rutes. Proxy NDP cobreix els casos en què l'enllaç per pont és realment necessari, no és un substitut d'una ruta.

Planifiqueu que el prefix canviï sota els peus

La delegació de prefixos és un arrendament entre el router delegant i el sol·licitant, i una renovació pot tornar un bloc diferent: un /56 diferent després d'una migració del proveïdor, o un arrendament més curt que el temps que el túnel porta enlaire. Cada lloc que anomena el prefix antic es queda obsolet de cop: rutes, selectors, AllowedIPs, regles de tallafocs, registres DNS i qualsevol monitoratge que codifiqui adreces literals. El flux de missatges és a RFC 8415.

On s'esperi que el prefix es mogui, manteniu un pla d'adreçament intern que no en depengui i traduïu a la frontera. NPTv6 és l'opció sense estat i manté la política interna llegible, però és traducció de prefixos, no una capa màgica: les fronteres /64 han de coincidir, les sumes de verificació s'ajusten, i les aplicacions que incrusten adreces literals encara es trenquen. Si manteniu les adreces del proveïdor d'un extrem a l'altre, anoteu el comportament de l'arrendament i un procediment de canvi al pla d'adreçament.

Acabeu amb una prova que sobrevisqui al temps: un equip permès de cada LAN arriba a un servei de l'altra LAN, la resposta torna pel túnel, i la mateixa parella encara funciona després de reiniciar el túnel i renovar la delegació. Si falla l'última part, el disseny depèn d'un estat que no durarà una setmana.