Encamiñar IPv6 entre dúas sedes sobre unha VPN existente

Unha WAN só IPv4 pode seguir transportando IPv6 interno. Segue os selectores, as rutas do núcleo, o reenvío e o prefixo de retorno que descarta respostas en silencio.

Cando engades un prefixo IPv6 a un túnel de sede a sede, o paquete non viaxa como suxire o diagrama. A pasarela local toma o paquete IPv6 enteiro, cífrao e pon diante unha cabeceira IP externa cuxa familia de enderezos a deciden os enderezos dos extremos, non o que hai dentro. A pasarela remota quita esa cabeceira externa e reenvía o paquete orixinal á súa LAN, onde volve ser un paquete IPv6 normal. Túnel externo e tráfico interno son dúas conversas separadas que comparten unha chave, un par de extremos e nada máis.

Dúas cabeceiras, dúas familias de enderezos

En modo túnel IPsec, o paquete IPv6 interno convértese na carga útil detrás dunha cabeceira ESP. A cabeceira externa que transporta ese paquete ESP pode ser IPv4 ou IPv6, e segue local_addrs e remote_addrs. WireGuard fai o mesmo con menos cerimonia: o paquete interno é a carga útil dun datagrama UDP cara ao extremo do par. Ambos deixan intacta a cabeceira interna, e por iso o lado remoto pode encamiñala tras a desencapsulación.

O camiño entre as sedes só ve UDP 4500 cando IPsec usa a travesía NAT, ou UDP 51820 para un oínte WireGuard predeterminado. Calquera router do traxecto pode ser só IPv4 e o tráfico IPv6 crúzao igualmente, porque nunca aparece como paquete IPv6 nese camiño. Iso dá unha primeira separación limpa: tcpdump -ni eth0 udp port 51820 mostra o camiño cifrado, tcpdump -ni wg0 ip6 mostra o tráfico interno. Unha captura externa con moito tráfico e unha interna silenciosa significa que o núcleo non está metendo IPv6 no túnel; é encamiñamento ou política, non estado da ligazón.

A pasarela tamén decrementa o límite de saltos interno ao reenviar, así que os extremos contan como routers na ruta IPv6. A conta de saltos externa e o límite de saltos interno móvense de forma independente, e un paquete que morre na pasarela remota morreu no reenvío, non no cifrado.

Os selectores e AllowedIPs son a lista de permisos

IKEv2 negocia que prefixos internos pode transportar unha SA filla. En strongSwan 5.9 e posteriores, escribilos en swanctl.conf vese así:

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

Omitide local_ts e remote_ts e strongSwan derívalos das subredes da interface que selecciona. Nun host de dobre pila ese atallo adoita producir un par só IPv4: a SA sobe e IPv6 recái antes de chegar ao código ESP. Escribir os dous prefixos fai que a SA sexa apta para transportalos, e start_action = trap a ergue co primeiro paquete que coincide.

WireGuard ten unha única lista que cumpre dúas funcións. No bloque de par, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 é tanto a ruta instalada ao enviar como o filtro aplicado ao recibir: un paquete descifrado cuxa orixe interna queda fóra desa lista descártase en silencio. wg-quick engade unha ruta por entrada, así que o bloque de par de abaixo non precisa un comando ip -6 route á parte.

[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

As dúas listas deben estar espelladas: a sede B acepta o prefixo da sede A como selector remoto e encamíñao de volta, e o túnel só funciona cando as dúas direccións coinciden. Unha lista asimétrica produce o síntoma que máis tempo custa: un aperto de mans san, contadores que se moven nun lado, e un ping de A a B que funciona mentres nada de B chega a A.

Reenvío, rutas e o prefixo de retorno

Linux non reenvía IPv6 ata que llo digas, e o axuste é por espazo de nomes e non por interface:

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

A segunda liña é a que se esquece nos deseños baseados en rutas. IPsec baseado en políticas instala unha política XFRM que coincide cos prefixos, pero unha configuración baseada en rutas con vti6 ou WireGuard necesita unha ruta IPv6 real que apunte a ese dispositivo. Fai persistente o sysctl en /etc/sysctl.d/; se non, un reinicio devolve o reenvío a desactivado en silencio.

O reenvío ten un efecto secundario que convén coñecer: o núcleo ignora entón os anuncios de router salvo que net.ipv6.conf.<wan>.accept_ra sexa 2, así que unha pasarela cuxo enderezo WAN chega por SLAAC pode perder a súa ruta predeterminada no momento en que activas o reenvío. Axusta accept_ra = 2 nesa interface no mesmo ficheiro e a ruta sobrevive. O núcleo da sede B tamén debe aprender 2001:db8:aa::/48 desde a pasarela do túnel, mediante ruta estática ou un protocolo de encamiñamento sobre o túnel, ou a resposta morre dentro da propia rede de B.

Unha comprobación en catro pasos que localiza a avaría

Traballa nesta orde e detente no primeiro paso que falle, porque cada paso posterior depende dos anteriores.

  1. Selectores: swanctl --list-sas debería mostrar o par de prefixos IPv6 na SA filla, ou wg show wg0 allowed-ips o prefixo remoto cun latest-handshakes recente.
  2. Ruta do núcleo: ip -6 route get 2001:db8:bb::10 debe responder co dispositivo do túnel, non coa interface WAN.
  3. Captura interna: tcpdump -ni wg0 ip6 mentres fas ping entre hosts reais da LAN. Paquetes que saen pero ningún que volve apuntan á ruta ou á devasa de B; ningún paquete apunta de volta aos pasos 1 ou 2.
  4. Destino: no host B, ss -6 -ltn confirma que o servizo escoita en IPv6, e os contadores locais da devasa mostran se o paquete se aceptou ou se descartou.

A MTU entra na mesma pasada. Os routers IPv6 non fragmentan, así que un paquete demasiado grande descártase e Packet Too Big volve ao emisor. Se os apertos de mans e os pings pequenos funcionan pero unha transferencia de ficheiros se atasca, reduce a carga útil ata que pase: ping -6 -s 1400 -c 3 2001:db8:bb::10. As interfaces WireGuard teñen por defecto unha MTU de 1420 bytes e IPsec sobre IPv4 resta máis, así que fixar a MTU interna vence esperar o descubrimento de MTU de camiño a través dunha devasa que descarta ICMPv6.

Modos de fallo que parecen problemas de devasa

O máis común non é unha devasa en absoluto: o servizo liga a 0.0.0.0 en lugar de ::, o rexistro AAAA existe, e o cliente recibe un rexeitamento rápido por IPv6 que un navegador de dobre pila agocha volvendo a IPv4. Se só fallan algunhas aplicacións, comproba a familia de escoita antes de tocar un conxunto de regras.

O segundo é o filtrado ICMPv6. Neighbor Discovery e Packet Too Big forman parte do funcionamento normal, non do diagnóstico, e unha política que descarta todo ICMPv6 produce un túnel que conecta, autentica e despois atasca con calquera cousa maior que un paquete pequeno. Permite os tipos dos que depende o camiño e deixa os contadores acendidos para que un descarte sexa visible.

O terceiro é un prefixo engadido ao túnel pero nunca ao plan de enderezos da sede que o posúe, de modo que ningún router o anuncia e ningún host pode responder del. Comeza cun prefixo e un par de hosts, demostra as dúas direccións cos catro pasos e despois engade o resto; un prefixo roto queda como unha liña nunha configuración en lugar dun redeseño. A única referencia oficial que paga a pena manter aberta é RFC 8200, que define a cabeceira que transporta o túnel.

Artigos relacionados