Encaminar IPv6 entre dos seus per una VPN existent

Una WAN només IPv4 pot portar igualment IPv6 intern. Segueix els selectors, les rutes del nucli, el reenviament i el prefix de retorn que descarta respostes en silenci.

Quan afegiu un prefix IPv6 a un túnel de lloc a lloc, el paquet no viatja com suggereix el diagrama. La passarel·la local pren el paquet IPv6 sencer, el xifra i hi posa al davant una capçalera IP externa la família d’adreces de la qual la decideixen les adreces dels extrems, no el que hi ha a dins. La passarel·la remota treu aquesta capçalera externa i reenvia el paquet original a la seva LAN, on torna a ser un paquet IPv6 normal. Túnel extern i trànsit intern són dues converses separades que comparteixen una clau, una parella d’extrems i res més.

Dues capçaleres, dues famílies d’adreces

En mode túnel IPsec, el paquet IPv6 intern es converteix en la càrrega útil darrere d’una capçalera ESP. La capçalera externa que transporta aquest paquet ESP pot ser IPv4 o IPv6, i segueix local_addrs i remote_addrs. WireGuard fa el mateix amb menys cerimònia: el paquet intern és la càrrega útil d’un datagrama UDP cap a l’extrem del parell. Tots dos deixen intacta la capçalera interna, i per això el costat remot pot encaminar-la després de la desencapsulació.

El camí entre els llocs només veu UDP 4500 quan IPsec fa servir la travessia NAT, o UDP 51820 per a un oient WireGuard predeterminat. Qualsevol router del trajecte pot ser només IPv4 i el trànsit IPv6 hi passa igualment, perquè no apareix mai com a paquet IPv6 en aquest camí. Això dona una primera separació neta: tcpdump -ni eth0 udp port 51820 mostra el camí xifrat, tcpdump -ni wg0 ip6 mostra el trànsit intern. Una captura externa atrafegada amb una d’interna silenciosa significa que el nucli no posa IPv6 al túnel; és encaminament o política, no estat de l’enllaç.

La passarel·la també decrementa el límit de salts intern quan reenvia, de manera que els extrems compten com a routers al camí IPv6. El comptador de salts extern i el límit de salts intern es mouen de manera independent, i un paquet que mor a la passarel·la remota va morir en el reenviament, no en el xifrat.

Els selectors i AllowedIPs són la llista de permisos

IKEv2 negocia quins prefixs interns pot portar una SA filla. A strongSwan 5.9 i posteriors, escriure’ls a swanctl.conf es veu així:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Ometeu local_ts i remote_ts i strongSwan els deriva de les subxarxes de la interfície que selecciona. En un amfitrió de doble pila aquesta drecera sovint dona una parella només IPv4: la SA puja i IPv6 es rebutja abans d’arribar al codi ESP. Escriure els dos prefixs fa que la SA sigui apta per portar-los, i start_action = trap la aixeca amb el primer paquet que coincideix.

WireGuard té una sola llista que fa dues feines. Al bloc de parell, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 és tant la ruta que s’instal·la en enviar com el filtre que s’aplica en rebre: un paquet desxifrat l’origen interna del qual cau fora d’aquesta llista es descarta en silenci. wg-quick afegeix una ruta per entrada, així que el bloc de parell de sota no necessita cap comanda ip -6 route a part.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Totes dues llistes s’han de mirar en mirall: el lloc B accepta el prefix del lloc A com a selector remot i l’encamina de tornada, i el túnel només funciona quan les dues direccions estan d’acord. Una llista asimètrica dona el símptoma que costa més temps — una encaixada de mans sana, comptadors que es mouen en un costat, i un ping d’A a B que funciona mentre res de B arriba a A.

Reenviament, rutes i el prefix de retorn

Linux no reenvia IPv6 fins que ho digueu, i l’ajust és per espai de noms i no per interfície:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

La segona línia és la que s’oblida en els dissenys basats en rutes. IPsec basat en polítiques instal·la una política XFRM que coincideix amb els prefixs, però una configuració basada en rutes amb vti6 o WireGuard necessita una ruta IPv6 real que apunti a aquest dispositiu. Feu persistent el sysctl sota /etc/sysctl.d/; si no, un reinici torna el reenviament a desactivat en silenci.

El reenviament té un efecte secundari que val la pena conèixer: el nucli llavors ignora els anuncis de router tret que net.ipv6.conf.<wan>.accept_ra sigui 2, així que una passarel·la l’adreça WAN de la qual arriba per SLAAC pot perdre la ruta predeterminada en el moment que activeu el reenviament. Ajusteu accept_ra = 2 en aquesta interfície al mateix fitxer i la ruta sobreviu. El nucli del lloc B també ha d’aprendre 2001:db8:aa::/48 de la passarel·la del túnel, amb ruta estàtica o un protocol d’encaminament sobre el túnel, o la resposta mor dins de la xarxa pròpia de B.

Una comprovació en quatre passos que localitza l’avaria

Treballa en aquest ordre i atura’t al primer pas que falli, perquè cada pas posterior depèn dels anteriors.

  1. Selectors: swanctl --list-sas hauria de mostrar la parella de prefixs IPv6 a la SA filla, o wg show wg0 allowed-ips el prefix remot amb un latest-handshakes recent.
  2. Ruta del nucli: ip -6 route get 2001:db8:bb::10 ha de respondre amb el dispositiu del túnel, no amb la interfície WAN.
  3. Captura interna: tcpdump -ni wg0 ip6 mentre feu ping entre amfitrions reals de la LAN. Paquets que surten però cap que torna apunten a la ruta o al tallafoc de B; cap paquet apunta de tornada als passos 1 o 2.
  4. Destinació: a l’amfitrió B, ss -6 -ltn confirma que el servei escolta en IPv6, i els comptadors locals del tallafoc mostren si el paquet s’ha acceptat o descartat.

L’MTU entra a la mateixa passada. Els routers IPv6 no fragmenten, així que un paquet massa gran es descarta i Packet Too Big torna a l’emissor. Si les encaixades de mans i els pings petits funcionen però una transferència de fitxers s’encalla, reduïu la càrrega útil fins que passi: ping -6 -s 1400 -c 3 2001:db8:bb::10. Les interfícies WireGuard tenen per defecte una MTU de 1420 bytes i IPsec sobre IPv4 en resta més, així que fixar la MTU interna val més que esperar el descobriment de MTU de camí a través d’un tallafoc que descarta ICMPv6.

Modes de fallada que semblen problemes de tallafoc

El més comú no és cap tallafoc: el servei s’enllaça a 0.0.0.0 en lloc de ::, el registre AAAA existeix, i el client rep un rebuig ràpid per IPv6 que un navegador de doble pila amaga tornant a IPv4. Si només fallen algunes aplicacions, comproveu la família d’escolta abans de tocar un conjunt de regles.

El segon és el filtratge ICMPv6. Neighbor Discovery i Packet Too Big formen part del funcionament normal, no del diagnòstic, i una política que descarta tot ICMPv6 produeix un túnel que connecta, s’autentica i després s’encalla amb qualsevol cosa més gran que un paquet petit. Permeteu els tipus dels quals depèn el camí i deixeu els comptadors encesos perquè un descart sigui visible.

El tercer és un prefix afegit al túnel però mai al pla d’adreces del lloc que el posseeix, de manera que cap router l’anuncia i cap amfitrió no pot respondre’n. Comenceu amb un prefix i una parella d’amfitrions, demostreu les dues direccions amb els quatre passos i després afegiu la resta; un prefix trencat es queda com una línia en una configuració en lloc d’un redisseny. L’única referència oficial que val la pena mantenir oberta és RFC 8200, que defineix la capçalera que transporta el túnel.

Articles relacionats